- 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
- 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
- 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
- 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
- 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
- 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ?
Bets are onLater
Among the interesting features of Phing is its extensibility, and of the hallmarks of that exensibility is the ability to define new
Task types as PHP classes, which are by default located in the default namespace only. Can we do better ?
Step 0: "Ad-hoc" (inline) tasks
At the simplest,
Task classes are created by embedding ad-hoc tasks like:
A few days ago, while I was writing a bit of Silex code and grumbling at Doctrine DBAL's lack of support for a SQL Merge operation, I wondered if it wouldn't be possible to use DBTNG without the rest of Drupal.
Obviously, although DBTNG is described as having been designed for standalone use:
DBTNG should be a stand-alone library with no external dependences other than PHP 5.2 and the PDO database library, in actual use, the Github DBTNG repo has seen no commit in the last 3 years, and the D8 version is still not a Drupal 8 "Component" (i.e. decoupled code), but still a plain library with Drupal dependencies. How would it fare on its own ? Let's give it a try...
WebProfilerServiceProvider brings the Symfony Profiler to Silex apps, and with it the nice "Timeline" feature, detailing for each request cycle the time spent handling each event dispatched by the
kernel.terminate, with detail time spent in each individual listener.
The timeline looks like this one:
This is all nice and well, but there is a problem with this timeline: although the beginning and end of the request cycle is profiled in depth, it represents less than half of the total time spent for this request.
More than half of the total request time is spent in the controller, and this example does not even perform any database access, which would make the controller represent event more of the total time, making the detailed analysis of the beginning and end of the request cycle less relevant.
What would make sense would be to subdivide the time spent in the controller in much the same way the time spent in the event listeners is already plotted. Is there a simple way ? Sure: let us see how the profiler works.
So, since I always supported PSR-4 in FIG discussions, and after the tl;dr discussion about it regarding autoloading in Drupal 8, I jumped on the occasion and converted the code base for PlusVite to PSR-4 to get an idea of how PSR-4 "felt" in practice.
So DrupalCon Prague is almost over, and I can now share with you the video of my session about the history of the Drupal block system, from drop.org to Drupal 8, just as recorded on wednesday.
The session page is available on https://prague2013.drupal.org/session/blocks-drop.org-drupal-8-and-beyond where you can also rate it. Please to it over there, or add your comments here: it is very useful for me to see what needs to be adjusted for upcoming presentations. Based on the overall feedback, it seems that:
Just noticed this little gem on a 10Gen course, about the respective names of the CRUD operations in common practice, versus the equivalent operations in SQL and in MongoDB. Links point to Wikipedia for SQL and the relevant MongoDB documentation page for the MongoDB column.
Some of the features in PHP may be surprising. Think for instance of the way PDO is able to create classed results, place the query results into them, and only then invoke the constructor when using
PDO::FETCH_CLASS fetch mode without the additional
PDO::FETCH_PROPS_LATE. Every wished you could do this in userland code ? Turns out this has long been possible, and is even simpler since PHP 5.4.
I was checking a bunch of Behat features left by former developers on a project, and noticed that the Rake rule to run them looked like:
$ behat -c config/behat.yml features
But this looked suspiciously like defaut options. How about running them more simply like just
$ behat ? Alas, this would throw something like:
These last few days, I had noticed a problem with Drush Make and patches: some patches, be they rolled by our team or from elsewhere, would apply without a glitch, but some others, which worked normally according to the test bot on Drupal.org, would fail to apply without any obvious reason.
I had mostly put it out of my list of pressing issues when I really had to use an old version of OpenLayers, 7.x-2.0-alpha2 to be specific, AND apply a patch fixing one of the bugs in that module: behaviors plugin not being located correctly (http://drupal.org/node/1898662 if you want details). So I rolled the patch, tested it locally, the qa.d.o bot applied it and did not report more errors than expected for that old version.... and my Drush Make install refused to apply it.
Here was the relevant excerpt:
projects[domain] = 3.7
projects[domain][patch] = "http://drupal.org/files/domain-foreach_argument-1879502-1.patch"
projects[openlayers] = 2.0-alpha2
projects[openlayers][patch] = "http://drupal.org/files/0001-Fix-the-path-file-declaration-for-behaviors.patch"
The Domain patch applied normally, but the OpenLayers patch would't apply. What could be wrong ?