The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Drupal 8 progress from my / MongoDB perspective: update #15

Submitted by nk on Thu, 2013-03-14 09:05

The entity team was busy: Nodes are using the new Entity API and Taxonomy Terms are not far behind. All the field types are also getting integrated with the new Entity API. Given that the new entity query only works with entities and fields integrating with this API, it's really great to see this happening.

CMI got a new override and context system. This, as usual, is only relevant to my goals as I am utterly dependent on the success of CMI :)

Drupal 8 progress from my / MongoDB perspective: update #14

Submitted by nk on Sat, 2013-02-16 08:45

A short one because not a lot of time has passed but two commits worths a quck post: Aggregator support for entity queries has been committed and also we have an aptly named 'drivers' directory database and other drivers can live. I will work on getting drush and update.module support for the db drivers there.

PSA: Twig was not added because Symfony

Submitted by nk on Fri, 2013-02-15 11:28

Before this gets too much traction: We didn't add Twig to core because Symfony uses it. I know it became popular to add anything that Symfony does based on the features it provides. Now, I started the Twig movement and I don't work like that. In fact, I feel frustrated and somewhat insulted that anyone presumes I would operate like that. My No1 priority is security. It always was. It always will be. To quote the original issue:

Are you confused by Behat / Gherkin?

Submitted by nk on Wed, 2013-02-13 20:24

I presume you read some Behat/Gherkin tutorials which go: "With BDD, you write human-readable stories that describe the behavior of your application." Well, WTF, how does that human readable story become code? The answer is, which I have never seen clearly written: you write it, without any help, whatsoever. Behat does not provide any assertions, any helpers, it's an extremely thin test runner. You need to write a test class, mandatory name "FeatureContext.php".

Drupal 8 progress from my / MongoDB perspective: update #13

Submitted by nk on Mon, 2013-02-11 04:19

The entity config query is in and the aggregation query system is ready, and it's surprising how little new code was necessary for it -- mostly a little refactor of the existing SQL implementation to make it more reusable and of course a lot of tests -- written with the help of dawehner, thanks! There are a few big issues left: split the entity controller into a CRUD controller and the real controller. Once users become EntityNG, roles need to use the existing entity reference item. Same for taxonomy terms and their hierarchy.

Drupal 8 progress from my / MongoDB perspective: update #12

Submitted by nk on Wed, 2013-01-23 08:49

Installing / importing new configuration no longer writes directly the config storage but uses the full Config object which fires events on write/delete. This allowed me to start on writing a config entity query class which subscribed these events and denormalized data suitable for queries. catch then voted this one down, saying it's premature optimization. So a simpler implementation has been submitted which loads all configuration entities of a certain kind (like all Views) and then filters/sorts/etc.

config(), state() and settings()

Submitted by nk on Wed, 2013-01-09 03:30

In Drupal 7 one could store every random thing not having its own table with variable_set and retrieved it with variable_get and life was simple. There was the $conf variable in settings.php which allowed an easy override. This worked well... until you wanted to copy variables from one server to the other. Or translate them. In Drupal 8, most variables have moved to config() and are still overrideable by $conf. There are a few exceptions.

Drupal 8 progress from my / MongoDB perspective: update #11

Submitted by nk on Mon, 2013-01-07 20:10

Most importantly: we added static caching to the configuration management system. This paves the way of further speedup by utilizing cache_get_multiple instead of loading each object one by one. While Drupal always had the capability to override certain variables in settings.php this is now much nicer and even has its own little API, settings()->get(). The separation of these settings necessary for bootstrap versus the CMI overrides was badly needed. Also, the new Entity Query system now has relationship support (that has been a frequent request).

Automated git pull in a more protected environment

Submitted by nk on Fri, 2012-12-21 20:17

Almost exactly a year ago I wrote about automating git pull from github. I found myself in an environment where a) I wanted to do this b) PHP had been set up so that git pull didn't work. inotifytools to the rescue. First, write a password-like filename (see the old post) PHP script like this:

file_put_contents('pull/git', '');

Then write a bash script:
cd ~/public_html
while inotifywait -qre close_write pull
  git pull

Drupal 8 progress from my / MongoDB perspective: update #10

Submitted by nk on Wed, 2012-12-12 22:17

I have changed course and speed seemingly because now we are so beyond tresholds that feature patches can't get in. So we are in bugfix mode and I have chosen performance ones because those will help in a lot of ways: it will kill a lot of majors and criticals and also speed up testing which helps development overall. Also, the EntityQuery relationship patch relies on converting everything to the new Entity API and that can't happen if it's slow.

User login