I keep digging up this same information from some obscure sources, so I thought I would post it here. Now if you have not set up XDebug with a project locally, I highly recommend that, but still, nothing beats a good stack trace. In Drupal 7, I would drop this into settings.php to show errors, regardless of the site settings:
I just had to make a post about this strange issue. A client sent me a database for a Drupal 7 site so I could resolve an issue for them. I clone the site, set up a virtual machine, import the DB. But trying to interact with the site resolved in some unusual errors:
After attempting any drush command:
An occassionaly pastime of mine is to put together timelines using the timeline.js framework. This is what I used to build a timeline based on the events of the Star Trek universe. In the past few monts, I had been working on a timeline that depicts real human efforts to explore space. So here is my Timeline of Space Exploration (Can you tell I like space?). Of course it's a work in progress.
I shouldn't have to say this to the type of person who follows this site, which is mostly myself, and a bunch of trump supporting Russians that speak very strange languages... but here is a reminder to be careful when copy-pasting code, especially from comments/descriptions from a ticketing system. Depending on your operating system, the following lines will look identical, but there is a subtle difference.
I've noticed an issue crop up recently where drush seems unable to download new modules, or update existing ones with the drush dl and drush up commands. The issue is that some versions of wget shipped with Redhat Enterprise Linux failed to check SAN names in certificates properly. This article from fastly explains the issue well. Note that Drupal.org hosts its updates server on fastly.
You can see where drush is failing by using the verbose flags
So yesterday was another big one for anyone who maintains Drupal sites. If you haven't patched your sites by now, you should assume at this point that any site you maintain with the Coder, RestWS or Webform Multiple File Upload modules has been compromised.
Here I go, still posting articles on Drupal 7, but hey, maybe someone will find these useful since that version isn't going away any time soon. Now how about a little SEO for the error message:
TL;DR: Why are my dates being converted to November 30th in PHP? Because zero is an invalid month and day.
One thing that strikes me odd is how to handle dates with wide granularities in PHP, and Drupal as usual. I came across this problem in a content migration project. In Drupal 6, a date field that was only granular to the year would like something like this:
2016-00-00T00:00:00
However, a date field in D6 might look like this:
2016-01-01 00:00:00
