PHP filter and search index woes
PHP filter is a great filter. It gives you a lot of flexibility. But it has a lot of disadvantages too. One of them is that it makes your code harder to debug.
One of those hard debug sessions occurred lately when the following happened. Cron always stopped running when it was going to index this one node. It also redirected to some page. Weird.
What was happening? The node was a page. The body was having the PHP filter on and the following code was in that body:
<?php drupal_goto("node/add/story"); ?>
What does this have to do with search indexing you ask? Well, when the search indexer is going to index a node, it first runs all filters on your body, and it's the result of that that is getting indexed. So if you're writing PHP code, that code is run when the indexer comes along. Even "non-text generating" code, like the redirect in this case.
About
drupalcoder.com is a blog on all things Drupal in specific and LAMP on OS X in general. It is maintained by Davy Van Den Bremt, a Belgian (Drupal) web developer and designer living in Ghent. The goal of this blog is to log all interesting things that have crossed the writer's path while developing Drupal sites. You can read all about Davy's professional activities on his LinkedIn profile. If you want to get in touch, use the contact form.
Comments
to fix it surround your redirect code with this:
$semaphore = variable_get('cron_semaphore', FALSE);
if (!$semaphore) {
drupal_goto('content/my_funky_page');
}
I'm going to link this page the next time someone asks me why I tell them not to use php code in a node body
I think the PHP filter encourages bad coding. It might seem easier to write some wonky PHP code and put it in the body of a node, but then you just make it harder on yourself later on.
Funky results with indexing are one problem. But what if you (or your client!) wants to add all kinds of functionality? Like hooking the page in the menu API, or making easy use of permissions/roles.
At that point, you just wish you had just begun with a custom module.
Of course, PHP filter has it's values: small, very specific code that controls lay-out. But using PHP in nodes past that might do more harm then good in the long run.
The PHP filter is evil incarnate. IMHO it shouldn't even be in core.
Had the same problem a few weeks a go. Cron failed for a site with an error about an unknown function from a removed module. After grepping through all possible template and Drupal files, I finally found it back in a node. I'm glad grep works fine for database dumps too :-).
Added to DrupalSightings.com
Post new comment