Semantic panels is for Panels what Semantic Views is for Views - better control of the markup.
Todays screencast subject is Semantic Panels. If you are new to panels and Page manager, I recomend you to watch Johan Falks screencasts on the suject.
You could also find the screencast at archive.org.
Now that we've passed the Drupal 8 feature freeze, it's a good moment to present some statistics of Drupal core code base evolution.
All the charts are here together in this infographic:
Update. Just to clarify
Drupal 8 core has experienced big changes in the file structure, probably the biggest ones in all Drupal's history, so I wanted to help to assimilate this change in a visual way.
But clearly isn't it enough to understand the full picture of Drupal 8 core changes, and I hope the graphs are not misleading. Please, I encourage you reading Dries, Crell, catch and the other initiative owners to know more about the conceptual and underlying architectural changes of Drupal 8.
Tim Plunkett points me via Twitter to this issue: http://drupal.org/node/1475510 . If this issue gets fixed, then Composer (tool for project dependency management) will take care of downloading the Symfony Components and we won't need them in the vendor folder.
Still, I would consider those components part of Drupal core, but what do you think? Should the vendor subdirectory be considered part of Drupal core or not?
For the sake of completeness I added in the first chart a variant of Drupal 8 core without the "vendor" subdirectory.
For Drupal 8, the slogan of our company #AberdeenCloud has more sense than ever "a virtual clustering platform for Big Drupal"
Adding the ability to comment on a blog is one way of allowing two-way communication with your readers. If your readers have an opinion or question, they'll simply leave a comment on your blog post. If you want to keep comments "clean" and without spam, you'll have to manually approve them. Of course, there are services like Mollom and Akismet that do a great job with filtering spam but some still get through.
Drupal's default comments administration page is very basic and if you want to review and approval comments you'll have to jump between two pages.
The Better comments administration module allows you to preview, approve and search comments on a single page.
In this episode you will learn:
Way back at DrupalCon Chicago the local team created a new track called Core Conversations. The purpose of this track was to focus squarely on the interests of core developers and those interested in keeping up with the bleeding edge of Drupal development. Crazy ideas and wild rants were encouraged, as long as they were focused and discussion and finding solutions. Since then Core Conversations have been a part of every DrupalCon.
Within our company we use Drush and Drush alias files a lot. Recently I wrote a company blog post (in Dutch) about the workflow we’ve set-up and this post is its English translation. For those of you not familiar with Drush, I’ll start with a short introduction. If you are already familiar with Drush and Drush alias files, you can skip to the interesting part.What is Drush?
A lot of Drupal developers use Drush (Drupal Shell) to speed-up their daily processes. After you’ve install Drush locally, you can run tasks on the command-line which you would normally run via the interface. Here are some often used commands:
It is quite easy to create custom drush commands for task that you need often in your daily work. Many contrib modules come with their own drush implementation (for example drush search-api-index to index your site content).What are Drush alias files?
In so-called alias files you describe the server information per website. They contain paths and usernames of all environments of a site (dev, test, staging, live). Here’s an example:
Filename: customer.aliases.drushrc.php. I’ve placed this file in my ‘aliases’ folder within my .drush folder. On Linux you can find it here: ~/.drush/aliaseslimoengroen.aliases.drushrc.php $aliases['dev'] = array( 'root' => '/Users/BarisW/Sites/company.com', 'uri' => 'dev.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), ); $aliases['test'] = array( 'root' => '/var/www/company-test/htdocs', 'remote-host' => 'webserver1.company.com', 'remote-user' => 'username-test', 'uri' => 'test.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), ); $aliases['prod'] = array( 'root' => '/var/www/company-prod/htdocs', 'remote-host' => 'webserver2.company.com', 'remote-user' => 'username-prod', 'uri' => 'www.company.com', 'path-aliases' => array( '%dump' => '/tmp/dump-company.sql', '%files' => 'files', ), );
The main advantage of using alias files is that you can use them to run all the drush commands on external servers. To be able to do this you need SSH access to the external server and that Drush is installed on the external server as well. If you don’t want to enter your password each time you run an external Drush command, you can also add your SSH key to the external server.
Using these alias files I can now simple run a command like this to clear the caches on the production environment:drush @company.prod cc all
Or, to copy the production database to my local machine:drush sql-sync @company.prod @company.dev
Ideal! Optionally, Drush sql-sync can also sanitize the data (to obscure all e-mails and passwords). This prevents developers to store sensitive customer data on their laptops.drush sql-sync @company.prod @company.dev --sanitize How to use Drush alias files in teams?
Extremely handy, but each developer had to enter all the settings from the various local environments in their alias files. The solution we found for this is simple and very effective: Dropbox / SparkleShare or similar.
We created a folder in Dropbox that contains all alias files. We symlinked the alias directory in ~/.drush/aliases to that folder. In this way, each team member always uses the correct data for all the project environments. You can also use these same alias files for your Continuous Integration environment (we re-use them also for our automated deployments using Jenkins).
To be able to do so we had to change one setting: instead of the ‘dev’ alias we use the names of our employees (because each employee runs his local environment somewhere else). So in my case it is now:drush sql-sync @company.prod @company.baris Bonus tip: alias files inheritance
The real fun starts when you start using inheritance within your alias files. For example; we use a ‘localdev’ alias for all local environments:defaults.aliases.drushrc.php $aliases['localdev'] = array( 'target-command-specific' => array( 'sql-sync' => array( 'sanitize' => TRUE, 'confirm-sanitizations' => TRUE, 'no-ordered-dump' => TRUE, 'no-cache' => TRUE, 'enable' => array( 'devel', 'stage_file_proxy', 'ds_ui', 'fields_ui', 'views_ui', ), ), ), ); customer.aliases.drushrc.php $aliases['localdev'] = array( 'parent' => '@defaults.localdev', 'uri' => 'dev.company.com', 'path-aliases' => array( '%dump' => '/tmp/company-dump.sql', '%files' => 'files', ), ); $aliases['baris'] = array( 'parent' => '@company.localdev', 'root' => '/Users/BarisW/Sites/company.com', ); $aliases['eric'] = array( 'parent' => '@company.localdev', 'root' => '/Users/EricM/Sites/dev.company.com', );
This setup ensures that every sql-sync is automatically sanitized, and that a number of dev modules are enabled that are turned off on the live environment (like the devel module).
PS: to use the 'enable' command, you need to copy the sync_enable.drush.inc file from your drush installation folder to your ~/.drush folder.
How do you use Drush alias files in your team? Please share your tips in the comments!Tags: Drupal Deployment drush DTAP commands Planet Drupal
Drupal 7.20, a maintenance release which contains fixes for security vulnerabilities, is now available for download. See the Drupal 7.20 release notes for further information.Download Drupal 7.20
Upgrading your existing Drupal 7 sites is strongly recommended. There are no new features or non-security-related bug fixes in this release. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement.Security information
We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.
Drupal 7 includes the built-in Update Manager module, which informs you about important updates to your modules and themes.Bug reports
Drupal 7.20 is a security release only. For more details, see the 7.20 release notes.
A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.Security vulnerabilities
Drupal 7.20 was released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:
To fix the security problems, please upgrade to Drupal 7.20.Known issues
Due to the nature of the security fix, some sites will require extra testing and care when deploying this release of Drupal core, and several contributed modules require code changes in order to continue working correctly. See the release notes for more information.
It's hard to believe that we're closing in on a year since DrupalCon Denver. It seems like only yesterday that I was loading up on shwag and excitedly talking Drupal to a bunch of amazing and passionate people. And now we get to relive the fun and joy of another North American DrupalCon in a few short months over in the city that is stuck in the Nineties.
In addition to our flannel and neon green fannypacks, we're also bringing a case of proposed sessions. We'd love to crack these open and pass them around to everyone at DrupalCon. Enough with the extended metaphors though. Here's the quick and dirty on what we hope to share with everyone.
Oh, and if any of these stand out as sessions you'd like to attend, then leave a friendly comment on the session page letting the presenter(s) know. Comments are also a great way to contact us ahead of time to swap ideas, and get more information on what the session is all about.Adaptive Content in Drupal
It's been exciting to see how much attention is being given to the way we structure content to adapt across platforms and devices. One DrupalCon keynote speaker will be Karen McGrane, who wrote the seminal piece Content Strategy for Mobile. It's a touchstone text for our company as we work with clients during the Information Architecture process to think about the ways their content will live beyond the page and then structure it accordingly. Joel and I see this as a great follow up to Karen's talk- a time to look at the concrete ways we can put the concepts of Adaptive Content into practice.Dapper Drupal- Custom Tailored Themes
Subthemes are great for leveraging the hard work done by a base theme and customize from there. At some point though, you might want to define those fundamental assumptions yourself. We certainly found that to be true and Garrett and John, with all their front-end swag, will share the lessons they've learned from building the base theme Center and its subtheme sidekick Prototype. Expect to see some great tips and at least one pair of very cool boots.Design Smarter, Not Harder
Every Monday, as we check in with one another on the work we're doing I'm amazed at how much our company is managing simultaneously. The ability to manage multiple projects at a time comes into play in an especially poignant way when a client wants to roll out several related projects together. This approach makes a lot of sense and can be a lot of fun to implement, but can also get ugly quickly. Justin and Jon will share their insights into how to avoid the ugly and deliver those multiple projects like a boss.Making Drupal Meetups and Events Rock
Ever planned a Meetup only to have your mother, an-out-of work clown and your cat Edgar show up? Awkward. Maybe you have a regular meetup, but the villagers are getting restless and you're looking to spice things up. Or maybe you've always wished your town had more going on in the ways of Drupal. Well, if you're interested in planning or improving upon the Drupal events in your neighborhood be sure to check out this panel.
This discussion will feature some great leaders in the Drupal community, including Karyn and Scott. While we all work together, they'll be offering two unique perspectives on this topic. Karyn is a Women in Drupal community leader and Drupal Ladder evangelist, while Scott has been MCing the Denver Drupal Meetup ever since Jason Yee was shipped off to Portland. This is sure to have some interesting and original thoughts batted around when it comes to making Drupal events rock.Standardized Development with Vagrant and Puppet
Oh the time I have lost trying to replicate a problem locally because a site's server is configured differently...If I had that time back I'd be soaking it up in a bubble bath. Anyways, that's what Puppet and Vagrant are here for. No more fiddling with MAMP, WAMP, XAMPP configuration. When you standardize your development environment the angels sing. Get the nitty gritty from Ryan on Virtualizing with Vagrant and Provisioning with Puppet, then go home and get that bath started.Successful Contrib Projects: Some Non-Technical Tips
You don't want to be "that guy/gal" they talk about in IRC with the abandoned project people wish they could use but whose neglect has rendered it obsolete- do you? Do you?!? I didn't think so. There's a lot to know about managing a contrib project beyond the initial code you wrote. Scott will clue you in on how to manage a successful Drupal contrib project in a way that leaves you fulfilled and the people around you happy. That way, when people mention your name in the forums, you'll know it's a good thing.
There are currently 69 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...Module: Webform Event What does it do?
One of the more exciting aspects of working on Project Review Wednesday is getting a quick glance at things that people are working on out in the world. Many modules solve a particular problem, some provide a means to solve a set of issues.
The Webform Event module is a key example of trying to solve a set of problems. Essentially the module provides an event content type, but also signup (or add their name to a queue if the event is full) for the event. Events can be closed by an end date or by a number of participants and the process ties in with several existing modules.Look Useful? Review it!
If this sounds like something you'd like to see readily available on Drupal.org, you should review it and help make that happen.
Drupal community members are supporters of the Drupal Association because they want to support the Drupal project and DA membership is an easy way to do so. When you join or renew, you get more than just good karma, and you give Drupal more than just member funds.Personal blog tags: MembershipDrupal Association
The blank canvas in Photoshop is where many well-intentioned Web redesign projects go to die.
If you want a beautiful magazine ad, then find a talented graphic designer and have them draw up something pretty for you. If you want a rational redesign, you need to start somewhere else.
As defined in the first part of this series, a rational redesign delivers true value to an organization, instead of simply consuming time and money for window dressing.
A little fun this morning. I had a great talk with Jacob Redding yesterday as part of his academic work on open source communities. We talked a bit about the early times of Drupal, including the heady days in Antwerp in 2005 when the ideas for what was to become CCK and then fields-in-core were being explored, debated, and scrawled on whiteboards. I thought I'd share this creation by Steven Wittens. He whipped it up late one night after a long day of architectural discussions. It's been on the wall of my office for years.
John VanDyk, Jonathan Chaffer, and the new fragrance of CCK.Topic: DrupalDrupal History
Given that they really go together, this week we will look at two different hooks: hook_block_configure() and hook_block_save(). Their purpose is to programatically add extra configuration options to the block configuration form: you know, the one with the region and visibility settings.
You did not read that wrong! Yes, Drupal 8 features are frozen, and the massive Drupal 8 Multilingual Initiative is not there to let you even translate a node title or the site name. We made massive amounts of progress with heroic efforts from key contributors, but we are not nearly close to be done yet. Yes, your help is needed! The way the Drupal core release cycle is set up, many things that you might consider features are not classified as such (verified with core maintainers) in the process. Feature freeze means all base features should be in core, however, many things that need to be integrated with these new features are not done yet. Otherwise what would we do for months on still, right? So let's look at the two use cases with this in mind. Start with the bad news!Translate site name
The biggest feature that will still not be native in Drupal 8 is translation of user provided configuration. We still have lot to work on translating shipped configuration. We've worked hard for months to get a configuration schema system accepted so we can have a programatic understanding of the translatable pieces of configuration. We started work on that in 2012 June at Drupal Dev Days, and it took several forked issues, alternate proposals, personal, IRC and phone meetings to get a universal understanding that a configuration schema system is needed in the first place, with the actual implementation not too far from the original proposals, that landed in core. We would have loved to achieve this milestone sooner but that did not work out.
So the sad news is you will not be able to translate your site name or custom created Views with Drupal 8 core only. Drupal 8 core should be capable to translate shipped configuration though, that is email texts, image styles, default content types, default fields, etc. shipped with Drupal core. The text for these should eventually end up on http://localize.drupal.org for translation. You'll need to use a contributed module to translate user entered configuration though (such as user created Views and your site name). Good news is that the underlying schema system and the configuration override system in core (as well as the soon to be committed configuration context system) supports this use case too, so the missing piece is a user interface to be generated for configuration translation. A very early version of that user interface can be seen in http://drupal.org/sandbox/reyero/1635230.
So as of right now you cannot even translate the shipped email texts, but that is a feature targeted for Drupal 8 core (in combination with http://localize.drupal.org as usual for software translation). Translating configuration created on the user interface and not shipped with modules/themes/profiles will need a contributed module.Translate node titles
All right, this is a flat out regression, right? Right! Drupal 8 trades node-copy translation that is native to Drupal 7 (using the Content translation module in Drupal 7), where translating a node creates a new copy of the node. In Drupal 8, the module named the same on the user interface (Content translation) works totally differently. It does not create new copies but stores translations in fields under the entity. This has several advantages. For one, it lets us support all kinds of entity types, for example, fields on users, taxonomy terms, comments, etc. We also provide a neat cross-entity configuration screen to set up all your entity types for language.
Yet, node titles remain non-translatable. The basic reason for that is that node titles are not "fields" on nodes, they are good old properties. Properties do not support multilingual storage natively. We introduced a multilingual property system earlier (for the entity_test entity type), and the integration to other entity types did not yet happen. Why? Well, the more sweeping next generation Entity API conversions are still widely underway. Comment entities are done (with performance regressions that are being worked out) and we are hard at work on nodes. There are still files, users, taxonomy terms, etc. ahead.
And then the multilinugal property conversions can happen on top of the new entity system much easier since that system has built-in support for them. That is still not a trivial task and we'll definitely need all hands possible to achieve.
(Side note: once node properties become multilingual, we also need to provide a migration path in core for the legacy content translation module and remove that module from core for good.)How can I help?
The configuration schema system is easy! We have documentation at http://drupal.org/node/1905070 and a visual configuration browser that applies the schema at http://drupal.org/sandbox/reyero/1635230. There is a huge set of issues at http://www.drupal8multilingual.org/issues/schema to fill in the blanks of schemas where not yet provided or incorrectly written. Tips to help are in the meta issue at http://drupal.org/node/1910624#comment-7088154
The entity API conversions are more involved work. You can participate in the conversion issues at http://drupal.org/node/1818580 - however the process so far has been to attack one type at a time, and nodes are in focus righ now (http://drupal.org/node/1818556). Performance expertise, reroll experience and all kinds of other skills are needed here.So how can you call Drupal 8 feature frozen? And when will it ever be ready?
Reality is features from the point of the development process are not necessarily the same as user's perceptions. While we wanted to get in solutions sooner (eg. targeted configuration schema and context for Dec 1st 2012), their declared belonging to a later development phase does not help to get reviewers and push them harder for inclusion. We are doing our best to not let this affect the eventual readiness of Drupal 8, but in the state we are in, we are not looking at an integration phase where we can sit back and relax.
The current planned deadline for the integration phase (when all entity properties should be multilingual and all configuration should have schemas) is July 1st 2013. There are three big sprints until then that we plan to use to boost our standing (please come and sign up for these):
Sitting around and waiting for later opportunities does not help, so jumping on these issues would be especially helpful. If you have no better idea, start reviewing the configuration schema issues today!A huge thanks once again for all contributors
I'd like to reiterate once again that all the people on the multilingual intiative worked exceptionally hard (in some cases all the way to burning out) to make Drupal 8 as multilingual as possible for you all. The gaps in implementation are not at all due to people doing poor work, they are due to all the uncertainties involved in working on an Open Source project with set goals but heavy interdependencies and lack of resource commitments possible. As well as all the bliss and baggage of making large scale decisions in an open issue queue format.
See http://www.drupal8multilingual.org/team for more information on our team.
Time from time, while doing your custom Drupal code, you may want to load only one or several specific fields from a defined set of entities. So actually you have three approaches to this:
1. Query for entity/node set and load whole entities to get desired fields data. Works, but not a performant solution.
2. Make a direct sql query and get desired fields out of your database. Works too, is the fasted in terms of performance solution, but not too flexible and portable.
3. Leverage EntityFieldQuery() and field_attach_load(). This approach is not as fast as the second, but way more faster than loading whole nodes, it is flexible and uses field caching mechanism. If you'll decide to change your database backend later in the future, let's say to MongoDB, you'll be able to switch without changing a line in your code, neat!Read on about Loading Only One Field From An Entity or Node in Drupal 7
You may ask me: why to have page titles for views?
Views in Drupal, technically, are used to display a list of content. Translating to business language, it will be used for category pages. For example, if you build a shopping website in Drupal to sell mobile devices, you will use "views" to construct the page of Apple products (and also Samsung products, LG products, etc ...)
These category pages are very important (second most after your homepage). You will definitely want they appear on top of Google search results for relating keywords. To achieve it, one of the best SEO practices is to set good focused titles for them.
If you have spent any time with Drupal Commerce, then you're aware of the separation between a product and a product display. The product entity is used for the price, title and SKU, whereas the product display is used to display the product on the front-end.
On most Commerce websites, you have to enter in a product two times. First, you have to create the product entity, and then create the product display. I personally love the separation between the product and product display, because of this Commerce can be used as a proper eCommerce framework.
At any given time, you can take a single node, send it to a translation service like Gengo, review translation and save it back in a single user interface.
Use the provided rules integration to automatically create a machine translation for all languages that your site supports when a news article is created.
Request a translation of all pages from your local translation team, which can use the local translator that provides a separate User interface on the same site.
Do the same for several sites, using a centralized translation server so that your translators only need to access a single site.
Or you can use our directory listing to find the best external translator for your content.
In this episode you will learn:
Jennifer Lampton (jenlampton) of Jeneration Web Development joins Ryan Price and Mike Anello to talk about the most-excellent new theme engine forthcoming in Drupal 8: twig. Jen tells us everything that’s wrong with theming in Drupal 7, and how twig in Drupal 8 will be like riding a pure white unicorn on candy-coated road across an aqua-blue sky so much better. WYSIWYG in core, microcopy, documentation, and some really good picks of the week are also covered in the last ever 2-digit DrupalEasy podcast!