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
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:
However, a date field in D6 might look like this:
I ran into an issue where I was not able to use the Localization update module in Drupal on an Acquia hosted site. This is because the default location where the module stores translation files, sites/all/translations could not be created due to this directory being write protected. I suppse write protecting any directory location that could contain executable code is a good practice.