Drupal 7 introduced the brilliant feature of letting users cancel their own account and with it various options for what to do with content they've created when they are cancelled. One of these options is to: > Delete the account and its content. Which can prove somewhat problematic if used incorrectly. You see, Drupal is very good at the latter part: deleting all the content created by the user. It's not very good at warning...
The new GDPR laws are here, hurrah! Having a number of developers handling databases from a number of client sites could easily be a nightmare, but we at ComputerMinds spent quite some time thinking about how to get and keep everybody safe and squeaky clean on the personal data front. Here's a quick run-down of the key things to be aware of - and a pretty poster to help you keep it all in mind...
Much has been said about last month's highly critical Drupal security issue 'SA-CORE-2014-005', otherwise known as 'Drupalgeddon'. It was covered by mainstream international media, even if the reaction needs addressing. Drupal's security team take a responsible approach to security issues - being open & honest in disclosing them with fixes, in keeping with the community values. Security issues should always be expected in any software, it's how they are dealt with that speaks far more. We patched all the sites that we had access to immediately fix, and informed all our clients of the issue as soon as possible. If you host a Drupal site, and haven't yet, run through the Drupalgeddon workflow right now.
Drupal 7's database layer is awesome, it is built upon PDO and one of the great things about PDO is named placeholders, they allow you to build queries like: $unsafestring = "this string can contain quotes: ' or other things"; $query = db_select('table') ->fields('table') ->condition('field', $unsafestring); The SQL that is sent to the database is: SELECT table.* FROM table WHERE (field = :db_condition_placeholder_0) This is sent along with the contents of $unsafestring to replace the...
Upgrading from Drupal 4.6 has always been complicated by issues of character sets, but the Drupal upgrade scripts normally solve most of these problems for us. But when your dealing with a complex upgrade you need a good understanding of how Drupal is dealing with character sets in Mysql. It all comes down to this - pre 4.7 Drupal stores utf8 encoded data in latin1 based tables (although this sounds a bit silly there were...