Over the past year we have gone through many iterations of our CI system, 3 major versions to be exact (not counting minor updates). During this time we have focused on stability, speed and documentation. These are the major changes that we have found make a huge difference.
I recently started on a project that involves migrating some data from a legacy app & database into Drupal. The old application is a collection of PHP scripts that basically just generate forms, accept data, insert said data into the database, and output it on a website. Pretty simple stuff - there's not a whole lot going on. It was developed long before many of the popular CMS's and frameworks came to be, and probably before people really started paying attention to the character encoding of their data.
I initially began the data migration using Drupal's Migrate module, setting up my new content types and fields, and running through some test imports. Things seemed to go well, until I started scanning the imported data. I started to see some really strange characters like â€™ and Ã©
For the most part, it was pretty clear what these characters were supposed to represent, based on the context they were placed in. I knew right off the bat that it had something to do with character encodings, something that I've never taken the time to truly understand. I made the mistake of thinking "oh this shouldn't take too long to fix", later unraveling my very own "character encoding hell". Do I'll talk more about that towards the bottom of the post, but let's first get an intro character encodings.So what are character encodings exactly?
When textual data is stored and transmitted, it has to first be converted to binary just like everything else. So how is text converted? There needs to be a lookup table matching characters with binary representations. That's determined by the character encoding that is chosen - which can be one of many.
Whenever data is decoded, the character encoding must be known beforehand. Web browsers do this every time you view a website. How do they know what encoding the text is in? The web server tells it, or the browser has to make an educated guess (not what you want!).
ASCII is a very basic character encoding that many are familiar with. It covers the English language along with common symbols and control characters, using only 7 bits to provide a maximum of 128 characters in the set. ASCII isn't really used anymore on the web because of the small number of characters it supports. There are many encodings that do use a full 8-bit byte for each character, re-claiming that wasted 8th bit from ASCII. In America, the most common single byte encodings are probably Windows-1252 and ISO-8859-1. However, no single byte encodings can possibly hold all of the characters necessary to create one "universal" encoding that can support a language like English and Japanese.
UTF-8 is a Unicode compliant character encoding that has become the dominant encoding on the web because it IS a variable width (ranges from 1 to 6 bytes per character, limiting wasted bits) universal encoding. It supports just about every character in every language you can think of. This is very important for the web. It makes multilingual sites easier to manage since you don't have to worry about any localized character sets for each language. Everything uses the same character set.
Most developers should only be dealing with UTF-8 at this point (or another Unicode encoding) and should understand how character encodings are involved in every part of your website or application.Where you need to worry about them Web pages
There are two opportunities to do this - one is the "Content-Type" HTTP response header which is typically set to text/html; charset=utf-8 for standard HTML pages. Your application should set this before delivering the response to the browser. It also includes the MIME type of the response which tells the browser what type of document is being delivered (image, video, document, etc).
The other is a meta tag header <meta charset="utf-8"> or <meta http-equiv="Content-Type" content="text/html; charset=utf-8">. The former is the newer HTML5 version. It's a bit confusing to indicate the character encoding within the data that needs to be decoded, but this is allowed in HTML. Parsers will interpret everything as ASCII until it hits that header (which will work, since the HTML syntax is within ASCII and can be parsed that way) then re-parse the document with the new encoding. The reason it's supported in HTML is to account for any inability to set the HTTP response header which would otherwise provide the same info.
You should be using both methods. Without setting this data, your browser will have to guess, and it may display "garbage" text.
You can actually see what character encoding your browser chose to render the page in, and even force it to render it using a different encoding. It's a handy tool that can help diagnose if a page was meant to be rendered in some other encoding. Chrome, FireFox, and Safari all support this ability (IE probably does as well) in the "View" menu. Form submissions
When data in input in text boxes or text areas in an HTML form, the browser has to encode it before sending it to the server. What encoding does it use to do this? Again, this is up to you to decide. By default most browsers will just use the same encoding that the page was rendered with. However, you can specify this in the <form> tag: <form action="/process.php" accept-charset="UTF-8">. So, while explicitly indicating the character set to encode the data with is not totally necessary, you should do it anyway just in case. If this is not set you risk the browser encoding the data in some random Encoding that your back-end is not anticipating.MySQL connections
Something that is often overlooked is that when you communicate with a database server and you send textual data, you need to indicate the character encodings when sending and receiving data between your back-end and the MySQL server. This makes sense once you understand that any time text is transferred from one place to another, you need to indicate what encoding the text is in. The text does not automatically have a way of indicating what encoding it's in (not universally anyway).
It get's pretty tricky here, at least with MySQL. There are specific settings in MySQL that you can set after a connection has been established that dictate how characters are treated between the client and server. In particular, there are three things that are important to look at:
- The encoding of data you send to the server from the client
- What encoding the server should convert to after receiving the data
- The encoding the server should return to the client when queries are run (a conversion if necessary).
Assuming the data you're sending MySQL actually IS in UTF-8 and the data in MySQL is stored as UTF-8, you'll want all three of those things to be UTF-8. No conversions will actually take place, and MySQL will just pass everything along as UTF-8. To set these values, you can simply execute the statement SET NAMES utf8 after making a connection.
If you DON'T set these values, then MySQL will more than likely default to latin1 (Windows-1252) which is just asking for trouble! A knowledgable developer may recognize that they need to set the character encoding for their web page and forms, and even their database fields (see below). However, if they have a backend script that accepts UTF-8 data from a form submission, but it doesn't tell MySQL it's UTF-8, then MySQL will think it's latin1 when it's actually UTF-8.MySQL text field storage
Text fields in MySQL require you to indicate the character encoding of text fields. Defaults are set up on the server, database, and table level (each inheriting from the former). Since you're telling MySQL a field is a text field, it needs to know how to interpret the raw data it's storing as textual data. Without doing so, you wouldn't be able to query for text or have MySQL compare text fields with one another. You could alternatively just use BLOB fields instead, where the data is stored as binary data and not interpreted in any way. Just keep in mind you won't be able to search on these fields.
From what I can tell (as well as another blog author I reference below), MySQL doesn't change how the data is stored based on the encoding of a field. It just interprets the data differently when reading it. I could be wrong here (if I am, please let me know in the comments). However, you can alter the encoding of an existing field which will re-encode it (actually does change the data) as long as you recognized the limitations outlined in the that article.
For instance, if the string é was encoded as latin1 and stored in MySQL in a latin1 field, it will be stored as hex value E9. You can verify this yourself by running something like SELECT hex(text_field_name) FROM table_name. If you then run ALTER TABLE `table_name` CHANGE `text_field_name` `text` MEDIUMTEXT CHARACTER SET utf8 NULL; MySQL will convert that data from latin1 to UTF-8 for you. If you run the hex query again, you'll get back C3 A9.
In MySQL 5, all the text storage defaults are set to latin1 (Windows-1252) just like they are for the connection settings discussed above. While it's well known at this point that UTF-8 is preferred, I believe that the consensus was that the team behind MySQL didn't want to make the dramatic change to UTF-8 quite yet (though I think this is how it will be in MySQL 6).
Note: the collation of a field has nothing to do with how the data is stored, and instead effects how the data is compared and sorted.What can go wrong
One of the important things to understand is that UTF-8 is a multibyte encoding. This means that the majority of characters are represented with more than one byte (typically two or three), while a traditional character set just uses one byte per character. To really understand let's look at a practical example. Here's the word "Résumé" in two different common encodings:Encoded in Bytes Interpreted in Windows-1252 Interpreted in UTF-8 Windows-1252 52 E9 73 75 6D E9 Résumé R�sum� UTF-8 52 C3 A9 73 75 6D C3 A9 RÂ©sumÂ© Résumé
The normal letters in Résumé are actually the same in both Windows-1252 and UTF-8 (that's was an intentional design choice when creating UTF-8). However, once we get into the special accented e, it's actually represented with two bytes in UTF-8 and just one in Windows-1252.
If your data is sent from the browser to the server as UTF-8 (this is something you as a web developer have control over), is then stored in your database as UTF-8, and finally pulled out of the database and displayed on your website as UTF-8, then will be all dandy. This is how things should be and you have little to worry about.
But let's say that you accidentally removed the charset meta tag from your page template and your web server and app don't set the "character-encoding" HTTP header. Your app will still be delivering UTF-8 encoded text to the browser, but the browser no longer knows it's UTF-8. So the browser guesses. It's possible it will correctly guess that it's UTF-8, but it's also possibly it will guess Windows-1252 as the encoding. If that happens, Résumé will look like RÂ©sumÂ©. Why? Because the é was sent to the browser as C3 A9, which in Windows-1252 translates to the characters Â and ©. If it were correctly interpreted as UTF-8, the browser would correctly translate C3 A9 to é.
Whoops! You catch the error a few hours later and make sure the character set is properly set to UTF-8. No harm done, right? Since the the data didn't actually change at all, there is no data corruption to worry about. The browser now interprets the text data properly as UTF-8. Well, not so fast. Let's say you have a form on your site that accepts comment submissions. Someone submitted the form when the browser rendered the page in Windows-1252. Since most browsers will encode data in form submissions using the same encoding that it used to render the page, the text may be encoded as Windows-1252 and sent along to your backend.
Now you have a problem. Your app is expecting the data to come in as UTF-8 when it's actually encoded as Windows-1252! If the comment contains with the word "Résumé", it will be encoded to 52 E9 73 75 6D E9 instead of 52 C3 A9 73 75 6D C3 A9 like it should be in UTF-8. You may have your database driver setup to indicate that the data you're sending it is UTF-8, and the database field may be set to store it as UTF-8. It's possible that your DB abstraction code throws an exception when it sees that 52 E9 73 75 6D E9 is not valid UTF-8 (which is correct, it's not valid), but it may let it slide and insert it anyway.
After you fixed the website to tell browsers you're sending it UTF-8, let's say someone goes to view the comment that was submitted earlier. Instead of displaying Résumé, the browser will actually display R�sum�. That funny question mark box is the Unicode "replacement character" - which is used when the byte sequence in the text is not supported in UTF-8. E9, the byte that Windows-1252 uses for é, is NOT a valid UTF-8 character. If you're curious why, you need to read more about how UTF-8 encodes text.
You have data corruption now. To fix this, you'd need to find the data entries that were submitted with the wrong encoding and manually convert them to UTF-8. Not a fun task. Yo can't even assume that any text submitted after your bad commit would be encoded as Windows-1252 and is stored incorrectly. Some browsers may have properly send UTF-8 data and it was properly encoded. So if you tried to re-encode all the data after that commit to UTF-8, you may end up double-encoding the valid UTF-8 characters.Conclusion and further reading
Character encodings are not trivial to deal with and it's not terribly fun trying to figure out why funny characters are being displayed on your app or website. Hopefully after reading this you'll take the subject seriously and really begin to understand what character encodings mean to your website and application. Generally you should be using UTF-8 everywhere!.
The application I'm working on has been operating for years without a character encoding set in the HTML pages or form submissions. I've determined that form submission data has been encoded in UTF-8, Windows-1252, and ISO-8859-1, with no definitive way to figure out what data is what. The application does not set the character encoding for the MySQL connection at all, so it defaults to latin1 (Windows-1252). To top it all off, the database text fields are a mix of UTF-8 and latin1 (and the UTF-8 fields may have been "converted" from latin1). It's been frustrating trying to determine what is right and wrong in the database and how to properly fix it because there's both a mix of encodings on the field storage level as well as the input coming into the app. There's no sure fix for any of it.
If you're interested in learning more, these are some great starting points:
- What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text
- Handling Unicode Front To Back In A Web App
- UTF-8 and Unicode Wikipedia
- Getting Out of MySQL Character Set Hell
Brian from Modules Unraveled and I put together a short screencast for people unfamiliar with Drupal. If you are wondering what Drupal can do, or weighing your options in the world of web frameworks and content management systems, here is a common use case: a simple business website.
As you see, it is fast and easy to build a site with Drupal, especially because of the Drupal community, which Modules Unraveled and Pantheon are grateful to be a part. Enjoy the first installment of “The Site I Built.”
About Modules Unraveled Brian Lewis is one of the people making Drupal more accessible. He does a great job of explaining how to make Drupal do whatever you want, even if you don’t code. Brian’s site is a great resource we often recommend at Pantheon.
About “The Site I Built” In this small Drupal world, we get to know each other pretty quickly — we meet at camps, chat on IRC, and work together on sprints, projects and all kinds of other initiatives. It’s a great community, and I am happy to be a part of it. Nevertheless, it is hard not to develop a bit of a drupal-centric worldview.
Here at Pantheon, we are trying to burst this bubble, or at least make it a bit bigger. We know that most people who end up on Pantheon are “in the know.” But we also see people using us to kick the Drupal’s tires, and we know a vanilla Drupal 7 install is not the most compelling first impression. Nor does it hint at Drupal’s flexibility, scalability, and ease of use.
Yes — I said it, Drupal can be easy for new users.
This is our first in a series of efforts to prove it — we are calling it “The Site I Built,” (hoping it conjures up images of your grandpa, walking you down an old country road, and... um, building you a website). We want to spread the word about Drupal however we can!Blog Categories: Education Tweet
We've all figured out by now that the future of the web is for the sites we build to be accessible on as wide a variety of platforms as possible. The magic of responsive design means that one single web page can be viewed on a large range of devices. All of this works very well when we have the time to build our site from the ground up with this in mind, but how can an existing site be adapted to be more responsive? In particular, it's relatively easy to get Drupal to render image fields differently for different screen sizes, but how can existing IMG tags in inline content be displayed at different sizes, and how can a user place images on the page with a WYSIWYG editor without using separate image fields and still have them display correctly? Fortunately, there's an easy answer to this.
While there are several modules that manage image fields (in no particular order, they include Client-side adaptive image, Adaptive Image, Responsive images and styles, and Picture, which is a backport of a Drupal 8 core module), the module Adaptive Image Styles (AIS) does this while also integrating with the WYSIWYG module and handling inline images. Each of these modules has their various strengths and weaknesses; for example, AIS requires you to modify .htaccess to rewrite image paths (the maintainers also provide instructions for use with nginx). But if you want to handle inline images, AIS is probably the simplest.
Once the module is installed and your webserver correctly configured, AIS will make any image with the class "responsive" resize to fit the current screen, using breakpoints configured in the module's administration options. The only thing left to do is to add this class to your image tags. For that, I wrote a patch which defines an input filter that you can add to your text formats. Apply the patch, add the filter to the necessary text formats, and like magic all your images will be resized when necessary! (Make sure you configure this to run after any other input filters.) It's really that easy. Enjoy your newly responsive website!
You might have heard by now that a new version of Drupal is right around the corner. Drupal 8 brings a plethora of changes both under the hood and in user interface.
For example: Symphony 2 Integration, Namespaces, Services, Configuration Management, Views in Core, Twig (theming), Default WYSIWYG, HTML5, Inline Editing, Mobile, Multilingual Improvements and thats just the short list!
During DrupalCon Prague I had the pleasure of giving a presentation about teaching Drupal 8 as part of the core conversations track. In the presentation I talked a lot about providing a good learning environment for people starting with Drupal 8, and removing the fear and uncertainty that are so counter to learning.Related Topics: Drupal 8
Dan Callahan is part of the Identity Team at Mozilla who are trying to solve some of the problems of privacy and security on the Internet that have been hitting the headlines recently. Dan works on the Mozilla Persona project, a system to both replace passwords with verified identities and put that verification under user control, rather than the control of large corporate entities.
Over the past two years, we've built Drupal 8 into what will be the most flexible, future-proof Drupal version ever. Core developers have contributed thousands of hours of work to expanding Drupal 8's capabilities and modernizing our APIs.
We're several months into Drupal 8's API completion phase, and we're releasing monthly alphas as we nail down key APIs, refine the developer experience, and continue vital work on performance. To finish Drupal 8, we must focus on essentials, so I'd like to ask the Drupal developer community to look ahead to the next big step: the first Drupal 8 beta.When does alpha become beta?
Earlier in the year, we announced that Drupal 8's first beta would be released once we had a stable data upgrade path from Drupal 7. At DrupalCon Prague, however, the Drupal core developer team made a bold decision: instead of using Drupal's update.php database update script to convert Drupal 7 sites to Drupal 8 on the fly, Drupal 8 core will instead include a robust data migration API (based on the popular migrate module) to migrate data from existing sites into new Drupal 8 installations. This means that Drupal 8 core will provide reliable, extensible migration from Drupal 6 as well as Drupal 7. We believe this to be important for organizations running older versions of Drupal can reliably modernize their sites.Data migration no longer blocks a beta release
In order to make this important data migration change possible for Drupal 8, the initial Drupal 8.0 release will be primarily intended for building new Drupal sites, and the finished data migration path for existing Drupal 6 or 7 sites may be provided in a later Drupal 8 release, like Drupal 8.1. (For more information on how we might improve the Drupal release cycle after the release of Drupal 8, see the proposal to manage the Drupal 8 release cycle.)
This means that a data upgrade path from Drupal 7 is no longer a prerequisite for releasing Drupal 8.0-beta1. Instead, we will focus on what testers and contributed module authors most need from a Drupal 8 beta: (1) a stable data model and (2) stable critical APIs.Stable data model
A stable data model means that developers should not need to perform data migrations between beta releases of Drupal 8 (except where necessary to resolve critical issues). The Drupal 8 data model includes database schemas, file-based configuration storage, and storage services like the Entity and State systems.Stable critical APIs
To provide contributed module developers with a useful milestone for module porting, beta 1 will include stable critical APIs. These are fundamental APIs that most or all contributed modules depend on, including the configuration system, the Entity and Field API, the Plugin API, and the Routing and Menu systems.
Other API changes approved by core maintainers will continue through the end of the API completion phase, but after the first beta, we will shift from away removing deprecated code and instead retain more backward compatibility layers. (Module/theme developers who wish to go through the porting process only once should wait for the first release candidate.)What issues are blocking beta1?
Drupal core maintainers determine which specific issues must be resolved to meet the criteria above. We have worked with core developers to identify a list of beta-blocking issues. There are currently 48 of these "beta blockers" outstanding. As you can see, there are many difficult problems in this list that need to be solved. We need your help to resolve these issues so that we can release beta1 and expand Drupal 8's reach to new testers and contributors.It's focus time!
While the end of Drupal 8's development cycle is in sight, there's still a lot of work to do. Now more than ever it's essential to focus on the critical issues that will bring Drupal 8 closer to release. If we don't, we risk pushing Drupal 8's release off for many more months. The sooner we create a beta, the sooner we can release Drupal 8 to the world.
Many people looking forward to Drupal 8's release aren't sure how best to help out. I'd like to ask all sub-system maintainers to watch their sub-system's issue queues closely to help new contributors triage issues and fix bugs, especially for beta-blocking issues. I'd also like to ask everyone to review patches carefully, make only necessary API changes, and document APIs clearly. Or, if you aren't able to work on Drupal 8 issues directly, consider sponsoring core developers for Drupal 8 contribution.
Help us make Drupal 8 the best release of Drupal yet by working on our alpha releases and toward a Drupal 8 beta!
If you don't give your site visitors an opportunity to share your webpages, you're missing out on an opportunity for others to hear about your great content.
Drupal has several modules that all you to add buttons to your site that help your visitors share your pages.
In this blog, we're going to introduce the four different options for adding social sharing your Drupal site:
ICS celebrate International Volunteer Day by launching their new blog containing a rather special blog post from Parliamentary Under Secretary of State for International Development, Lynne Featherstone.Blogs: Drupal PlanetTags: BlogBloggingDrupalWeb Design
Free-Templates.lt posted a photo:
via Free-Templates.lt - Free Drupal, Wordpress, Joomla themes bit.ly/IJtai9 FREE-TEMPLATES.LT
International Volunteer Day was established by the UN General Assembly in 1985. Over the years it has become an opportunity for organisations of all kinds to take time out to recognise the contribution of their volunteers.
On this day last year, Ban Ki-moon, the Secretary General of the United Nations said:Personal blog tags: #DrupalVolunteers#IVD2013#ActionCounts
We're getting to the point in the Drupal 8 cycle where the UI's are starting to solidify and we have fairly static markup to write interface tours against.
So to facilitate this, we're going to have a weekly scrum to coordinate pain points, progress and participants.
If you're interested in helping write tours for the Drupal 8 UI or identify and resolve any remaining API issues, please come along to this short meeting (Google hangout).
Here is a how-to for beginners: Install more than 1 Drupal Stack on Acquia DAMP
1. Go to Acquia Dev Desktop Control Panel -> Settings… -> Sites. You will arrive at this page below. Instead of clicking “New…,” which will give you a new instance of Drupal on your current stack, click the “Import…” to create a new install.
2. On the Import site, for the “Site path:” choose “Browse…” On this pop up, search for the stack of Drupal you wish to install and click open. The one I have selected is drupal-7.x-dev.
4. If you are doing a new install, for the Database, select “Create new database” and make a new DB name.
5. You can enter the “Subdomain:” and “URL path” of your choice.
6. After you click “import,” Acquia Dev Desktop will take you to the Select an installation profile page. You will see the page below displayed on your browser. Now you can continue with your regular installation.Blog Tags: drupalstackSection: Drupal
Free-Templates.lt posted a photo:
via Free-Templates.lt - Free Drupal, Wordpress, Joomla themes bit.ly/1kc6fIp FREE-TEMPLATES.LT
The last two weeks have been absolutely ACTION PACKED Drupal 8 core-wise. Let's see if I can remember it all. :)
- The Migrate in Core team had their first core patch land! This provides the underlying architecture for migrations, as well as a variable-to-CMI migration as a proof of concept. Drupal 8 will provide migrations from Drupal 6 and Drupal 7 both. If you're curious to see how it works, read the change notice for a quick overview, and the excellent documentation for more details. BIG congrats to mikeryan, chx, marvil07, bdone, jessehs, mpgeek, BTMash, fastangel, mongolito404, Moshe Weitzman, eliza411, YesCT, dawehner, and cosmicdreams!
- Ding, dong! Overlay module is dead! My ears are still ringing a bit from all of the cheers and applause. :P~ However, rather than the module simply being booted to /dev/null, it has instead been replaced by a nifty "Back to site" button that shows up when you're in an admin context, and takes you back to where you were on your main site:
After extensive usability testing, this solution was found to solve the same "lost context" problem as the Overlay, but with a few thousand fewer lines of code. :) Let us all build nod_ a statue, as well as yoroy, lisarex, and Bojhan from the UX team.
- Alex Pott, single-handedly responsible for almost 50% of the commits in Drupal 8 since he became a core maintainer, is nearing the end of his savings account + Gittip supplements that have allowed him to focus on core full time the past few months. Alex is actively seeking diverse community funding to sustain his momentum independently. If you're a business excited about the new awesome things Drupal 8 will bring, this would be an excellent way to very directly support all of D8 contributors' efforts.
- drupal 8.0-alpha6 shipped, and alpha 7 is due on December 16. Get your patches in now! Here's the current hit-list.
- There were also security releases of Drupal 6 and 7, which we are are in the process of forward-porting to Drupal 8 now. If you can help here to ensure expedient patching, that would be great!
- Performance-wise, remove drupal_add_css(), remove drupal_add_js(), and remove drupal_set_title() are all very close, and fixing these helps to enable render caching, as well as get us to beta 1 sooner.
- If you're interested in learning Drupal 8 OO best practices, the ongoing effort to Convert page callbacks to Controllers and Convert non-controller forms to FormInterface is still happening. Read the docs on how to get started, as well as Form API-specific info.
- The Accessibility team is seeking help with the Green by 2014 initiaitve, which aims to ensure that there are zero accessibility-related test failures by 2014! Read that post for info on getting started.
- If you eat HTML and CSS for breakfast, the ongoing Style Guide for Drupal 8's admin theme effort needs helping hands. See if you can help with any of the issues tagged "styleguide".
- As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.
The best of git log --since "2 weeks ago" --pretty=oneline (232 commits in total):
In addition to the ones mentioned above:
- In PerformanceVille, we're making great progress on removing dynamic page elements to allow render caching to be awesome. Some relevant commits:
- Issue #2115061 by JeroenT, tim.plunkett: Remove direct calls to drupal_add_html_head_link().
- Issue #2102489 by InternetDevels: Remove drupal_set_title in views module controllers.
- Issue #2102449 by amateescu, swentel: Remove drupal_set_title in field_ui module controllers.
- Issue #2102445 by disasm: Remove drupal_set_title in content_translation module controllers.
- Issue #2102369 by vijaycs85, JeroenT, ACF, rteijeiro, -enzo-, tim.plunkett: Remove drupal_set_title in custom block module controllers and entitylist controllers.
See the Where can I help? section for how to help push this area further!
- Meanwhile, in Entity Field API-topia, lots of refactoring that helps bring these APIs closer to solid ground:
- Issue #2047229 by fago, smiletrl, Berdir, effulgentsia, amateescu: Make use of classes for entity field and data definitions.
- Issue #2076445 by plach, andypost, yched, Gábor Hojtsy: Make sure language codes for original field values always match entity language regardless of field translatability.
- Issue #2142549 by amateescu, yched: Support multi-column field types in base tables.
- Issue #1988612 by effulgentsia, yched, Wim Leers, Berdir, Pancho: Apply formatters and widgets to rendered entity base fields, starting with node.title.
- In "API changes you should be aware of" Land:
- Issue #1998638 by damiankloip, dawehner, kim.pepper, cosmicdreams, larowlan, Damien Tournoud: Replace all remaining superglobals with Symfony Request object removed all instances of $_GET, $_POST, and so on with the Symfony Request object. So from now on, just say "no" to $GLOBALS!
- Additionally, Issue #2131851 by tim.plunkett: Form errors must be specific to a form and not a global changed the signature of various form error-handling functions to now take a $form_state argument.
As always, see Change records for Drupal core for the whole list of Drupal 8 API changes.
- From the Isle of Usability, we bring you:
- Issue #675446 by mgifford, RobLoach, amateescu, nod_, longwave, oxyc, rteijeiro, tomyouds, Jelle_S, mcrittenden, Sutharsan, hansyg, Angry Dan, clemens.tolboom, droplet | Dave Reid: Use jQuery UI Autocomplete (instead of our own custom, less-accessible version)
- Issue #1255696 by dagmar, lslinnet, swentel, jenlampton, sun: Move field type modules into separate 'Field type' package (to help break up the modules listing some)
- Issue #1986074 by LewisNyman, Outi, mcjim, edward_or, ry5n, Bojhan, yoroy: Buttons style update. I mean, seriously, just *look* at how awesome our buttons are now!
- And finally, from the Developer Experience-opolis, two big wins to tell you about:
- Issue #2138867 by chx: Allow dangling commas in annotations makes annotations approximately 56,832% less annoying to work with
- Issue #2118991 by Berdir, dawehner: Use abstract service definitions to minimize copy & pasted service definitions is a huge win for the ongoing fight against verbosity.
Blog posts about Drupal 8 and how much it's going to rock your face.
- Vijay Nandwani and Matthew Lechleider put together a great tutorial on how to add a user interface "tour" of your module using Drupal 8's Tour module.
- December 3 was International Day of People with Disabilities (IDPwD), and Dries marked the occasion with a write-up of all the ways Drupal aims to be an inclusive community and platform. Jesse Beach made a sister post celebrating the individuals who help make our stellar accessibility possible.
- As part of their ongoing Drupal 8 Field API series, yched, swentel, and amateescu wrote an article about entity (form) displays and display modes, which does a deep-dive into this API and the improvements it offers over Drupal 7.
- Also in Field API land, check out Ivan Zugec's tutorial on How to Create a Custom Field Formatter in Drupal 8. It demonstrates turning a regular ol' boring link field into a snazzy YouTube player embedding link field!
- For the more design-inclined, Danny Englander wrote a great guide on porting your theme from Drupal 7 to Drupal 8 (Get Twig-gy With It). This goes over the syntax changes, file changes, and more. And best of all, it's pretty short! :)
- Steve Burge from Open Source Training provides an overview of the major changes in Drupal 8 since September in The State of Drupal 8: November 2013. Useful if you've missed a few installments of This Week in Core.
- If you want a more extensive D8 deep-dive, yours truly will also be giving a Webinar on Drupal 8 and what to expect on Tuesday, Dec. 10. Be there or be square! ;) (but please, no heckling. :D)
- DrupalCamp Vienna happened Nov 22 - 24, and Josef Dabernig posted a great summary of the event.
- Among the sprinters was Janez Urevc who organized a Drupal media sprint at DrupalCamp Vienna and wrote up a summary of the results. Awesome work! Janez is running regular media initiative meetings the first friday of every month, which puts the next one this Friday, December 6 at 8 p.m. GMT
(please help me I do not understand time)
- This coming weekend (December 7-8) has been dubbed Drupal Sprint Weekend, there will be sprints literally all over the globe! Check out London, Manchester, Phillipenes, India, Japan, Boston, and New York City! If you ever wanted to get involved in core and didn't know where to start, now might be a great time. :) There's also an upcoming Drupal Global Sprint Weekend on January 25 and 26 so if you missed the boat this time around, be sure to get your local community on the map next time!
- If Drupal 7 is more your style, there's also the D7onD7 virutal sprint, to try and give D7 contrib some extra love.
- Camp-wise, there's Drupagora in Paris on December 5, and DrupalCamp Chicago on December 7.
Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.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. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!AttachmentSize Screen Shot 2013-12-04 at 9.43.31 AM.png15.83 KB
Whether you’ve been handed an existing Drupal site by your IT department or you’re starting from scratch, it’s important for a Marketer to fully understand how Drupal is put together. Understanding the different systems and layers will help you make better marketing decisions and build content that takes full advantage of Drupal.
This blog post may get a little deep, but don’t worry. If you come away with just a few good concepts about Drupal then you’re doing fine and you can always refer back to this post as you need to. (bookmarks are your friend)
These systems are the key parts that make up a Drupal site:
- The Theme Layer sits on top of your Drupal site and has final say on how things look to your site visitors.
- The Taxonomy System gives you the ability to categorize and tag your content.
- The Node System determines what a “content” is and how it is structured
- The User System creates separate “accounts” for each logged-in visitor.
- The Path System allows you to create site structure in your URLs
The best websites separate the look and feel from the content. That is, in theory, what the theme layer in Drupal does. You or your developer can create a Theme that is made up of CSS and a bit of php (don’t worry, it’s easy or mostly done for you in the theme) to create a look for your site.
For those who prefer a more visual representation, here's a great graphic Drupal.org created to explain theming architecture:
According to Drupal.org, "All layers can implement a themed representation of the output, but (with a few exceptions) only within the theming layers can overrides occur." So, making a single change to the theme will carry down to every single page of your Drupal site.
If you need a certain landing page to be different, it’s very easy to create a separate theme file for just one page. (see "page" section on that link)
Prefer that all your blog posts to have a different font size? You can easily theme content types separately.
Want to hide certain blocks on a form page? You can hide certain blocks on a form page.
Here's a 20 minute video from our friends at Drupalize.me that will help you understand all this a bit more: Introduction to Theming Basics.
If you only understand those few things then you're already well on your way!The Taxonomy System
Taxonomies are used to classify and categorize website content. In other words, they allow you to create a tags to help organize your content within your selected content type. Tags are essential to keeping your content organized and well-structured.
They are helpful internally to the editorial team writing articles so they have a place to nest their content on the site, or to the sales team when they're looking for a past example to help sell a lead on choosing their company's services. Tags also help website visitors find what they're looking for. After all, what's the point in having content if the consumers of that content can't find it?
Overall tag categories are collected in what are called vocabularies. Under vocabularies there are terms or tags followed by sub-terms/sub-tags. An example of this would be a events business with several different service offerings they cover on their blogs. So, there could be a vocabulary called Weddings or another called Birthdays or a third called Corporate Events. Within those vocabularies, tags could include venues, decoration, or catering with sub tags like indoor or outdoor. This video from BuildAModule has another great example of leveraging taxonomies to create different content categories.The Node System
You’ll hear the words “Content” and “Node” used almost interchangeably in the Drupal world. A node is nothing more than a group of “fields” (or "chunks" if you listen to Jeff Eaton...and I do) that are related to each other.
In other words, a node is a group of fields that all go together. For example, if you put these fields together:
Then you’d have a blog post “Content Type”. The Node system has an easy method for defining all the content types you could ever want. You might have different fields that are needed for a Press Release:
- Body text
- Breakout quote
- Contact first name & last name
- Contact email address
- Contact phone number
or a company event:
- RSVP form
See? It’s easy to put together exactly the fields you need for almost any purpose. Drupal provides you with a “Basic Page” and a few other types. The Blog module gives you a “Blog” type. And, you can easily create any of the types you want.The User System
You might be the only person logging into your site, or you may have a whole team that needs access to the site, or perhaps your consumers can log in and create their own accounts. The User system allows you to manage these users so that everyone may log in securely and access what you want them to access. You do this through creating roles such as: Administrator, Author, Developer or Subscriber.
Within each of these user roles, you can set up user access permissions and restrictions to certain content types, admin features such as modules or appearance settings.
The Path System
Drupal, unlike most other CMSs, does not force any kind of organization onto your content. All content is equal to all other content. That’s right, every new content that is created lives on the main node level of a Drupal site. For example, node/123 is just as important as node/1 or node/1000001. There is no built in categorization or layers in a Drupal website, Drupal assigns a number to each piece of content chronologically and you must create your own unique URL paths. While this may seem daunting, it creates deep flexibility in how you’re able to lay out your website structure. Moz has a great guide to URL structuring that covers best practices that your site structure should follow for SEO and user experience.
Search engines often look at how a website is structured to determine what silos (groups) of content that exist on a site. The bigger or deeper the silo the more likely that the site is an authority on that particular topic - especially if users find the content useful and spend a lot of time on the site, link to it, and share it on social networks.
An overview of Drupal's architecture and how Marketer's can use it to full benefitdrupal, Planet Drupal, drupal marketing
While understanding the architecture of your Drupal site might be overwhelming at first, understanding and utilizing these systems will help you create marketing content intelligently that creates a powerful impact. Take a look at your own site, use this post for reference, or bookmarkt it for later. Have questions? Hit us up in the comments, we're always happy to help.
In the world of content strategy, spreadsheets are a critical tool for planning and communication. In particular, content types are often defined and refined in spreadsheets before they're committed to code or CMS configuration.
It is a very common usecase to display a list of nodes on a page, and one or more blocks that give you the ability to filter by tags or categories. You might encounter such a use case on a "blog posts" or "event list" page. And it would be nice if the filtering wouldn't require a full page reload, but rather just inquire the server for new information, and update the list of content via AJAX.
Fortunately creating a list of posts is easy with the Views Module, and you can also make an exposed form block which will contain the exposed filters for tags and categories.
A problem arises when just the Views module is used: it only has support for displaying taxonomy terms (we use them for tags and categories) as a select list. A module that helps us solve this is Better Exposed Filters. It has support for displaying taxonomy terms as a select list, checkoxes/radio buttons, link list, and hidden values.
First a content type "Blog" should be created with two taxonomy fields for tags and categories, and any other relevant fields. The fields can be either term or entity references.
The next step is creating a view that displays blog items. After configuring all the relevant blog settings, the two taxonomy fields should be added as filters.
And afterwards, they should be set as exposed.
Once that is done, assuming the Better Exposed Filters module is installed, the exposed form type should be changed to BEF, and the form can also be exposed as a block.
The last step is changing the BEF settings for the taxonomy fields to be displayed as links.
Once the view is saved and previewed, the list of blog items should be displayed, the exposed form should appear with two sets of links for tags and categories, which once clicked will filter the results to display only posts with the respective tags or categories.
Unfortunately, even if "Use Ajax" was ticked, the filtering will not work via Ajax. This is a known open issue of Better Exposed Filters at https://drupal.org/node/1268150, that still isn't fixed, with the most relevant patch being in comment #81 against the DEV version of BEF.
The patch can be found at https://drupal.org/files/issues/filter_links_ajax.patch, and also in the issue queue at https://drupal.org/node/1268150#comment-8210373.
Once the patch is applied, clicking on the taxonomy links should filter the view via AJAX properly.Language English Tags: DrupalCheck this option to include this post in Planet Drupal aggregator: planet
Recently we have found many of our prospective clients asking us “How are you involved in the Drupal.org community and what do you give back?” which we think is a great question, because it means not only do our clients understand the importance of community contribution, but it means they’re also passionate about working with suppliers who understand the importance of contributing to the Drupal community which is what helps Drupal grow as a platform.
This is important for everybody involved, as many people could argue reasons for and against using different CMS’s, but at the end of the day it’s the strength of the community that really sets Drupal aside from other CMS’s.How do you begin getting involved in the community?
When I was first introduced to the Drupal community I assumed it would be hard to get involved since my initial assumptions were that submitting Modules and patches was the only way to contribute back to Drupal, and since I’m not a back-end developer I thought I’d struggle to get involved here.
Soon enough I found there really is something for everyone, no matter what your skill set is. I began by helping out in the content queue, more specifically by reviewing Marketplace listings. After a couple of months I was given a webmaster role, so I now feel I have my own responsibility within the community! Find out how you can help content moderation here.How does Microserve give back to the Drupal community?
Here is a list of what we have given back to the community and advice on how you can get involved too:Sponsorship/Association
The Microserve team attended our first DrupalCon in Prague this year, and as part of this step we also sponsored the event at silver level. We feel it was a great decision and hope to do the same again next year at Amsterdam, hopefully at a gold level. We would highly recommend it to other agencies, if not for the experience alone. See why you should sponsor here.
We are also Drupal Association Organisation members.
As a Drupal Development Agency we are one of many Supporting Partners that help make it financially possible to maintain and improve drupal.org.Global Training Day Initiative
When we began offering Drupal Training as a service we thought it was only right to host a Drupal Global Training Day. These days are free or low cost training events which are aimed at users who are new to Drupal. We thought the event was a success and was a great boost for Drupal in our local community which helped inject confidence into a variety of users who were uncomfortable with Drupal before attending the event. More information about the day can be found here.Modules/Patches
We have improved modules by submitting patches and helping within the issue queues, we have also submitted a number of our own modules:
Fast database logging and Extended block visibility by Mark Pavlitski
TTR Configurable Widget by Saemie Chouchane (see the accompanying blog post)
Textmarketer SMS Integration by Simon Dix
Who Sends API by Darren Whittington
After submitting Textmarketer SMS Integration, Simon wrote a blog on his experience throughout the submission process. Read it for instructions and tips on how you can submit your first module if you haven’t already.
Textmarketer SMS Integration and TTR Configurable Widget were initially based on features of an existing client project, and with the clients permission we extended this functionality to create modules which other members of the community would find useful. When appropriate we discuss community contribution with clients if we spot any functionality which we think would be beneficial to the community during a project.What else is there to do?
Want to get involved in the Drupal Community too? There are many other ways to get involved in Drupal which we haven't covered above, so you can be sure there will be something to suit your skillset.
Native in a non-English language? Why not help with Drupal translations.
Maybe you're a designer and the thought of technical contributions has deterred you. In that case why not help out with Usability, which is a key part right now with the release of Drupal 8.
How about marketing if this is your area of expertise?
However you choose to contribute it is all beneficial to the Drupal community and you should be proud of your contributions however large or small they may be. It's the users who make up the community and without contribution Drupal wouldn't be what it is today. We will continue to contribute wherever is possible and we hope anybody reading this will do the same!
Microserve are listed as just 1 of 10 drupal.org recognised Featured Service Providers within the UK. You can see our listing here to see more about us and find out about our individual team members - https://drupal.org/marketplace/microserve