Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 1 day 23 hours ago

Chen Hui Jing: Drupal 101: Customising field markup with Display Suite

5 April 2015 - 5:00pm

A minor complaint I often have about Drupal is the mess of markup it generates. Don’t get me wrong, there are times when all those default classes help when it comes to styling, but there are also times when there is so much nesting it puts Inception to shame. (This is a repeat joke, excuse me if you’ve heard me mention it before.)

This post actually came about because I was trying to include using Display Suite to set up fields as an optional step in the alternative method for accordions post. However, that step ended up being so ridiculously long it warranted its own post.

  1. Install Display suite. drush dl ds -y
  2. Enable Display Suite,...
Categories: Drupal

Chen Hui Jing: Drupal 101: An alternative method for accordions

5 April 2015 - 5:00pm

Accordions are commonly used graphical control element. The Yahoo Design Pattern Library has a good explanation on the purpose of accordions, as well as recommendations on their usage. Accordions are usually used when you have limited space and a long list of related items. Seriously, the Yahoo Design Pattern Library is a valuable reference for all designers. I recommend you bookmark it.

There are a number of Drupal modules that help implement accordions (just google drupal accordion), but they didn’t really fit my particular use-case, so I did my accordions differently. This method was a little complicated and required some jQuery, but fit my use-case well.

Create the Accordion content type

Required modules

Acquia: Streamline your local Drupal workflow with Acquia Dev Desktop 2

5 April 2015 - 4:50pm

Since we introduced the original version of Acquia Dev Desktop, thousands of people have used it to quickly create local Drupal sites on their Mac or Windows PCs. Over the years we have received a lot of great feedback, and so we redesigned Dev Desktop 2 from the ground up, incorporating the most requested improvements. Thousands of users have tried the beta version, and now it's ready for prime time. If you haven't upgraded to the latest Dev Desktop 2, download it now and give it a try. It's free!

What's new in Dev Desktop 2?
  • A streamlined UI makes it easy to work with all your local Drupal sites and their code, database or files from the GUI or the command line.
  • A welcome wizard makes it easy to get started with any Drupal sites including:
  • Built-in Acquia Cloud integration lets you host any of your local sites for free, or sync locally with any of your Acquia Cloud sites. More on this below.
  • The latest xAMP stack components are included including Apache 2.4, MySQL 5.5, as well as PHP 5.6, 5.5, 5.4 and 5.3 so you can easily test your site with multiple PHP versions.
  • Drush 7 is configured to manage all of your Drupal sites via the command line. Click Dev Desktop's terminal icon to start a command line pre-configured with Drush aliases for all your sites.
  • Browse, query and edit your local site's database using phpMyAdmin.
  • Take advantage of Dev Desktop's deep integration with Acquia Cloud to:
    • Host your local sites on Acquia Cloud for free. Dev Desktop takes care of packaging up your Drupal site and importing it. Once there leverage Acquia Cloud's scalability, dev and stage team environments, Git workflow, site tests and more.
    • Synchronize any code, database, or file changes between your sites on Acquia Cloud and your local sites. Easily pull or push your code, database or files between Acquia Cloud and the local site running in Dev Desktop.
    • Add modules to your local file system and then click Push code to add those modules to your Acquia Cloud site and git repository without using Git. Use Git directly for more complex operations.
    • SSH in to your Acquia Cloud environment by clicking the terminal icon. Use drush commands to manage it.
    • When pulling an Acquia Cloud site database locally, use the sanitize checkbox to scrub the local database's user emails and passwords to keep it secure and prevent accidental email blasts while working on your site.
    • Already using Acquia Cloud? Clone any of your Acquia Cloud sites locally to work on them in Dev Desktop and your local toolchain.

And much more
  • Keep up to date with the newest Dev Desktop features and fixes by selecting the Check for updates menu. This is also done automatically when Dev Desktop starts.
  • Take advantage of the command-line installer to script the installation on multiple machines, or embed it as part of another installer that includes your custom Drupal distrobution.
  • Create multiple sites sharing the same codebase using Drupal multi-site.
  • Easily report feature suggestions or issues via the menu Help > Report an issue.
See it in action!

With these improvements Dev Desktop 2 is the fastest way to create Drupal sites on your Mac or Windows PC, and optionally sync them at any time with Acquia Cloud. Download it now, and try it out! There are more great things in the works so be sure to check for updates regularly.

Tags:  dev desktop acquia drupal planet
Categories: Drupal

agoradesign: 3rd party library integration in Drupal 8

4 April 2015 - 5:24am
During my work on the D8 port of our Outdated Browser module, I’ve got in touch with several API changes of Drupal 8. One of them I want to describe now is the integration of third party Javascript libraries.
Categories: Drupal

Jimmy Berry: Drupal testbot command line tool

3 April 2015 - 2:31pm

Are you a developer familiar with the patch submission workflow?

  • load the issue page in your browser
  • add some helpful text describing the patch
  • create a patch file
  • upload it to the issue
  • change the issue status to 'Needs review'
  • wait 20 minutes (at best) to find out if the tests pass or fail with your patch

If the tests fail, then you get to do it all over again, including making possible revisions to the issue summary.

Ever wanted to run the tests while iterating on a change, but are reluctant due to:

  • insufficient local machine resources or configuration to run tests efficiently
  • inconsistent results compared to the official testbot
  • disruption of your 'creative coding moments' due to the patch submission workflow
  • long test runtime on qa.d.o

Well you may be in luck.

What if you could type "drush testbot" to have the changes in your working branch submitted and tested as a patch against Drupal? And be able to view the results in five minutes or less? If this sounds interesting, then install the "drush testbot" command file (see instructions) and take it for a spin.

Suggested usage

If your changes only affects a single module (or a few), then an assessment of your changes can often be had by simply running the tests for that module (or those modules). Once you know that your changes do not break the immediate context, then the entire test suite can be run before posting the patch on the issue queue.

You can do so by including a list of test classes to run (see examples); in so doing you might reduce your response time to a matter of seconds.

Drupal 8 examples

Run the command from the working directory with your code changes. The default test environment for Drupal 8 is mysql 5.5 and php 5.4. In lieu of setting properties on the command line, add them to a '.testbot' file in the repository root directory (i.e. the same directory that contains the .git directory).

Description Command All defaults (without .testbot file) drush testbot Using properties from .testbot file drush testbot Single test class drush testbot --properties='{"classes":["Drupal\taxonomy\Tests\TermTest"]}' Alternate environment and multiple test classes drush testbot --database='mongodb-2.6' --php-version='php-5.5' --properties='{"classes":["Drupal\node\Tests\NodeQueryAlterTest", "Drupal\node\Tests\NodeRevisionsTest"]}' Drupal 7 examples

The default test environment for Drupal 7 is mysql 5.5 and php 5.3. The command syntax matches that shown above with the addition of the 'branch:7.x' parameter to the properties. An example of testing two classes is:

drush testbot --properties='{"branch":"7.x","classes":["NodeQueryAlter","NodeRevisionsTestCase"]}' Instructions

Point your browser to https://github.com/reviewdriven/testbot and see the README file for installation instructions.

Caveat

If our test queue is empty when you submit a patch (and do not specify a list of classes to test), the actual response time for a Drupal 8 patch will be under ten minutes based on existing test suite and available hardware at the time of this writing. If the queue is full, we may not run your patch and will let you know.

Final thoughts

If you have questions, would like to offer constructive comments or suggestions, or want to let us know that you found the tool useful, please post in the github issue queue.

The testbot is provided as a complimentary service to the Drupal community. No financial assistance is received from the Drupal Association (to defray even the hardware costs). Unlike the current testbot which runs on the most powerful compute instances offered by Amazon Web Services, these tests are run on hardware with roughly 25% the processing power yet return results in under half the time.

Tags:
Categories: Drupal

DrupalCon News: Higher Ed Summit: More tickets!

3 April 2015 - 2:13pm

Did you miss your chance to sign up for the Higher-Ed Summit? This first-ever event is so popular that we already sold out. Clearly, higher-ed is a lively crowd!

But worry not, college or university Drupalers: second chances do exist. We will release an additional twenty tickets on April 13 at 12:00pm (Pacific Standard Time).

What will I learn?

Our most suggested topics are:

  • Maintaining brand consistency on sites across campus

Categories: Drupal

Freelock : Drupal 8 is around the corner... time to upgrade?

3 April 2015 - 12:51pm

We're starting to recommend Drupal 8 for some new upgrade projects, with the following notes...

Drupal 8Drupal Planet
Categories: Drupal

Zivtech: Drupal Jeopardy

3 April 2015 - 12:31pm

Drupal 7 Core Site Building Jeopardy helps your team study for the Acquia Site Builder certifcation, or just brush up on your Drupal core knowledge.

We have a weekly "Dev Lunch" on Fridays and lately we've been studying some of the topics covered by the various Acquia certification tests, to help junior staff fill in the gaps of their Drupal skills. This week we mixed it up by playing Jeopardy questions I made up, using a nice web app (jeopardy.rocks) by Muno Creative.  

We had no problem including a few remote colleagues via Google hangout, and we used our regular Hipchat room with team emoticons to buzz in. Congratulations to Team Eggplant (Steve, Dima, Jeff and Victor) who won the game and are enjoying their prize (RC helicopters).

Let us know if your group plays and how you like it. This could be fun for a meetup event as well.

jeopardy.rocks/zivtech

Terms: DrupalDrupal PlanetJeopardyAcquiacoresite building
Categories: Drupal

X-Team: Deep dive into the anatomy of Drupal 8 theming

3 April 2015 - 10:36am

Drupal 8 is the most advanced Drupal ever built and it will surely will be a game changer among other CMSes out there. Part of its strength comes from adopting the principles from other technologies like Symfony, YAML, Twig, and Backbone.js. The theming has undergone many changes since Drupal 7, especially the deep integration with...

The post Deep dive into the anatomy of Drupal 8 theming appeared first on X-Team.

Categories: Drupal

SitePoint PHP Drupal: Install and Integrate Elasticsearch with Drupal

3 April 2015 - 9:00am

In this tutorial I am going to look at the possibility of using Drupal 7 as a content management system that powers another high performance application. To illustrate the latter, I will use the Silex PHP microframework and Elasticsearch as the data source. The goal is to create a proof of concept, demonstrating using these three technologies together.

The article comes with a git repository that you should check out, which contains more complete code than can be presented in the tutorial itself. Additionally, if you are unfamiliar with either of the three open source projects being used, I recommend following the links above and also checking out the documentation on their respective websites.

The tutorial will be split into two pieces, because there is quite a lot of ground to cover.

In this part, we’ll set up Elasticsearch on the server and integrate it with Drupal by creating a small, custom module that will insert, update, and delete Drupal nodes into Elasticsearch.

In the second part, we’ll create a small Silex app that fetches and displays the node data directly from Elasticsearch, completely bypassing the Drupal installation.

Elasticsearch

The first step is to install Elasticsearch on the server. Assuming you are using Linux, you can follow this guide and set it up to run when the server starts. There are a number of configuration options you can set here.

A very important thing to remember is that Elasticsearch has no access control so, once it is running on your server, it is publicly accessible through the (default) 9200 port. To avoid having problems, make sure that in the configuration file you uncomment this line:

network.bind_host: localhost

And add the following one:

script.disable_dynamic: true

Continue reading %Install and Integrate Elasticsearch with Drupal%

Categories: Drupal

Pronovix: 2for1, give to Drupal 8 and get an ROI of 200%

3 April 2015 - 8:30am

Two weeks ago the Drupal association launched the d8accelerate fundraising campaign on Crowdrise. An important initiative — the Drupal ecosystem needs Drupal 8 to come out really soon now. But again an already familiar pattern is emerging: While there is an incredible solidarity between Drupal developers, very little money in comparison is raised from the largest group of beneficiaries of Drupal: the site owners. To be fair, they have been given very little incentive to contribute. It’s great that every dollar has been matched, but what’s in it for the site owners? Even if they don’t do anything, Drupal 8 will probably get finished anyway, right?

Categories: Drupal

Blink Reaction: Ten things you need to know about the Drupal Console Project

3 April 2015 - 8:05am
1 - Why is Blink Reaction supporting the Drupal Console project and who is @jmolivas?

We believe in open source and we believe in the Drupal community. We also believe in helping our enterprise clients achieve outstanding results from their investment in Drupal adoption. Drupal 8 should have a toolset that is specifically developed around its technology stack to get the most out of its incredible potential. We believe the Drupal Console project is a key part of that toolset that will help the entire community achieve outstanding results.

Jesus Manuel Olivas, @jmolivas, is the Drupal Console project lead. In May 2014 we hired him as our Drupal 8 Solutions Engineer to work full time on the Drupal Console as its lead contributor. He spends most of his time maintaining and expanding the project, writing and speaking about it, and gathering input from community members on how it can be used to help individuals and organizations adopt Drupal 8. He's also trained more than a hundred developers in our Introduction to Symfony2/Getting Ready for Drupal 8 series at the last three Drupalcons in Bogota, Amsterdam and Austin. We're offering the training again at Drupalcon LA.

2 - What exactly is the Drupal Console?

The Drupal Console is, at this time, a suite of tools that you run on a command line interface (CLI) to generate boilerplate code and interact with a Drupal 8 installation.

Similar tools include:

  • Module Builder: (Generates Drupal 6, 7, or 8 module scaffolding)
  • Drupal Module Upgrader: (Converts modules from Drupal 7 to Drupal 8; generates static help file with links to relevant change records)
  • Drupal 8 Tools: (Drupal code generator written in bash)
  • Drush (Interact with Drupal installation via CLI, create aliases, create custom commands)
3 - What makes Drupal Console unique?

From the ground up Drupal Console is using the modern PHP practices introduced into Drupal 8, including object-oriented PHP. The Drupal Console isn't a Drupal module, but was built with the Symfony Console Component and other libraries, such as Twig, to generate PHP, YAML, and other file types used in Drupal 8 module development. It is a tool designed for anyone using or planning to use Drupal 8. At the moment, it is used via a CLI, but there are plans to make it accessible through the Drupal administrative interface. Drupal Console works with Drupal 8, and because of the nature of its code base and use of modern PHP, will not be ported to work with Drupal 6 or 7, but instead plans to support Drupal versions from 8 onward.

4 - How does Drupal Console differ from Drupal Module Upgrader?

Drupal Module Upgrader takes a Drupal 7 module and attempts to port it to Drupal 8. While it generates files like Drupal Console does, Drupal Console generates module scaffolding and code based on a series of interactive prompts, instead of analyzing an existing module and converting it to work in Drupal 8.

5 - How does Drupal Console compare to Drush?

There are many similarities between these two tools, but the main difference is how it was built, using an object-oriented architecture and Symfony components. Read more about how the tools are similar in these two blog posts:

6 - What kinds of things can you do with Drupal Console?

Drupal Console provides a number of commands for creating module scaffolding and boilerplate code. For any command, you will be asked a series of questions about what you want. In the case of module scaffolding, files are created and inside these files, classes—complete with namespacing and use statements—are created for you with the naming convention you specified in the command's prompts.

Go to this post for a full list of all the things you can do with the Drupal Console.

7 - Who is the intended audience for the Drupal Console?

Any developer who will be responsible for writing custom code in Drupal 8. Any organization that will benefit from its vast potential.

And because Drupal Console generates boilerplate code—working example code—for the many different types of entities and objects in Drupal 8 core, this tool can be particularly useful for anyone looking to learn or teach Drupal 8 development. The goal of the project is to make a tool for people developing in and learning Drupal 8 that is relatively easy to use.

As such, the following groups in particular could find this tool advantageous to add to their learning Drupal 8 toolkit:

  • Enterprises and other organizations to reduce development time and reduce custom development risk factors.
  • Drupal 8 module maintainers and developers to speed up development and testing.
  • Drupal trainers and consultants providing Drupal 8 developer training.
  • All new Drupal Developers.

As mentioned, there are plans to include a non-CLI interface, to make the tool even more accessible to all site administrators of Drupal 8.

8 - Is it ready now? Who can I ask about it?

Yes. You can send your questions to us here at Blink Reaction or send questions or comments through Twitter at the following accounts: @drupalconsole@jmolivas, @raysaltini, or @blinkreaction.

You can download and learn how to set up the project at drupalconsole.com.

9 - What kind of help does the project need? 10 - What features are planned for development?
  • Verbose code output for learning and leveraging docblocks
  • Complete config:import, site:status, and few a few other commands.
  • Import/export content between Drupal installations
  • Site aliases
  • Generate dummy content, probably using PHP Faker library or Default Content project.
  • Add a GUI for Drupal Console as an alternative to the CLI. This could be especially useful for site builders wanting to generate dummy content or issue site commands without needing to use the command line. It could also be used for code generation in the form of a downloadable compressed file.
Additional Resources Mentioned in this Podcast Project links Libraries or projects Blog posts Bonus!

Check out this Drupal Podcast in Spanish, hosted by Jesus Manuel Olivas and David Flores, two of the maintainers of Drupal Console.

Blink Reaction Drupal 8 Solutions Engineer Jesus Manuel Olivas (@jmolivas) provided a wealth of information and resources for this post. Thanks also goes out to drupalize.me and Amber Matz for their great podcast about the Drupal Console project. We've reused much of their podcast notes for this post. We're grateful for their support. Please be sure to listen to the podcast!

Editied by Ray Saltini, Blink Reaction Drupal Evangelist

 

DrupalBest PracticesDrupal ConsoleDrupal PlanetPost tags: drupal 8Drupal Console
Categories: Drupal

Shomeya: Knowing when to use content types and when to use custom entities

3 April 2015 - 7:15am

Ever catch yourself staring at your editor? Then switching over and staring at the content types overview of your new Drupal site? Then back to the client requirements? And then doing it all over again and again while you face a decision? Drupal content types and fields vs. custom entities. That's the tough decision. The choices you make here will affect almost part of site building to come, but it's so hard to know which to choose.

On one hand, Drupal fields are getting better, faster and more flexible all the time with better integration with contributed modules like views. But at the same time the new entity API with Drupal 7 is more flexible than ever, allowing you to add fields to even your own custom entities. So which route should you go? How can you make a decision like this without second guessing yourself all the time?

Why getting it right is important

While lots of projects can go either way the downsides can make the difference between a successful web project and a maintenance or performance nightmare. Using content types and fields with a complex data model that requires lots of complex queries can hurt performance, but using custom entities when you don't need them can add a maintenance burden when it comes time to upgrade your site or make changes. So how do you make that decision?

Read more
Categories: Drupal

Baris Wanschers: Level up please. We’re not pushing boxes.

3 April 2015 - 3:01am

I have been active in the Drupal world since 2006 as a developer and co-own my own Drupal agency since 2011. I love to attend Drupal events. Both Local events (DrupalJam, Splash Awards) and global ones (DrupalCon). I have attended every DrupalCon since Paris 2009 and I like to attend CXO days and other “management oriented events” too. Last year, I co-organized DrupalCon Amsterdam as the lead of the local team and as the social media coordinator for the @DrupalConEur twitter account.

What I noticed in these past years is that we have grown a habit in the Drupal community of downplaying ourselves by describing agencies as shops. And that is a shame, in my opinion.

It might be a language barrier issue that makes shops sound weird. A shop in my native language is a store where you go to buy bread or a new phone. You come in, you pick a product, you pay, and you leave. It does not match with a process in which you work together with a client for months creating a great solution for their needs.

Shops makes us - Drupal agencies - feel cheap. As if we only have out-of-the box solutions that do not need love and care to be shaped into this great fit for the client.

The truth of Google

Just to compare: when I search Google for a ‘Drupal shop’ I even get more results than when I search for a ‘Drupal agency’ or  ‘Drupal company’! Meaning that we’ve truly grown a habit of using Drupal shop in our communication.

I urge you to stop using the term shop. So: let’s level up. And starting today, please use Drupal agency instead.

What do you think? Is it a language barrier? Comments are more than welcome!

Tags:  Drupal Discussion Planet Drupal
Categories: Drupal

InternetDevels: Our cool drupallers visited Vinnytsia

3 April 2015 - 2:30am

Hurray, we covered the fifth point on Ukrainian map! Its half-jubilee already and we’re not going to stop. So this time we visited Vinnytsia, and everything went really well — as usually, in fact :)

That Saturday morning was hard for our Drupal tourists: they all had to get up very early to leave the city already at 4 AM! But we’re strong and we did it. In the end it was nothing to regret about, Vinnytsia welcomed us very warmly and eagerly.

Read more
Categories: Drupal

KnackForge: Hide "Promoted to front page" and "Sticky at top of lists" options in Drupal

2 April 2015 - 9:30pm
This blog describes how to hide "Promoted to front page" and "Sticky at top of lists" options from node editing page in Drupal. When adding or editing a node, you can see "Publishing options" at bottom of the page which contains 'Published', 'Promoted to front page' and 'Sticky at top of lists' checkbox options. The below image shows you the three options:         The "Published" option is used to publish the content. The "Promoted to front page" option is used to display content in the front page. The 'Sticky at top of lists' option is used to keep the content sticked to the top of front page. If you don't need to show "Promoted to front page" and "Sticky at top of lists" options, then you can hide those options easily. You can hide these options by altering the form either using either hook_form_alter() or hook_form_form_id_alter(). <?php /** * Implement hook_form_FORM_ID_alter(). */ function kf_form_article_node_form(&$form, $&form_state) { // hide promoted to front page option if (isset($form['options']['promote'])) { $form['options']['promote']['#access'] = FALSE; } // hide sticky at top of lists option if (isset($form['options']['sticky'])) { $form['options']['sticky']['#access'] = FALSE; } } ?>
Categories: Drupal

KnackForge: Cleanup of Drupal modules folders

2 April 2015 - 9:30pm

Keeping your drupal modules folder very clear is important part of development. This is the common structure :

  • Contrib - modules from Drupal.org
  • Custom - modules developed for the specific project
  • Features - exported features for Features-driven development

This structure will give better understanding about the modules to other developers and prevent them from hacking the Drupal's contributed modules.

In my case, all the contrib, custom, features were placed in single folder (sites/all/modules/). So the modules folder had nearly hundred modules, its too irritating for any developer. So I planned to move all the modules to their corresponding folders according to the common drupal folder structure. There were many issues after moving all the modules into specific folders.

Drupal's Registry rebuild module gave the opportunity to clear the registry through cli (drush/php) 

  1. Backup your database,
  2. Download and place the registry_rebuild module into your drupal modules folder,
  3. Move all the modules into their corresponding folders,
  4. Run drush rr command to clear all the registry in the database.

After clearing the registry the site is working like a charm, and its a big relief for any developer. 

Categories: Drupal

Wuinfo: Should We Do Something With Core Field SQL Storage?

2 April 2015 - 6:15pm

Drupal field was part of the Drupal core since version 7. The Field extends her ability to build different kinds of systems. Since it is basic units of each entity, it is one of the most important parts of the open source software. But, when it comes to the efficiency of using SQL storage engine, the field can still do better with efficiency. I sincerely believe that we may not afford to ignore it. Let put it under a microscope had a close look at field SQL storage.

Case study:

I had built a patient scheduling system for a couple clinic offices. The project itself is not complicated. I have attached the patient profile picture on this article. We built a patient profile node type on the form. It is not a complicated form, but there are over 40 fields. It is not difficult to set up a nice patient profile node form. I also created appointment node type that connected patient profile and doctor profile with entity reference fields. Using views with exposed filter for the various reports.

It was the project where I find the issue. I am a little bit uncomfortable after I take a close look at the database. Each field has two almost identical tables. I think fields took too much unnecessary database space. I have dumped one of the fields database information to explain my concern.

1) Base table: field_data_field_initial +----------------------+------------------+------+-----+---------+-------+
| Field                | Type             | Null | Key | Default | Extra |
+----------------------+------------------+------+-----+---------+-------+
| entity_type          | varchar(128)     | NO   | PRI |         |       |
| bundle               | varchar(128)     | NO   | MUL |         |       |
| deleted              | tinyint(4)       | NO   | PRI | 0       |       |
| entity_id            | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id          | int(10) unsigned | YES  | MUL | NULL    |       |
| language             | varchar(32)      | NO   | PRI |         |       |
| delta                | int(10) unsigned | NO   | PRI | NULL    |       |
| field_initial_value  | varchar(255)     | YES  |     | NULL    |       |
| field_initial_format | varchar(255)     | YES  | MUL | NULL    |       |
+----------------------+------------------+------+-----+---------+-------+

Base table SQL script:

CREATE TABLE `field_data_field_initial` (
`entity_type` varchar(128) NOT NULL DEFAULT '',
`bundle` varchar(128) NOT NULL DEFAULT '',
`deleted` tinyint(4) NOT NULL DEFAULT '0',
`entity_id` int(10) unsigned NOT NULL,
`revision_id` int(10) unsigned DEFAULT NULL,
`language` varchar(32) NOT NULL DEFAULT '',
`delta` int(10) unsigned NOT NULL,
`field_initial_value` varchar(255) DEFAULT NULL,
`field_initial_format` varchar(255) DEFAULT NULL,
PRIMARY KEY (`entity_type`,`entity_id`,`deleted`,`delta`,`language`),
KEY `entity_type` (`entity_type`),
KEY `bundle` (`bundle`),
KEY `deleted` (`deleted`),
KEY `entity_id` (`entity_id`),
KEY `revision_id` (`revision_id`),
KEY `language` (`language`),
KEY `field_initial_format` (`field_initial_format`) 2) Revision table: field_revision_field_initial +----------------------+------------------+------+-----+---------+-------+
| Field                | Type             | Null | Key | Default | Extra |
+----------------------+------------------+------+-----+---------+-------+
| entity_type          | varchar(128)     | NO   | PRI |         |       |
| bundle               | varchar(128)     | NO   | MUL |         |       |
| deleted              | tinyint(4)       | NO   | PRI | 0       |       |
| entity_id            | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id          | int(10) unsigned | NO   | PRI | NULL    |       |
| language             | varchar(32)      | NO   | PRI |         |       |
| delta                | int(10) unsigned | NO   | PRI | NULL    |       |
| field_initial_value  | varchar(255)     | YES  |     | NULL    |       |
| field_initial_format | varchar(255)     | YES  | MUL | NULL    |       |
+----------------------+------------------+------+-----+---------+-------+

Revision table SQL script:

CREATE TABLE `field_revision_field_initial` (
  `entity_type` varchar(128) NOT NULL DEFAULT '',
  `bundle` varchar(128) NOT NULL DEFAULT '',
  `deleted` tinyint(4) NOT NULL DEFAULT '0',
  `entity_id` int(10) unsigned NOT NULL,
  `revision_id` int(10) unsigned NOT NULL,
  `language` varchar(32) NOT NULL DEFAULT '',
  `delta` int(10) unsigned NOT NULL,
  `field_initial_value` varchar(255) DEFAULT NULL,
  `field_initial_format` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`entity_type`,`entity_id`,`revision_id`,`deleted`,`delta`,`language`),
  KEY `entity_type` (`entity_type`),
  KEY `bundle` (`bundle`),
  KEY `deleted` (`deleted`),
  KEY `entity_id` (`entity_id`),
  KEY `revision_id` (`revision_id`),
  KEY `language` (`language`),
  KEY `field_initial_format` (`field_initial_format`) Here are my concerns. 1) Normalization.

Here is one of the fields' data record.

+-------------+--------+---------+-----------+-------------+----------+-------+---------------------+----------------------+
| entity_type | bundle | deleted | entity_id | revision_id | language | delta | field_initial_value | field_initial_format |
+-------------+--------+---------+-----------+-------------+----------+-------+---------------------+----------------------+
| node        | patient_profile      |       0 |      1497 |        1497 | und      |     0 | w                   | plain_text        |
+-------------+--------+---------+-----------+-------------+----------+-------+---------------------+----------------------+

We have value "W" in the Initial field. One character took 51 bytes for storage that had not included index yet. It took another 51 byte in the revision table and more for index. In this case here, only less than two percents of space are used for real data the initial 'W', and over 98% of space is for other purposes.

For the sake of space, I think we should not use varchar for entity_type, bundle, language, field_format column. Use small int, tiny int or intÎÎ that will only take one to four bytes. The field is a basic unit of a Drupal website. A medium website can hold millions of fields. Saved one byte is equal to multiple megabytes in precious MySQL database.

2) Too complicated primary key

Each field table has a complicated primary key. Base table use `entity_type`, `entity_id`, `deleted`, `delta`, `language` as primary key. Revision table use `entity_type`, `entity_id`, `revision_id`, `deleted`, `delta`, `language` as primary key. "In InnoDB, having a long PRIMARY KEY wastes a lot of disk space because its value must be stored with every secondary index record."ÎÎÎ. It may be worthy to add an auto increasing int as a primary key.

3) Not needed field column

I found bundle type column is not necessary. We can have the system running well without bundle type column. In my clinic project, I named the node type "patient profile". The machine name patient_profile appears in each field record's bundle type column. As varchar (255), it uses 16 bytes for each table record. Let do a quick calculation. if there are 100, 000 nodes and each node have 40 fields, 100,000 x 40 x 2 x 16 = 122MB are taken for this column. Or at least, we use 2 bytes small int that will take only one-eighth of the spaces.

4) Just use revision table.

Remove one of the field's data tables. It may need a little bit more query power to get field data, but it save time when we insert, update and delete field's data. By doing so, we maintain one less table per field, edit content faster. It helps to bring better editor experience and to save on database storage space.

A contributed module field_sql_leanÎÎ addressed some of the concerns here. It still needs a lot of work on itself and if we want other contributed modules compatible with it. After all, it changed the field table structure.

Reference:

1: http://dev.mysql.com/doc/refman/5.1/en/integer-types.html
2: http://dev.mysql.com/doc/refman/5.0/en/innodb-tuning.html
3: Field SQL storage lean solution
4: Patient profile form:

Categories: Drupal

Drupal core announcements: D8 Accelerate Performance Sprint at Drupal Developer Days in Montpelier, France

2 April 2015 - 2:54pm
Start:  2015-04-13 (All day) - 2015-04-19 (All day) Europe/Paris Sprint Organizers:  Wim Leers

http://montpellier2015.drupaldays.org

The goal of this sprint is to uncover the "unknown unknowns" blocking Drupal 8 from shipping, performance-wise. The main focus will be on profiling Drupal 8 under a variety of scenarios to determine the next places to start optimizing, then creating issues for these things so that a wider group of folks can work on them.

We're specifically looking for two types of sprinters:

  1. Finders: Those with profiling experience, using tools like XHProf, Blackfire, and flame graphs, who can analyze profiling data to flag problems and come up with recommendations on optimization targets. Your goal is to keep drilling down until we get to the bottom of what's making Drupal 8 slow.
  2. Fixers: Those who can both work on existing known performance issues, as well as take direction from the first group and create/review patches to improve areas of performance. We're especially looking for those with experience with things like the routing system, bootstrapping, container services, route access checking, and asset handling.

The Sprint Planning Doc has everything you need to know, including stuff to do before the sprint and a nice list of all the outstanding critical issues to tackle.

If you're planning to attend (remote attendees welcome!) fill your details in the DevDays Sprint Attendance sheet.

Hope to see you there!

Categories: Drupal

Drupal core announcements: Drupal core updates for April 2nd, 2015

2 April 2015 - 1:15pm

Welcome to the second quarter of 2015! In the past two weeks, Dries proposed an evolution to Drupal core's structure and decision-making process, the Drupal Community mourned the passing of Aaron Winborn and the Drupal Association announced The Aaron Winborn Award to honor amazing community members in his memory, Addison Berry was elected the 2015 Drupal Association Director At-Large, and lastly, a group to help mentors was formed.

What's new with Drupal 8?

Since the last Drupal Core Update, Drupal 8.0.0-beta9 was released (beta8 was skipped due to installer issues), all known critical issues with the Drupal 8 configuration system were fixed, and the taxonomy term reference field was removed in favor of entity reference fields.

Some other highlights of the month were:

How can I help get Drupal 8 done?

See Help get Drupal 8 released! for updated information on the current state of the release and more information on how you can help.

You can also raise money and/or donate to the Drupal 8 Accelerate grant program to fund Drupal 8 contribution sprints. For more information about how your donations are used, see webchick's detailed analysis.

We're also looking for more contributors to help compile these posts. Contact mparker17 if you'd like to help!

Drupal 8 In Real Life Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.0.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. If you'd like to volunteer for helping to draft these posts, please follow the steps here!

Categories: Drupal


Google+
about seo