When you want to recursively fix file permissions, directories usually should get a umask of 755 while files should default to 644 unless they are scripts.

Fortunately, chmod has the +X modifier for that: +X only adds the execution bit to directories, while it does not add it to files. It keeps pre-existing execution bits for files though. Thus, to fix all directories to have 755 and files to have 644 or 755 depending on the existing exexcution bit, just run:

If you want to reset all files to 644 also, run

As I've never been happy with the performance of Drupal running on behalf nfs shares in vagrant, I've been looking into a simple way to rsync my local changes into a vagrant box. There are separate tools like lsyncd or the deployment features of IDEs, but I wanted to have a simple solution that is easily scriptable.

I just gave a talk about the Drupal 8 Entity API at the Drupal Dev Days in Szeged. For everyone who missed it, you can find my slides here

After playing around with git-annex a bit, I figured its ubuntu install instructions are not ideal as the official ubuntu package is quite out of date (still at version 3.2), but git annex 4 comes with rather important improvements such as direct mode.

Fortunately there is an ubuntu PPA with an update version for ubuntu precise (12.04), which works well for raring (13.04) as well. To use it just run:

You might have heard some rumors about a tool called "fluxkraft": something like ifttt.com, but with Rules? Or what? Indeed, fluxkraft is one of our latest drunomics lab projects funded by netidee - a Austrian grant for powerful - and open - innovations, and yes - fluxkraft will be a tool for rule-based web automation, built as an open platform on top of Rules and Drupal! So, finally here are some first details on it:

So the idea is to build an easy to use Drupal distribution that allows you to automate various web-based tools like twitter, facebook and dropbox. Yes, you can do that already with services like ifttt.com, but fluxkraft will be an open platform, open-source and free for everyone to use and extend. That way, you can install it on your own servers and keep all the keys to your valuable data secured - and most importantly - under your control!
Then, as it's open source and will come with an API for adding connectors to new services you can simply integrate it with any service you want. So while the tool will provide some essential integrations for services like twitter and facebook from the start, the hope is that community will chime in and provide connectors to a variety of different online services.
Rules?
So how does that tie into Rules? Well, Rules already provides a solid technical base, but we'll add an API for easy-integration with external services to it - so we've got the kraft. But for the flux to gain enough strength, we'll build a new UI that makes it super-simple to create, mix, and share the rules that connect the various services together. So yes - we'll build a new Rules UI! Initially, it will be built separately and power fluxkraft, but if everything works out we'll see a new Rules UI pretty soon!

All fine, Doc? So what's the time(line)? We've mostly finished some initial wireframes, so expect a first shout for feedback on the the new UI at the Rules g.d.o. group soon! Then, the fluxkraft team will be working eagerly on the project such that - maybe - we might have a first preview release out for Drupalcon Portland in May. Howsoever, we'd love to share our learnings and show how we are reloading the Rules UX with fluxkraft, so I've proposed session!
Finally, so who's in the boat? Well, it's me "fago" who will be leading the project during the next months - in fact I'll dedicate most of my time to it. But, fortunately I've got some help of Christian Ziegler aka criz (Strategy, Community Management), Sebastien Siemssen aka fubhy (Development) and Nico Grienauer (Design, Inspirator).
If you are interested, follow @fluxkraft on twitter and provide feedback in a short comment below!

As previously announced on the IKS blog I’ve been recently working together with Stéphane Corlosquet on integrating the tools provided by the IKS project to do semantic content enhancements in Drupal as part of the IKS early adopter program.

The Interactive Knowledge Stack (IKS) project is an open source community which got funded by the EU to build an open and flexible technology platform for semantically enhanced Content Management Systems. Thanks to IKS, open source projects like Apache Stanbol, VIE.js or Create.js got started. While VIE.js and Create.js are already on their way to Drupal 8 via the Spark initiative, our focus was on integrating Apache Stanbol with Drupal 7. In short, Apache Stanbol is a java web application that leverages tools like Apache Solr, Apache Tika or Apache OpenNLP to provide a set of reusable components for semantic content management via RESTful web services. On the front-end side, VIE.js (“Vienna IKS Editables”) is the JavaScript library for implementing decoupled Content Management Systems and semantic interaction in web applications.

For leveraging Apache Stanbol with Drupal we send Drupal’s data over to Apache Stanbol’s EntityHub component for indexing, such that it is available to Apache Stanbol’s content enhancer. That means, we can use VIE widgets like annotate.js to send pieces of text over to Apache Stanbol for auto-linking content items indexed to Stanbol, which by default includes DBpedia entities, but could be easily extended by any source providing data in RDF. Next, the VIE autocomplete widget allows for easy tagging based upon entities indexed with Apache Stanbol - regardless of whether they come from DBPedia or from one of the Drupal sites your organization runs!

As there must be Rules at the Drupalcon Munich as well, I've had a Rules session together with Richard Jones from i-KOS. Head over to the session page for a summary and find the slides attached attached to this post as well. Moreover, you can find all the screencasts we've used during the presentation here as well. It's a real Drupal commerce site we've been using in the session to show how Rules can be used to solve real life problems.

1 - No VAT for certain products

2 - Discounts for products that are not belts or bags

and then to make it work the same way years ahead

3 - Subscribe to back in stock notifications via Flag module.

4 - Notify me when something needs review with Workbench moderation

5 - Execute Rules components from Views Bulk Operations

6 - Let's do promitions, but only on Monday please!

7. Message users if they abandoned their carts

8. Log user communication with the Message module

Why?

While the conversion to full CRUD for entities and classed objects for Drupal 8 made good progress, we’ve not yet reached the goals of fully translatable entities and having a default entity serialization for import/export, content staging and web services. For those points we need to know what’s in an entity! Yes we can look up the fields, but there are also base entity properties and further stuff modules put on entities, which both are no fields so we do not know anything about them.

That is what the new Entity Property API is supposed to change: It’s about providing a unified interface to entity properties *and* fields, avoiding the split between fields and non-field properties. So fields will be entity properties working with the same API as well! Then, it’s about being able to instrospect what’s going to be in an entity - regardless whether it has been added by a module or by the user via field UI. But furthermore, with classed entity objects as the basis we can improve the developer facing API and make it easier to access property and field values (I’m looking at you, $entity->field_body[LANGUAGE_NONE][0][‘value’]).

What?

As we’ve outlined in the WSCCI Web Services Format Sprint report we want to have a modern OOP, interface based API for properties. The API should allow for introspection, so that it’s possible to look up the defined properties of an entity type in advance. If you know the Entity property information system of the Drupal 7 Entity module, it’s a bit similar to that, but instead of adding an extra layer above the existing entities it’s about supporting it natively. So there will be no need for entity wrappers - all the easy API and information will be directly available in $entity.

See the Entity Property API meta issue for a more complete list of planned features.

At the Drupalcon Denver I've given a talk called "Drupalize your data: use entities!". Check out the recording of my talk and find the slides attached: Also, I've been instructing at the "Rules Mastery" training, together with Johan Falk, Dick Olsson and Klaus Purer. The training materials are all available online so check them out at http://tinyurl.com/rulesmastery! To get into Rules check out the The tiny book of Rules - kudos to Johan Falk again :-)

Some weeks ago I decided to go for something new and to start freelancing. Anyway, I'll keep up the good relationship with epiqo, but starting from December I'm going to work on a freelance basis and look out for other exciting possibilities and projects. Of course I keep maintaining my beloved Drupal modules. Moreover if everything goes well, I hope to be able to reserve more time for community work that way and/or to find new sponsors for exciting developments.