Google 500 server error, otherwise working

Hello, I’ve been developing a website in MODx for about a year now and I have to say that the CMS is perfect. I launched it about a month ago and it works fine, absolutely no errors... except Google can’t crawl it. The site is www.theforce.ro (it’s in romanian) and it’s perfectly accessible to everyone, but when I submit a sitemap or check for any crawls I see HTTP Error: Found: 500 (Internal server error.

I am using the alias script and htaccess, using the standard settings from the installation. I am on linux server (CentOS) with modx 0.9.5 rev 2106, with Ditto 2 with PHP 5.2.4 on an Apache 2.0.59 with the modules:

core prefork http_core mod_so mod_access mod_auth mod_auth_anon mod_auth_dbm mod_auth_digest util_ldap mod_auth_ldap mod_include mod_log_config mod_env mod_cern_meta mod_expires mod_deflate mod_headers mod_usertrack mod_setenvif mod_mime mod_dav mod_status mod_autoindex mod_asis mod_info mod_dav_fs mod_vhost_alias mod_negotiation mod_dir mod_imap mod_actions mod_speling mod_userdir mod_alias mod_rewrite mod_proxy proxy_ftp proxy_http proxy_connect mod_cache mod_suexec mod_disk_cache mod_file_cache mod_mem_cache mod_cgi mod_logio mod_bw mod_fcgid mod_jk mod_perl mod_php5 mod_python mod_ssl

The site uses Magpie and other scripts but as long as my visitors can see the site, why can’t Google crawl it?

I can’t say what the problem is, but I can confirm that your site is sending out the 500 Internal Server Error in it’s response headers:

I checked this using the WebDeveloper Firefox extension’s Information > View Response Headers function.
What’s odd is that it’s sending out this header, but then sending the page output. That’s why it looks ok in the browser.

I’ll check if I can use htaccess to modify the headers with this:

<FilesMatch "\.(php|cgi|pl|htm)$">
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>

Don’t need the apache cache anyway so I’ll check if this works.

Actually.. it didn’t work. I still get the same connection close with the 500 error

Do you have access to Apache’s error log, just in case it’s logging something interesting in conjunction with these pages?

Well.. I just found it.. using Plesk. It’s 1,25 GB. I wonder why?    I talked to one of the support guys there. They’ll delete the log, and probably generate a new one, but it’ll take until tommorrow (it’s 10 PM here).

Later edit: The log says nothing about modX, weird. The other errors are related to my forum, but there is only one related to modx "[Fri Jan 04 23:08:00 2008] [error] [client 83.103.132.21] File does not exist: /var/www/vhosts/theforce.ro/httpdocs/manager/media/images, referer: http://www.theforce.ro/manager/index.php?a=93" and it’s not significant.

Quote from: Raith at Jan 04, 2008, 12:47 PM

I am using the alias script and htaccess, using the standard settings from the installation.

What’s the "alias script"? Have you made any changes to .htaccess at all? Could .htaccess have been saved in Windows (giving it Windows-style line endings)? Just trying to think of anything that would give Apache cause to generate an error condition before it hands things over to php.

Alias script, sorry about that, that’s what it’s called in Mambo (or was) I meant Friendly URLS. Oh, and about the htaccess, I saved it in plesk using Unix line break type and UTF-8. Anyway, this is what it says in there:

I can explain that, slightly. I tried upgradind modx to the latest version and did a backup with phpmyadmin. Atfer upgrading to the latest version I still get the 500 error, even if the file I load is a simple file using the blank template. It seems that in the backup phpmyadmin injected every link with a session id or something. My host is Webfactor, and it’s odd because I used phpmyadmin before and never had a problem. It’s not really an issue because I don’t see how it can affect modx, but it is a nag that can be fixed. I also have the modx backup which indeed has no links damaged by phpmyadmin.

Later edit: I found out that the problem with the link injection appears after you access the configuration page in modx. I was forced to beacuse Romanian is not displayed properly and hhad to modify the encoding. Before I did that every link was perfect, EVEN if I used a backup that contained the phpMyAdmin=X71iqiTxhVKpG85d%2Ce73Bi7nm95 part. To fix my encoding I modified the template but I think that if I go and modify something in the configuration I will have faulty links again.

Also, I have installed the newest version of modx separately. www.theforce.ro/modx and it works perfectly, no 500. Also, these are my snippet versions if it helps:



Forms and Mail
eForm - 1.4.1 Robust form parser/processor with validation, multiple sending options, chunk/page support for forms and reports, and file uploads.
Navigation
Breadcrumbs - 0.9d Configurable breadcrumb page trail navigation.
FirstChildRedirect - 1.0 Automatically redirects to the first child of a folder document.
UltimateParent - 1.2 - Gets the highest parent that isn’t 0.
Wayfinder - 2.0 Completely template-driven menu builder that’s simple and fast to configure.
News, Blogs and Catalogs
Ditto - 2.0.2 Summarizes and lists pages to create blogs, catalogs, PR archives, bio listings and more.
Jot - 1.1.2 User comments with moderation and email subscription.
ListIndexer - 1.0 Shows the most recent documents, highly flexible.
NewsPublisher - 1.4 Publish news articles directly from the web.
Reflect
Search
AjaxSearch - 1.1 Ajax enabled search form with results highlighting.

I discovered the same 500 error header issue, trying to verify a new MODx-run site within Google Webmaster Tools.

Looking at response headers with firebug confirmed the 500 error; I then tried saving the verification html doc with no template (template ’blank’ in the manager); and also adding a ’ExpiresActive Off’ in .htaccess -nothing changed!

Finally I passed verification by creating the html with a text editor and uploading it to the MODx directory manually; bypassing the CMS page generation completely.

definitely a conflict between headers set by Apache and MODx ones, might be worth further investigations since it affects the site’s response time optimization (YSlow)