[*Solved] Please help: Error-Messages in MODx Revolution

Letti, that’s coming very soon. Please PM me for details.

Letti, If your host is running suPHP or suExec, you may have the permissions set *too high.* Directories should be 755 and files 644 in that case.

Here’s another thought. If you used FTP to install the MODx files, there may have been some files in the cache directory that are "owned" by FTP and the server doesn’t want to delete them.

Try using cPanel’s File Manager and deleting everything in the core/cache directory. MODx will create new files that may have the proper ownership and permissions (or not).

Hi BobRay,
thanks a lot for your new help how we might resolve the errors.

Quote from: BobRay at Jan 02, 2011, 11:03 PM

Letti, If your host is running suPHP or suExec, you may have the permissions set *too high.* Directories should be 755 and files 644 in that case.

Here’s another thought. If you used FTP to install the MODx files, there may have been some files in the cache directory that are "owned" by FTP and the server doesn’t want to delete them.

Try using cPanel’s File Manager and deleting everything in the core/cache directory. MODx will create new files that may have the proper ownership and permissions (or not).

As far as I saw in the System Info and in the phpinfo the server is not running suPHP or suExec.

Beside this we now deleted everything in core/cache except the .gitignore-file. Unfortunately the errors continue when we visit a couple of different webpages at the same moment for the first time after clearing the cache.

Maybe there are more folders we can delete for trying to solve the problem?

We have about 60 TVs. Maybe this is a co-factor of the problems? Are there any cache-folders which we can renew/delete in respect to this? (In the beginning we were going to make our MODx as safe as possible and therefore we gave many folders CHMOD 755 and the ownership to the ftp-client. Meanwhile we changed this back to 775 and gave the ownership back to MODx as well as we could. But maybe there remained some settings which are now leading to the problems?

Another possible reason could be the 60 TVs we have created of which are many related to each other. Do you think this could be a reason as well and is there a possibility to check this maybe by an diagnostic tool?

Thanks again for your help!
Letti

Hi Letti,

I noticed that you are using APC-Cache as well as modx caching system. Sometimes two caching systems can cause conflict.. Have you tried turning off APC-Cache temporarily and see if the problem can be recreated?

Hi coldhand,

we activated APC-Cache a couple of days before. But the errors already appeared before we activated APC-Cache. Do there exist more cache-systems which might collide with another cache-system?

I recommend using APC with MODx Revolution or it will be a lot slower; don’t think that would be related.

Is it possible that you have a circular reference in the TVs that are related to each other, resulting in an endless loop of DB queries?

Quote from: BobRay at Jan 05, 2011, 01:15 AM

Is it possible that you have a circular reference in the TVs that are related to each other, resulting in an endless loop of DB queries?

We have one TV that includes another TV. Can this result in the errors or is this normal technique which is done by other MODx-Users, too?

Beside this we found out that no more errors occur when we disable the "Database Cache" in the MODx-Settings.

But if we disable "Global Cache Option" while "Database Cache" is enabled the errors still occur. Does this mean that disabling "Global Cache Option" does not include the "Database Cache"?

So does anybody know what could be the reason of the errors which don´t occur anymore when "Database Cache" ist disabled?

And can we let the "Database Cache" disabled or is this a big disadvantage especially if you once have a couple hundrets visitors in a short period?

Ok, we finally recognized that cache_db is set in an original MODx-installation by default to "no". We have no idea why this was set (or why we set this) to yes in our settings.

But after all we are very happy that this problem is probably solved right now and we can concentrate on other important challenges again. Thanks to all who gave us all the time so many hints and help!

Letti

Just in case someone else runs into this, I am running a Mac. I did two things to correct it.

First, I created an /etc/my.cnf file per Apple instructions and added these two lines:

1 [mysqld]
2 socket=/tmp/mysql.sock

Also, I noticed that I was overlooking the two of these lines in php.ini. I only knew to change one of them.

pdo_mysql.default_socket = /tmp/mysql.sock
mysql.default_socket = /tmp/mysql.sock
mysqli.default_socket = /tmp/mysql.sock

Searching a phpinfo() page helped track these down.