From Ana Aman's Blogspot blog today, there's a quick post with a helpful hint for anyone working with PHPMyAdmin experiencing freeze-ups.

If you are using phpmyadmin on a database with more 1500 or more tables, you may experience problems. The page will not load at all so you will not be able to operate propery with phpmyadmin.

Of course you can still run commands from a terminal or console but it is not as confortable as using phpmyadmin.

The solution? Following a bit of digging, Ana discovered that upping the memory limit for the server PHPMyAdmin installed on makes a world of difference.

From Ana Aman's Blogspot blog today, there's a quick post with a helpful hint for anyone working with PHPMyAdmin experiencing freeze-ups.

If you are using phpmyadmin on a database with more 1500 or more tables, you may experience problems. The page will not load at all so you will not be able to operate propery with phpmyadmin.

Of course you can still run commands from a terminal or console but it is not as confortable as using phpmyadmin.

The solution? Following a bit of digging, Ana discovered that upping the memory limit for the server PHPMyAdmin installed on makes a world of difference.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.

On the blog of the Agave Group today, there's this new post showing how to correct an issue that a PHP/MySQL install has with the OS X version 10.4.

I recently upgraded my mac to OS 10.4. Overall I've been pleased. Recently I decided to fire up PHP and mySQL and ran into some trouble.

Everything was moving along nicely - until I tried to connect to my database from a PHP page. To make a (really) long story short, a bunch of research revealed that since OS 10.4, the PHP install tries to connect to mySQL via the socket: /var/mysql/mysql.sock, but mySQL uses /tmp/mysql.sock. So they won't talk to one another. The trick is to change your php.ini to point to /tmp/mysql.sock.

Included is also a mini-guide to getting PHP working on OS X, and how he solved his problem (where to find the php.ini and change the value it needed).

On the blog of the Agave Group today, there's this new post showing how to correct an issue that a PHP/MySQL install has with the OS X version 10.4.

I recently upgraded my mac to OS 10.4. Overall I've been pleased. Recently I decided to fire up PHP and mySQL and ran into some trouble.

Everything was moving along nicely - until I tried to connect to my database from a PHP page. To make a (really) long story short, a bunch of research revealed that since OS 10.4, the PHP install tries to connect to mySQL via the socket: /var/mysql/mysql.sock, but mySQL uses /tmp/mysql.sock. So they won't talk to one another. The trick is to change your php.ini to point to /tmp/mysql.sock.

Included is also a mini-guide to getting PHP working on OS X, and how he solved his problem (where to find the php.ini and change the value it needed).