Recently I was working on a Drupal project that required the use of a custom module and, within that module, custom blocks. I searched for something like ‘drupal 7 custom block’ on google, grabbed the example code for hook_block_info() and hook_block_view() (as I’ve done plenty of times in the past), and went merrily on my way.
One of the things we have to do quite frequently is migrate databases from one server to another. There are lots of reasons we might have to do this: a site going live after being on a development server, wanting to test live data in a development environment (and so bringing the database down locally from the live site), restoring a back-up to fix a broken/corrupted database, etc.
Building a website requires many different elements (from the site logo to the site design, from there to the technical side such as what screen resolutions the site will function properly on, etc), and so website development requires the developer to be both able to use the tools of the trade and also to understand the concepts behind what he is building.
I deal with a lot of WordPress sites in my day-to-day proceedings. 'Dealing with WordPress sites' has, for me, come to mean 'cleaning up hacked WordPress sites', since that covers about 90% of the dealings I have with WordPress. Having experience with many compromised WordPress websites begs the question, does this mean that WordPress itself is an inherently-flawed CMS with gaping security holes and should be avoided at all costs?
In Part One, I went over some of the more common Wordpress hacks I've seen, and ways to detect them/find where they're hiding. Here, I'm going to look at the second part of the equation: removing the hack without damaging your site. I will also go through some of the more unique hacks I've come across and some basic strategies to make sure you don't get hacked again.
One of the more common issues I've had to deal with in the area of website technical support is that of wordpress sites getting hacked. I've seen hacks perpetrated by various hacker groups (typically these are flamboyant and overwrite the index.php/index.html files), and I've seen hacks that consist of a small segment of code being injected automatically (by a script of some sort) into every php file on the site. Having dealt with these hacks frequently, I have come up with a few methods of sniffing out the problems that might exist and dealing with them.
A common problem, and one that has tripped me up several times, is that when attempting to redirect from a node submission form via adding a submit handler in an implementation of hook_form_alter, the redirect instruction is never honored.
Take the following example, which is normally the appropriate way to handle adding a submission handler to a form:
Sometimes, as in the case of a script which iterates over many thousands of users, loads the user object, manipulates it and then re-saves it, the memory available to the PHP process can become a bottleneck. Unlike in previous versions of Drupal, in Drupal 7 and above users are statically cached after a user_load is performed. If you are sequentially loading thousands of users, you can easily hit up against memory limitations. To force Drupal to release its internal static cache of users after a user_load operation, you can call
