Feed aggregator
Lullabot: Module Monday: Content Locking
Drupal's editorial experience has improved considerably over the past several releases, and Drupal 8 promises to be even better. However, it's still easy for writers and editors to collide with each other when they collaborate. If two people edit the same piece of content at the same time, one user's changes are inevitably lost. Fortunately, the Content Locking module is ready to help.
Module Monday: Content Locking
Drupal's editorial experience has improved considerably over the past several releases, and Drupal 8 promises to be even better. However, it's still easy for writers and editors to collide with each other when they collaborate. If two people edit the same piece of content at the same time, one user's changes are inevitably lost. Fortunately, the Content Locking module is ready to help.
Guest post: Notes from DrupalCamp Gothenburg, Sweden
Adam Evertsson is the head honcho behind DrupalCamp Gothenburg two years in a row, member of the Swedish podcast Drupalsnack and always fond of the community, both locally and globally. He really came for the code and stayed for the community.
After visiting a DrupalCamp in 2011, I set off with a mission - to arrange a DrupalCamp in my hometown of Gothenburg. This became a reality only 5 months later and with the experience from that said camp of 2012 we set off to make the next one even better.
And at the time when drupalers from all over the world started their journey back home from DrupalCon Portland, or stayed for the sprint weekend, a similar, but much much smaller event took place some 7700 kilometers away. That event was DrupalCamp Gothenburg 2013.
I took the role of project manager again and together with 12 others, we arranged a great DrupalCamp - or should I say, a Drupal Weekend!
A Drupal weekend in Gothenburg
We turned our DrupalCamp into a real Drupal weekend, starting with a kickoff at a local pub. There, a number of us started (and ended) Friday night with discussions covering Drupal, PHP, Symfony and Swedish things like surströmming and, of course, the sunny weather. As a Swede, you always discuss the weather.
Friday turned into Saturday and in the morning we opened the doors of our venue of this year’s DrupalCamp Gothenburg, Folkets Hus - the House of the People, a community area with many rooms, perfect to hold sessions in.
This year, we were glad to present a full schedule, 15 sessions, that covered the whole day. The keynote was held by Tobias Sjösten, a well-known voice in both the Drupal and Symfony community in Sweden, and covered the symbiosis of Drupal and Symfony.
The sessions consisted of very diverse things, from web accessibility to Drush, via Git and Drupal 8. A whole session was dedicated to inform about Drupal Association and community-based work in Gothenburg.
After the sessions (and a lot of coffee) we headed upstairs to the restaurant in the same building where we dug into a buffet provided by the restaurant at the venue. With a beer in our hands we continued the evening with mingling, networking and enjoying ourselves. The sunny weather invited us to sit outside and when the place closed later that night, some of the attendees headed off to a club downtown.
Sunday came around and whilst we who arranged the DrupalCamp gathered for a well-deserved lunch together, others gathered at the office of Kodamera where there was a code sprint to help get rid of more bugs from Drupal 8.
From start to end, a 48 hour ride with Drupal as the common denominator, that was the final of some six months planning and work.
Tips and tricks for organizing a camp
When we arranged our first DrupalCamp in 2012 we ended up with a long list of things to improve. This year, all of the things on the list was improved, and we ended up with another list of things to improve for future DrupalCamps. With these kind of iterations, we learn and make better DrupalCamps in the future.
So what did we improve this year? What advice can I give to all you out there planning or arranging DrupalCamps all over the world?
The most important is to listen. Listen to your visitors, sponsors and session speakers. Ask them about their ideas and their feedback about your camp. Use that information to plan and improve your camp next time. If you’re a first time camp-organizer, then seek this kind of information from your local Drupal community, or post a thread in groups.drupal.org
When the camp is over, send out a survey to get feedback from all of those that you didn’t have time to talk to.
Second most important is to have fun. Make place for fun. Our camp is 100% community-driven so besides the experience, fun is an important ingredient to make all this work.
Look in the calendar and see what’s going on. Choose a date when your camp doesn’t have to compete with other major Drupal events. In our case, we ended up very close to another camp in Sweden, and of course, DrupalCon Portland. Date-wise, we didn’t really have a choice when to have our DrupalCamp before the summer would be here, and we ended up paying for it with less visitors.
Another thing is to launch a website early, and try to set a schedule with sessions early. That attracts both visitors and sponsors.
My last tip for all you out there: Avoid growing pains by growing slowly. Start off with a one-day event, then add a code sprint next time, after that perhaps a kickoff the following and then start experimenting with business days connected to your DrupalCamp. For us, we are somewhere in the middle, we have a great camp, and in the future we’ll explore the many possibilities a DrupalCamp can offer.
Personal blog tags: drupalcampsDrupal Association News: Guest post: Notes from DrupalCamp Gothenburg, Sweden
Adam Evertsson is the head honcho behind DrupalCamp Gothenburg two years in a row, member of the Swedish podcast Drupalsnack and always fond of the community, both locally and globally. He really came for the code and stayed for the community.
Personal blog tags: drupalcampsCommerce Guys: DrupalCamp Paris - Venez nous voir!!
Our Speakers
Augustin Delaporte
Jonathan Sacksick
Julien Dubois
Anne-Sophie Picot
Shannon Vettes
Nicolas Meyer
Julien Dubreuil
Tags: Planet DrupalDrupalcamp
Deeson Online: Drupal, Drush aliases and how to use them
drush aliases allow you to run a drush commands on your local server but actually execute the command on a remote server. This is a real time saver when working locally and then you want to do something on the remote server. Your specific workflows will depend on your particular setup but, as an example on Acquia dev cloud, how about pushing code up to your remote dev server and running updatedb in two commands.
$ git push origin $ drush @site.dev updatedb -ySetting up your local computer to use an alias needs a little configuration. Alias configuration files can go into a .drush folder in your home directory. You can add as many alias files as you like here with the naming convention:
sitename.aliases.drushrc.phpEach file can contain any number of aliases descriptions which are just entries in a multi dimensional array, the key of which is the subitem for that alias. For example, an alias file called mysite.aliases.drushrc.php with one dev entry like this ...
$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'example.myserver.com', 'remote-user' => 'mysite', );... gives one alias which is accessed via the @mysite.dev drush argument. For example,
drush @mysite.dev statusThere is also a drush command to get you started on producing an alias drushrc file:
drush sa [uri] Holy Cow! What else can I do with drush aliases?I am glad you asked. How about download the remote db in one command ...
drush @mysite.dev sql-dump > /tmp/dbdump.sqlNote: don't use --result-file here as that will put the sql file on the remote server!
How about bring all the remote files down to your local system? From the root of the site on your local install run ...
drush rsync @mysite.dev:sites/default/files/ sites/default/files/Note: Run drush help rsync for help with this one!
Notes on Acquia and Drush aliasesWe often use Acquia dev cloud to host our client's sites. On Acquia hosted sites setting up local drush aliases are made very simple. Under the cloud menu on the subscription tab there is a utility link which describes exactly how to add the alias files to your local computer.
Acquia executes drush commands using drush 4 by default. To use drush 5, you'll need to edit your alias files in the .drush folder and for each environment add a path-aliases entry which describes which drush script to execute. The precise syntax is shown below.
$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'mysite.com', 'remote-user' => 'mysite', 'path-aliases' => array( '%drush-script' => 'drush5', ), ); Other readingThis link shows all the goodness that can be put into a sites drushrc file ... http://drush.ws/examples/example.aliases.drushrc.php
Read moreDrupal, Drush aliases and how to use themBy John Ennew | 10th June 2013drunken monkey: Search API Solr search is stable!
It sometimes seems to me, that there are two different types of Drupal module maintainers: the ones who create a stable 1.0 release as soon as any code is working; and those who leave their modules "unstable" for years until they finally pluck up the courage to go 1.0. (I guess there also have to be some with the right middle approach, but those propably just don't catch one's eye as much.) There are actually projects in the top 10 of contrib module usage without a stable 7.x release (although there may of course be good reasons for that).
Anyways, in that pattern I'm definitely one of the latter group. I have only recently gotten to eventually creating stable releases for a number of modules (though some of them already had several thousand users) – Search API Database search (over 11k users) and Search API Pages (almost 3k users) are still waiting – and the 1.0 release of the Search API itself also took extremely long (by which time it also already had over 2000 reported* users).
In that context, it is kind of a milestone that there is now finally a 1.0 release of the Search API Solr Search module. (If you are not familiar with it, it's pretty self-explanatory: it allows you to use Apache Solr with the Search API.) As with the other modules, it had already been production-ready for quite some time, and currently has almost 5000 users.
In the case of the Solr Search module, though, there were several good reasons to wait with a stable release – foremost, the Apache Solr Common Configurations project, though definitely a good thing, changed the configuration files quite drastically when the module was otherwise stable. We also managed to add numerous feature (like location search support) and fix a lot of bugs, but those would have probably worked as well in subsequent minor releases. There were some other major refactorings, though, (foremost the effort to get rid of the external library dependency) whose inclusion in the 1.0 release is definitely beneficial.
Additionally, for the Solr Search module the 1.0 stable release is also kind of a promise: with it, I'm saying that I'm now confident that no major changes to the config files will be necessary anymore, so that there won't be the necessity for re-indexing the content for future new (minor) releases. Time will tell whether I'll be able to keep that promise but, as said, I'm quite confident.
So, if you shied away from giving the module a spin in the past, due to its missing stable release: it has been ready for quite some time now, but now it's official!
For all existing users: upgrade to the new stable release and see if there are features or bug fixes that help you out (or, hopefully not, any bugs you can report)! Recent additions include support for SSL, field collapsing, Solr 4.x and location-based searches.
(Also, check out the new documentation, if you haven't done so already!)
* By the way, is there any data or estimations out there on what percentage of users the Drupal.org usage statistics actually capture?
Image credit: Sergey Melkonov
Tags: Search API SolrPlanet DrupalThe Creative Process: Episode 9 (Josh Higgins Interview)
Jared Ponchot and Jeff Robbins chat with Josh Higgins about his work as Design Director of the Obama 2012 Campaign. They discuss managing large creative teams, the importance of culture and lots more fascinating insights about the political campaign process.
Josh Higgins on the Obama 2012 Campaign, managing creative teams, culture and moreMediacurrent: Preparing for a Drupal Website Redesign
When was the last time your website had a facelift or you audited your Drupal modules, site security, SEO, etc?
We believe website redesigns fundamentally fall into two categories: the right and the wrong.
The right way delivers true value to an organization and the wrong way just consumes time and money for window dressing—which does nothing for your bottom line.
Recently a few of our teammates gathered our thoughts around Drupal website redesigns. As we talked through the different areas we coach our customers on, we decided to put them into one eBook.
"Preparing for a Drupal Website Redesign" is a collection of important suggestions your organization should consider before embarking on your next website design. Suggestions such as:
capdrupal a capistrano recipe for Drupal
Hi!
We are working on https://github.com/antistatique/capdrupal for some months now. This is a capistrano recipe to deploy drupal website. It works with multistage...
It's far from perfect but feedback more than welcome, please use the issue at github.
Code Enigma: Getting started with Test Driven Development - Choosing a Test Harness
Following on from the first blog post in this series, An Introduction to Test Driven Development, Chris introduces the test harness so strap yourself in!
My first experience of work "in the real world" came through work experience. I was lucky enough to get one of only two placements with IBM at Havant and my assigment was to build to specification the wiring loom used to connect the IBM 3745/3746 communications controller to its test harness. These units had to be regularly and thoroughly tested throughout production and so periodically each unit was hooked up to a test harness by means of the aforementioned wiring loom so that a range of tests could be executed against the unit and pass/fail reports and data collated. My time at IBM provided a fabulous insight into engineering/testing and firmly cemented in my mind the concept of a test harness.
In software development, a test harness provides exactly the same functionality, it provides a means of executing tests against software and giving feedback on whether the software is behaving as expected.
The specific test harness you choose will likely vary from project to project and is dependant on a number of factors, the coding language of the project and experience of the developers and test engineers involved may have an impact on the decision making process, a Google search for "test harness for language x" will no doubt turn over a number of options for each language and whilst there’s no hard and fast rule that your test suite and project code language must match, the skillset of the team surely will play a part.
Another major consideration should be around the types of test you want to execute, (unit, integration, system, acceptance etc) as some test harness frameworks lend themselves more towards one or a subset of types. You can of course use more than one test harness if it makes sense for your project with each providing different elements of a test plan strategy: unit tests running on every build and full smoke and functional tests running on release for example.
Consideration also needs to be given to the development methodology being applied - perhaps PHPUnit is a best choice if a purely Test Driven approach is adopted, on the other hand, Behat is a clear winner for Behaviour Driven Development.
I'll leave the last key point for consideration till the end! First, let's briefly review 4 popular test frameworks.
SimpleTestFor those of us working with PHP (and specifically Drupal), there are a number of options. Coupled closely with Drupal is SimpleTest which was moved to core in Drupal 7. It's modeled on the open source SimpleTest unit test framework so those familar with its suite of assertions will be comfortable and will get the extra benefit of helper methods such as drupalLogin(), drupalLogout(), drupalCreateNode() and drupalCreateUser() for establishing fixture[1].
Here's an example of a user login test in SimpleTest taken from the user module and modified slightly for clarity:
<?php /** * User login test. */ class UserLoginTestCase extends DrupalWebTestCase { public static function getInfo() { return array( 'name' => 'User login', 'description' => 'Ensure that login works as expected.', 'group' => 'User', ); } /** * Test that a user can login. */ function testUserLogin() { $user = $this->drupalCreateUser(array()); $this->drupalLogin($user); } }As you can see, tests are expressed in PHP code and SimpleTest provides a number of assertions that can be used.
I won't go into much detail here about SimpleTest as many good blog posts already exist about its use and limitations (duration of test run being a major issue which SimpleTest Clone seeks to address, some have had success with switching to MyISAM for tests and others, along with Drupal Quality Assurance have adopted ramdisk with a mixed outcomes it seems.)
Code Enigma offers high performance Drupal hosting with built in support for running automated tests, see our http://hosting.codeenigma.com/faq for more information or get in touch if you'd like to talk it through.
PHPUnitPHPUnit is a popular open source PHP test framework created and maintained by Sebastian Bergmann which, from its name, is a good choice for unit testing although you can combine it with other libraries, Guzzle and Selenium Server for example enabling browser automation for functional and acceptance testing.
I personally find PHPUnit invaluable and use it on a daily basic, tests are easy to read, write and are quick to run if you're actually doing true unit testing. Of course, that in itself raises a challenge when working with Drupal where dependencies are commonly requested rather than injected. Drupal 8 is heading in the right direction with Mark Sonnabaum leading the introduction of PHPUnit tests in the upcoming release. I recommend watching the video of his recent Drupalcon Portland session on the subject.
A really basic example PHPUnit unit test:
<?php /** * Adds two numbers and returns the result. */ function add($a, $b) { return $a + $b; } class AddTest extends PHPUnit_Framework_TestCase { public function testadd() { $this->assertSame(3, add(1, 2)); } }Once again, tests are expressed in PHP code with PHPUnit providing perhaps a slightly richer set of assertions than you get with SimpleTest.
BehatCreated by Konstantin Kudryashov, Behat is the PHP Behaviour Driven Development enabler for PHP projects - it enables composition of human readable tests (in Gherkin) that Behat turns into executable acceptance tests. This is the beauty and strength of BDD (and Behat), together they provide a means whereby business owners, developers, project managers and testers can frame requirements in a common language, the language of the business domain and from there derive a suite of acceptance tests that indicate delivered value.
The DrupalExtension module provides additional step definitions for some of the basic operations normally performed on a Drupal site, in addition it provides support for regions defined in the theme layer for more accurate querying of the user interface.
I recently gave a talk about BDD and Behat at the North West Drupal user group - you may find my slides and code helpful.
An example feature and scenario:
Feature: Login As a visitor I want login So that I can manage my account Scenario: A user enters their credentials and logs in successfully Given I am on "/" And I fill in "admin" for "name" And I fill in "letmein" for "pass" When I press the "Log in" button Then I should see "My account"Expressed in a structured language called Gherkin, Behat along with the Mink extension can take this feature and turn it into an executable acceptance test without the need to write any PHP code.
CodeceptionCodeception is a PHP framework created and maintained by Michael Bodnarchuk. It enables acceptable, functional and unit testing which are created by expressing context, actions and expected behaviour in simple expressive PHP code.
At the time of writing, Codeception has switch on module support for a number of PHP projects such as Symfony, Laravel, Yii and ZF but unfortunately no-one has written the equivalent for Drupal yet. Keep an eye on Mike Bell and Paul Byrne who have both written very good blog posts about Codeception, Testing with Codeception and Drupal Projects and More testing with Codeception and Drupal projects
An example Codeception test:
<?php $I = new WebGuy($scenario); $I->wantTo('ensure that frontpage works'); $I->amOnPage('/'); $I->see('Home');Tests are composed in simple expressive PHP code.
ConclusionIt's perhaps now apparent that whichever test framework you choose, the end result is much the same: tests are executed either directly against code (unit testing) or against the site itself (functional/acceptance testing through browser automation) and the failures are reported in some way. The key variant these frameworks offer, and in my book, the most important element for consideration is the input. Answering the following pivotal question helps:
How best can tests be expressed for this project and the people involved in its delivery?
Although not explicit, you might want to include the client when you consider the people involved!
1. A fixture is a known application state which tests will run against, establishing a fixture is the work you do to get to that know state, perhaps the creation of a user for example.
Related Service Areas: DevelopmentTeaser: TDD is a daunting prospect for the newcomer, but Chris Maiden explains it's not so hard to get goingCategories: CommentConsultancyDevelopmentDrupal PlanetPrimary Category: DevelopmentTags: test driven developmentagiletestingsoftware qualitysoftware engineeringtddKnackForge: Drupal 7 Form API - Using #states on #markup field
An essential feature of a dynamic site would be to let its users add some contents to it. Often this is done using HTML forms. Drupal offers a rich and relatively simple way to use API for building forms for its Developers. In Drupal parlance it is referred as Form API (or FAPI).
Google Plus One Linkedin Share Button Tweet Widget Facebook LikeWeb Omelette: Cool module: Responsive Navigation
Responsive Navigation is a cool Drupal module that incorporates the responsive-nav.js plugin into your site. In this article I am going to show you how to install and use this module.
drunken monkey: Creating helpful documentation
Good documentation helps both a module's maintainers and its users, and is quintessential for the success of at least more complex modules. That's why you, as a module maintainer, should not put this (admittedly rather unpopular) task off any further but write some helpful documentation rather sooner than later.
On a related note, I just set a good example by finally expanding the handbook documentation for the Search API, and adding some for the Solr search module as well. Go check it out!
Why good documentation paysWhen we talk about documentation, there are of course two sub-categories: documentation for users (site builders/administrators) and for developers. There are different reasons for having both types of documentation:
User documentationUser documentation is very important as a first step because it lets you both attract new and keep old users. Users who first hear of your module and take it out for a spin will usually have little tolerance for things not working as expected or for having to figure out everything by themselves. Sure, supporting such (potential) new users in the issue queue and on IRC help, but having a clear "How to" tutorial, maybe with a list common pitfalls, just makes it so much easier for new users. If someone just wants to try out your module, not sure whether they would have any benefit from it, there will be little incentive to actually try to find help if things go wrong, or if they cannot easily find instructions on what to do after enabling your module.
As a nice side effect, proper documentation will lead to less support requests in the issue queue or on IRC, thus even saving you time in the long run. If you keep the documentation up to date with support requests you've seen more often, users should find what they're looking for there in most cases – and if they don't find the documentation and still create a support request, a simple link to the documentation will suffice.
In some cases, there is already some documentation directly in the source code, either as a README.txt or as Advanced help integration, maybe even plenty of it.
Still, in terms of being able to find it and, e.g., also using it before downloading a module to see what you can do with it, handbook pages on Drupal.org still have the advantage. Furthermore, having documentation in the handbook significantly lowers the barrier for users of your module to get involved and extend the module's documentation (or to keep it up to date).
As long as there is no handbook documentation of your module at all, I'd wager the chances of someone else going and creating some are rather slim.
Just like user documentation, developer documentation helps you attract new and keep old developers. Developers, who can help with patches in the issue queue, implement new features or create and maintain extension modules of your module. In my case, with the Search API being primarily a framework for creating search-related modules, this is of course especially important – but having people active in the issue queue who can fix the bugs they discover and implement the features they request themselves, who can review your more complex patches, etc., is quite valuable for nearly any module out there. Just by someone else reading through your code (if it's a more complex module), a few rough edges will pop up which would sooner or later have led to problems for someone (perhaps you yourself, as the one who then should fix them).
For developer documentation, naturally, source code comments, a proper .api.php file, etc., are very important. Still, none of these can really give new developers the “great picture” of how your module works. They just document single functions, methods, classes and hooks, but there is no general place for documenting how it all fits together. For that, again, I think handbook pages are the way to go.
New/Improved Search API documentationSo, after all the grand words, have I myself lived up to them? Well, no, or at least only very recently. For several years now, there was only some basic documentation for the Search API in the handbook, for the first year or so there was none at all.
However, being asked the same questions over and over in support requests, and recognizing all of the above arguments, I finally got round and significantly expanded the existing documentation:
- There are now a Common pitfalls and a Frequently asked questions section, listing support requests I've received more often over the last years.
- The developer documentation section is completely new. There's still a lot to add, but the two (in my opinion) most important parts are covered: an in-detail explanation of the Search API's architecture and workflow, and documentation about adding custom item types / data sources.
- I moved some of the text from the project page into the handbook – concretely, the extension modules and the related materials. This allows others to easily add to those lists as well, and additionally brings down the length of the project page to just a little over two screen pages.
- Lastly, there is finally also some handbook documentation for the Search API Solr search module, including advice on how to customize the Solr configuration.
Of course, good documentation is hardly ever finished, and there is still a lot to be added, but I do think that this is at least a sound base now so that most users will find what they want to know.
Help still wantedWhile, as the creator and maintainer, I'm certainly quite knowledgable concerning all Search API-related topics, I'm also for the very same reason one of the worst people to judge what needs documenting, what could be unclear, how things are best explained, etc.
Therefore, if you have dealt with the Search API on any level in the past or – better still – want to look into it in the near future, please take a look at the new (and old) documentation, see if everything is clear, what might be missing, etc., and tell me your thoughts in the issue queue.
Or, of course, just jump in and edit or expand the documentation yourself! It's a great place to start contributing, helping others avoid potential problems you've encountered.
Some more documentation projects I have in mind for the nearer future include creating an example module for implementing a custom datasource (possibly by integrating Search by Page with the Search API); and maybe creating a new, up-to-date version of the old Search API screencast. If you've got other suggestions, please leave them here as a comment or create an issue for them.
Image credit: Johannes Jansson/norden.org
Tags: Planet DrupalSearch APISearch API SolrDocumentationKároly Négyesi: Drupal 8 progress from my / MongoDB perspective: update #20
There are a lot of great things happening! Let's first see those that are already in: the config system got back to a saner track by removing the partial import capability and only allowing import of full config trees. This removed manifests which, honestly, I never truly grokked. Also, config import and sync were converted to pluggable services earlier so if someone can figure out how to do partials better then they can do. There was an epic profiling effort made by the Twig team to get the conversion committable -- and then Alex Pott honored them by committing patches one by one instead of rolled together to give them credit. Same with the views rename method patches. Big, big kudos to Alex for this!
Database connections are now serializable. As MongoDB doesn't use PDO, this is only important to us in the way the Database class has been refactored to allow for this.
Entity controllers now can have their dependencies injected (what about entities themselves? see below). Although batch v2 didn't happen, the batch storage is now pluggable (and soon the batch specific tables will be gone completely as msonnabaum points out that the expirable keyvalue storage is fit for it).
On a performance front, let's note that contextual links are now AJAX, making them compatible with render caching. The issue was filed in 2010 and I filed it as "this will never be done although it's rather necessary", so big kudos to everyone fixing it.
Firing hooks during major upgrades were always a problem and we discouraged it but now this will throw an exception (this was mostly my work). This is the second cornerstone on making the Drupal 7->8 upgrade path way more resilient than before, the first one are tests for use cases that were untestable before. Probably it'd been better if migrate happened this cycle, but it didn't so we cook with whatever ingredients we have.
The evented branch of the entity refactor is now dead and won't happen but a lot of that code now lives in the widely accepted "let's move as much logic as possible from storage controllers to entity classes" patch. It even passed once but due to the user entities conversion to the next generation controller it currently fails but I expect it to be fixed this weekend and it's possible it'll get committed soon. This will make replacing entity storage controllers much easier and supporting contrib entities much easier too.
Meanwhile, entity classes themselves are being changed to not be plugins. This makes some sense because, well, there's not much pluggability here you would want to do. I believe this leads to dependency injection of plugins which will be useful now that most of the logic is moving there.
Ps. Let me congratulate two people here. You can't even find msonnabaum among the Drupal 7 contributors core and he is rapidly becoming one of the shaping architects of Drupal, quite for the better. Tim Plunkett of the Views in Core team, the unstoppable coding machine, who can somehow balance like five ongoing patches over 100kb, had only 23 core mentions in the Drupal 7 cycle. I am so glad to see others taking lead.
.VDMi/Blog: Integrate Drupal with Zurmo
Zurmo is the open source, gamified, mobile and social Customer Relation Management suite, build on top of YII PHP Framework and RedBeanPHP. The development is test driven and has a fast release cycle. Zurmo is feature rich, without overloading your screen with options. The best part of Zurmo is that it is gamified, you earn points while doing your work. That makes the usage of Zurmo fun... you simply want to use it... and that solves one of the most heard complains from management of a company: "We have an expensive CRM, but no one uses it".
A Drupal ModuleWe developed a Drupal module to integrate the Drupal Webform Module with Zurmo. The module can be downloaded from the Zurmo project page on the Drupal website. The module builds a connection between Drupal and Zurmo, that utilize the webservices in Zurmo. With a sub-module you can send your webform submissions to Zurmo and create Contacts or Leads in Zurmo. In Zurmo you can send emails with the workflow tool to notify the right employee that a new Lead has come in.
The module is currently in development state. That means that it can be used, but is not complete yet. The Webform sub-module works and is tested in reallife. It needs more testing, more documentation to be released in Beta. In the comming months we will develop further to integrate Commerce (webshop) and Feeds (fetch any object from Zurmo and import it into Drupal).
You can help with the development of the Zurmo module by:
- Test the modules.
- Write documentation.
- Develop a sub-module.
- Supply patches.
Use the Drupal Issue Queue for this project to add your work to the module. You can also request to become co-maintainer for the Zurmo module for Drupal. Help us and let us build together a stable module, so that no one ever needs to copy/paste data!
Badzilla: Drupal 7 - Setting Up Piecemaker 3D Slider with InnoCompany Theme
Subsequent to my earlier blog on installing and setting up the commercial InnoCompany Drupal 7 theme, it is now time to do something useful - set up the Piecemaker 3D slider which is based on Flash animation, with an XML configuration file. Thankfully a lot of the work has already been bundled into the InnoCompany theme and there isn't that much to do. Principally the slider images, captions and links are included in theme configuration, and there are 10 available placeholders which means the carousel may have up to 10 images.
High Rock Media: Drupal 7 Preprocess Tricks: Tips From a Themer
In the course of a day as a Drupal Themer, I need to code a wide variety of functionality into a given site I'm working on. I try to follow Drupal best practices as well and this usually means implementing theme preprocess functions; these become key to a Themer's toolbox. This article is a selection of snippets I've picked up along the way that might help others out. When I first started building with and theming Drupal several years ago, at first I did not see the value of preprocessing but it's turned out to be quite valuable.
Add JS or CSS with a Pattern Match / WildcardThis method is ideal if you want to add special or custom JS or CSS files to a specific path with a pattern match or wildcard. For example I might have unlimited URLs associated with a Taxonomy with patterns such as:
/portfolio/cars/portfolio/trains
/portfolio/architecture
/portfolio/foo
… but then maybe I want to also add this code to some individual pages not associated with the Taxonomy. I can do something like this with a preprocess HTML function.
function MYTHEME_preprocess_html(&$vars) {$path = drupal_get_path_alias();
$pattern = "portfolio/*\nfoo-page";
if (drupal_match_path($path, $pattern)) {
drupal_add_js(drupal_get_path('theme', 'MYTHEME') . '/js/jquery.foo.js', 'file');
}
}
As you can see from the above code, we are adding JS to anything under the path or /portfolio/ but also to a page called foo-page. Note the newline character between the two pattern matches as well as the * which serves as a wildcard. We are also using the Drupal API function drupal_get_ path_alias which returns the alias of an internal path. You can imagine the possibilities using this method which could potentially cut back on the number of scripts being aggregated on any given part of your site.
A CaveatThe one caveat using this method is that you'll want to be sure to add a test to your script instantiation. So for example, in my scripts file, if I am instantiating the above script, I want to be sure to add an if clause, otherwise you run the risk of calling the script when it does not exist on various pages which would in turn throw a nasty error. So you'd want to do something like so:
if($().foo) {// your script foo here…
} Weight, Scope and Group
In certain cases, you need to load a script last or set a specific weight to place it at a specific point in relation to other scripts that are loading. This can be achieved by "weighting" and "scoping." Scope has two possible constants, header and footer which are self-apparent, you can either load the script in the head of the page or in the footer after everything else; there's lots of advantages to this in regard to Javascript. For grouping, typically a themer is going to use JS_THEME but there's also two other constants available, JS_DEFAULT and JS_LIBRARY which would commonly be used within a module context. Below is a sample
function MYTHEME_preprocess_html(&$vars) {drupal_add_js(path_to_theme() . '/js/foo.js',
array(
'group' => JS_THEME,
'preprocess' => TRUE,
'scope' => 'footer',
'weight' => '9999',
)
);
}
Note also that preprocess is set to TRUE as we want this internal script to be aggregated. However, there's some cases where you'd set this to FALSE perhaps in the case of an external JS file. The high weight number would most likely make it load last but it's a good idea to test this with aggregation off on your dev site so you can actually see where and how it loads. Play with the number if you don't get the desired result.
CSS ParametersYou can also weight CSS and it has three group constants available as per the Drupal API page:
- CSS_SYSTEM: Any system-layer CSS.
- CSS_DEFAULT: (default) Any module-layer CSS.
- CSS_THEME: Any theme-layer CSS.
It should be pointed out that the groups themselves have weight so you can really fine tune this using a numbered weight as well as a named group 'weight'.
Browsersif you still develop for older versions of Internet Explorer (gasp!), there's a nice add_css Parameter called browsers which combines with the drupal_pre_render_conditional_comments function. This is also a theme preprocess_html function. For example, if you want to render an IE8 fixes stylesheet conditionally, you could do something like this:
function MYTHEME_preprocess_html(&$vars) {// Add IE 8 fixes style sheet.
drupal_add_css(path_to_theme() . '/css/ie8-fixes.css',
array(
'group' => CSS_THEME,
'browsers' =>
array(
'IE' => 'lte IE 8',
'!IE' => FALSE),
'preprocess' => FALSE));
}
Here we say that we want this to be a conditional stylesheet for less than or equal to IE8 and false for all others and this would render as:
<!--[if lte IE 8]><link type="text/css" rel="stylesheet" href="http://example.com/sites/all/themes/MYTHEME/css/ie8-fixes.css" media="all" />
<![endif]-->
There's plenty of other parameters, options and constants for adding CSS and JS within theme preprocessing functions and I suggest checking out the Drupal API pages, links referenced below. There's your tips from a themer, I'll be back sometime soon with more!
Tags- Drupal
- Preprocess
- PHP
- CSS
- Tutorial
- Drupal Planet
Paul Booker: Write Drupal Logs to Rsyslog
Install rsyslog on your web server (should already be installed)
Enable the syslog module in Drupal
To allow Drupal to log to rsyslog, you have to enable the Drupal syslog module. Syslog is included with Drupal core.
Configure the Drupal module
In admin/config/development/logging , you can select one of the following prefixes for your website:
LOG_LOCAL0
LOG_LOCAL1
LOG_LOCAL2
LOG_LOCAL3
LOG_LOCAL4
LOG_LOCAL5
LOG_LOCAL6
LOG_LOCAL7
If you log one site, it really doesn’t matter which one you choose. If however you have multiple sites running on the same machine, and you want each site to log to a different file, the selection does matter. Eg: site A logs to LOG_LOCAL0, site B logs to LOG_LOCAL1, etc.
Configure rsyslog
vim /etc/rsyslog.d/50-default.confadd the line:
local0.* /var/log/drupal.logThis will log all local0 logs to /var/log/drupal.log
If you have selected local1 in the previous step, you have to replace “local0” by “local1″ in the configuration line, etc. You can name your log file different from “drupal.log”, in fact you can choose any name that hasn’t been taken yet.
Restart rsyslog
service rsyslog restartYou should now cause an error (eg. 404) and see if /var/log/drupal.log has been created and gets filled. If you're having problems check if /var/log/messages gets filled with Drupal log messages. If it does recheck the previous steps and see if you made any mistakes.
Disable dblog
At this point, Drupal will log to both the log system and the regular dblog. You can simply disable the module “database logging” in admin/modules .
Paul Booker: Write Drupal Logs to Rsyslog
Install rsyslog on your web server (should already be installed)
Enable the syslog module in Drupal
To allow Drupal to log to rsyslog, you have to enable the Drupal syslog module. Syslog is included with Drupal core.
Configure the Drupal module
In admin/config/development/logging , you can select one of the following prefixes for your website:
LOG_LOCAL0
LOG_LOCAL1
LOG_LOCAL2
LOG_LOCAL3
LOG_LOCAL4
LOG_LOCAL5
LOG_LOCAL6
LOG_LOCAL7
If you log one site, it really doesn’t matter which one you choose. If however you have multiple sites running on the same machine, and you want each site to log to a different file, the selection does matter. Eg: site A logs to LOG_LOCAL0, site B logs to LOG_LOCAL1, etc.
Configure rsyslog
vim /etc/rsyslog.d/50-default.confadd the line:
local0.* /var/log/drupal.logThis will log all local0 logs to /var/log/drupal.log
If you have selected local1 in the previous step, you have to replace “local0” by “local1″ in the configuration line, etc. You can name your log file different from “drupal.log”, in fact you can choose any name that hasn’t been taken yet.
Restart rsyslog
service rsyslog restartYou should now cause an error (eg. 404) and see if /var/log/drupal.log has been created and gets filled. If you're having problems check if /var/log/messages gets filled with Drupal log messages. If it does recheck the previous steps and see if you made any mistakes.
Disable dblog
At this point, Drupal will log to both the log system and the regular dblog. You can simply disable the module “database logging” in admin/modules .
