Thought it would be interesting to see the progress on critical issues for Drupal 8 beta and then try and predict when the release candidate might show up. Below is a graph from Plotly showing monthly (lunar) progress (why can’t these guys solve issues at a nice steady pace instead of giving us these messy, bumpy graphs for crying out loud):
Resorting to modules or plugins to fulfill functionality requirement is not ideal as the quality of contributed modules varies, the support can be flaky to non-existent, the life span is never really that guaranteed and you create another security vulnerability. Of course there are some amazing well supported modules out there but if you can fulfill your requirements using core code then happy days. What makes Drupal 8 so special is some new pretty amazing features that ship with the core. I’ve just focused on the ones that leap out at me and make Drupal stand out from the crowd.
We are living in a world where data is king. Google’s business model is built on owning data and mining that data. Data becomes really powerful when you can share it across platforms between applications.
We ran into an issue this week, one I haven’t encountered before when we were using a “sub module”. The module in question was the Taxonomy CSV project for Drupal 7 and we had moved this into a custom module as we had some custom functionality to add inside of it.
We noticed that our custom defined permissions were showing on our admin > people > permissions page but the default permissions were not.
This one is a bit off the topic, but something that I’ve found vitally important when creating responsive designs / “mobile first” websites. The limited space on mobiles often is something that is only going to be fixed by larger screen sizes – devices such as iPhones and certain Androids have a limited screen size compared to larger phones like the Galaxy Note.
We have seen a bit of trouble with versions of Drupal 6 running on hosts who are upgrading their versions of PHP to above 5.2. According to the Drupal requirements then you may experience some errors or unexpected behaviours if you are running drupal 6 under PHP 5.3. The recommended version is PHP 5.2. Drupal developers everywhere will need to keep a mindful eye on this one.
This has caught out a few of our older sites which have been hosted elsewhere, we’re currently looking into this – more to follow…
We last told you how to serve up 2 fields for searching between two date fields on a View. While this solution was great if you entered 2 dates, your nodes were returned perfectly based on the date field you provided in the view. It did fail, however, if you only specified one date.
If you have a nice view that contains a list of nodes (with date fields) and you want to be able to filter these dates (using exposed filters) then you can do this simply by installing the Date module.
Once this is installed and enabled, edit your view and “Add” a new “Filter Criteria”. Find the field “Date (node)” and add this.
We’ve ran into an issue when exporting databases using our Aegir host. Our first recommendation, is always to clear your cache from your database before you move backup/export your Drupal database.
We use the “Administration Menu” module on most of our installs – as it gives a handy toolbar that stays at the top of your browser window. This has a menu item for “Flush all caches” and we noticed that, this didn’t actually flush the caches when using our Aegir host. You can test this by doing the following:
This is a stumbling block we’ve hit lately, we had a view showing a list of News items and then were referencing another content type called “Editors” which are actually classed as nodes as we were using Profile2 module. So the Editors (though they were users) had information contained within their “profiles”.