01 Feb 2015
You have built an application where there was a taxonomy or options field with more values defined in them than what was really being used after release. And these fields are being used as exposed filters in a View. This basically means that you end up with an option in an exposed filter that yields no results when selected. Not a good UI behaviour, and confusing for the end user.
01 Feb 2015 6:00am GMT
31 Jan 2015
When I first wrote Ubercart's Cart module, we knew we were going to support both anonymous and authenticated shopping carts and checkout. The decision came at a time when there wasn't consensus around the impact of forced login on conversions, but we knew we wanted it to be optional if at all possible. Additionally, for authenticated users, we wanted to preserve items in their shopping carts so they would see the same items when logging in from multiple devices or across multiple sessions.
This resulted in a small conflict that we had to figure out how to deal with: users could have items in their authenticated shopping carts but browse the site anonymously, create a new shopping cart, and then log in. What should happen to the items in their authenticated carts vs. the items in their anonymous carts?
There are three basic resolutions: combine the shopping carts together so the user still has a single shopping cart, remove the items from the previous session and leave it up to the customer to find them again if desired, or retain the old shopping cart but ignore it until the customer has completed checkout for the current cart. In Ubercart, I chose to combine the items, but in Drupal Commerce I changed course to retain the old cart but, from the customer's point of view, treat that anonymously created cart as the current cart after login.
We got some push back for this decision, but ultimately I didn't change the default functionality of Drupal Commerce. We just made sure there was an appropriate hook (hook_commerce_cart_order_convert()) so developers could alter this behavior on a site-by-site basis as need be.
From the merchant's standpoint, the thinking behind combining carts goes that you don't want customers to forget they intended to purchase those products in the past. However, from the customer's standpoint, suddenly having additional items in the cart after logging in during the checkout process is quite jarring.
In fact, I've been bitten by this behavior when shopping online at Barnes & Noble. Weeks prior to placing an order, I had put a Wheel of Time novel in my shopping cart but eventually bought the book in store. When I came back to the site to purchase a gift for my wife, I used a login button on the checkout form to quickly reuse my previous addresses and payment details. Unbeknownst to me, the website combined my old shopping cart with my current one such that my "quick checkout" experience made me accidentally order a book I already owned! I then had to spend 30 minutes with customer service canceling the order and placing it afresh just for the book I actually wanted.
That experience confirmed in my mind we made the correct decision not to combine carts automatically. As eCommerce framework developers, we have no clue where a developer might like to integrate login during the checkout process. Best to let them decide if it's safe to do something with those previous cart items instead of silently making the decision for them.
That said, I believe we can improve the experience. Right now, Drupal Commerce retains the old shopping cart order, and after the customer completes checkout they'll see the previous shopping cart as their current cart. This can be confusing as well! My ideal situation would likely be a user interface component on the shopping cart page where customers can see items they had added to their carts in previous sessions, giving them the option to add those products to their current carts. If they decide not to, I don't see any harm in then just deleting those historical carts and moving on.
There's always room for improvement.
Photo credit: alphageek
31 Jan 2015 7:06pm GMT
Sometimes, diving in to try and help work on something in an open source project can leave you feeling stupid, lost and confused. Generally, you'll find you are not alone. Sharing the problem, and the solution when you find it, can be helpful to build your own understanding, but also might help others too. So, just in case I'm not the only one feeling lost and confused about why the path / route / link issue in Drupal is so complex, I thought I'd share some of my confusion and a little ray of light that might help unravel this tangle of related terminology.
In the Drupalverse, we use IRC to connect with each other. So I popped into channel and asked:
Can someone describe how drupal uses these terms? route, path, url, uri, link, menu item - or point me to a reference?
Angela Byron generously responded with a rough outline of definitions, which I've fleshed out a bit below with some references.
"this URL goes to this PHP code, and can only be accessed by these kind of people."
As far as I can tell, this is a relatively new concept for Drupal with routing and controllers, replacing the hook-menu system we had previously. Here's a couple of references that might be helpful if you want to build a deeper understanding.
Uniform Resource Locator eg. "https://www.drupal.org/community" It's generally the address we use to find content on the web.
Uniform Resource Identifier is often confused with URL because it's so similar. See the URI wikipedia page for more information. I'm not sure if or how Drupal distinguishes between the use of URIs, URLs and URNs (Uniform Resource Names), but let's save that yak to shave on another day.
The Build a module team made a video that describes the difference between a URL and a URI
What the difference is between a URI and a URL (a Drupal how-to)
The path is like a pathway to find content eg. admin/content but because it can be an alias, it may not actually represent the location of a file on disk, which helps lead to some of the complexity under the hood in Drupal, and the confusion about when to use http://example.com/blog/yakshaving, /blog/yakshaving, or node/5
<a href="/foo">foo</a> - This one seems pretty straightforward - it's the HTML markup used to point to a URI or path.
A link in a menu - which could be pointing to a route, path or URI.
Hope that helps you, it certainly helps me to lay it all out like this. And, just in case you're wondering how I fell down this rabbit hole, this relates to a series of critical issues holding up the release of Drupal 8. If you can help, please get involved or buy a ticket in my chook raffle to help fund the Drupal 8 Accelerate initiative.
31 Jan 2015 1:29am GMT
30 Jan 2015
The Drupal Association is thrilled to announce the addition of four new staff members. As part of our goal to increase Drupal adoption and provide the community with strong support and advocacy, the organization has been growing at a rapid rate over the past year. Now, we're welcoming four new staff members into the fold. Please help us say hello to Elise, Lucia, Rachel, and Tim!
Elise Horvath, Operations Team, Operations Coordinator
Elise (EliseH1280) is joining the Operations team as an Operations Coordinator. She will manage key details of the Drupal 8 Accelerate program, will manage the Drupal Store, will assist Operations with any accounting needs, and will assist the board of directors by managing meetings and schedules and taking meeting minutes. Prior to joining the Association, Elise worked in logistics and operations for scrum training services. When not working, Elise enjoys spending time with her fiance, watching movies, cooking and baking, riding her bike, and going to Disney World whenever she has the chance!
Lucia Weinmeister, Revenue Team, Sponsor Fullfillment Coordinator
Lucia (lweinmeister) is the Association's new Supporter Fulfillment Coordinator, and will be working with the revenue team to ensure that all our Supporting Partners, Hosting Supporters and Tech Supporters get the most out of their sponsorships. Lucia is one of three Austin, TX-based Association employees, and comes to the Association with a marketing and advertising background. Lucia was born and raised primarily in Mexico City, is fluent in Spanish, and enjoys reading, running, doing Crossfit, cooking, and chasing around her two sons, Bruce and Leon.
Rachel Rivera, Revenue Team, Junior Account Manager
Rachel (rayn1ta) grew up in the San Francisco area and spent four years living outside the US in Latin America, Asia, Africa and Europe. She has worked as a ski instructor, English teacher, and digital marketer. In addition to learning foreign languages, she enjoys yoga, hiking and scuba diving. As a Junior Account Manager with the Drupal Association's revenue team Rachel will focus on identifying and satisfying the needs of awesome Drupal Businesses.
Timothy Constien, Community Programs, DrupalCon Sponsor Fullfillment Coordinator
Tim (timconstien) is joining the Association's Community Programs team as a DrupalCon Sponsor Fulfillment Coordinator. In this position, he will be ensuring that DrupalCon sponsors enjoy all their benefits and receive top-quality service before, during, and after the convention. Tim is a graduate of Oregon State University, and most recently worked to support the sales and marketing departments at a national radio group based in Portland. In his free time, Tim enjoys exploring: Whether he is finding new pubs to shoot pool at, finding the new best food joint, exploring new tree runs to snowboard through, or road tripping to the next music festival, he is always on the go.
Please help us give a warm welcome to our four new staff members. It's great to have you on board!
30 Jan 2015 9:06pm GMT
We're always on the lookout for great sites built with Drupal Commerce, our truly flexible software that's changing the face of eCommerce one site at a time.
Pam Kerr is one of New Zealand's leading independent jewelry designers. Her company - Pam Kerr Designs - had a Shopify site that served retail customers well, but it didn't meet their growing B2B needs. With the help of Blue Fusion, a New Zealand based web design and development chose Drupal Commerce for its flexibility, power and customizable user interface.
For more information, check out the full write-up DrupalCommere Showcase
To see Drupal Commerce sites we've Spotlighted in previous weeks view the Other Spotlight Sites
30 Jan 2015 1:32pm GMT
Welcome to 2015, the European Year for Development
Last Thursday - Jan 22nd - President Michael D. Higgins launched the European Year for Development at Dublin Castle, saying that "2015 is a seminal year for the future of human development".
30 Jan 2015 11:48am GMT
I quite often use Mollom to prevent spam submissions on contact and comment forms. It works pretty well, but some spam still gets through.
An alternative anti-spam technique is to require a Bitcoin dust transaction before an unprivileged user can POST a form. The value of such a transaction would only be about $0.001 USD. For a non-spammer this cost is fine, but for a spammer this is enough to make it totally uneconomical as they need to send out millions of posts.
Coin Tools already has a Bitcoin payments system. When viewing a form, a new payment is created for the minimum amount possible. In the latest Bitcoin reference implementation the smallest output is 546 satoshis. However, many wallets still use the old value of 5460 so that is what is used.
The form's submit button is hidden with CSS (it still needs to be in the DOM for the form to function correctly) and a clickable QR code for the payment is put in its place. Coin Tools payments are BIP 70 compatible so a payment can either be satisfied by a direct POST from the wallet to the Drupal website, or the wallet can broadcast the transaction through the Bitcoin network (slightly slower).
When the form is submitted it is also verified on the server that the payment has been completed.
Here is a video of it in action.
Of course, this technique requires that the user has a small amount of bitcoin. For a website not targeting the Bitcoin community it would not only prevent spammers it would actually prevent everyone from posting. As Bitcoin usage increases this technique will be able to become more commonplace.
It has been proposed before that web browsers should have Bitcoin SPV wallets built-in, e.g. for paywalls. If a payment is required an "HTTP 402 Payment Required" response would be generated. In that situation it would make sense for the browser to prompt the user before a payment is made. For the spam filter this could just happen automatically. The transaction could actually just be included as part of the POST to submit the form.
Because the transactions are for such a small amount it may not be economic to spend the received funds as large miner fees would be required. It might be simpler to just generate a random Bitcoin address for each payment. This means that you don't have to have a wallet on the server and could just use Chain to check if the payment has completed.
If a double-spend on a comment submission was detected after it had been accepted, the post could be deleted. For email submissions, they could be delayed a few seconds to be sure there is not a contradictory transaction floating around.
Even without implementing these protections, double-spending wouldn't make sense for a spammer.
Could a spammer double spend and avoid paying the dust amount? No - double spending is extremely expensive so it would be even worse value for money than just paying the dust amount.
Could a spammer simultaneously broadcast many transactions that spend the same outputs to many different forms and websites? In theory this might be possible and some of the forms would accept the POST before realising the transaction is a double spend. Spamming multiple forms on the same website simultaneously would be impossible because the website would be connected to just one Bitcoin node. If this did become an issue the fee required to POST could just be increased to make it uneconomic.
Of course, it may be desirable to actually charge a larger fee for the purpose of generating revenue. The admin interface could be extended to allow a configurable amount.
30 Jan 2015 10:49am GMT
In this week's episode Addison Berry hosts Greg Anderson, one of the Drush maintainers, and Juampy Novillo Requena to discuss Drush. We start off by explaining why Drush exists and some cool things about it. One of the big hangups people have with Drush is installation, so we talk a bit about that, and how it is easier now with Composer.
- Drupal 8 Survey
- Automated Testing in Drupal 7 with SimpleTest video series
- DrupalCon Los Angeles
- Drush website
- Drush for Developers book
- Drush 7 Stable Release planning issue
- Drush Commands with Composer issue
- Composer website
- Packagist website
- Drushify project
- The Wonderful World of Composer video tutorial (FREE)
- Introduction to Drush video series
- Coding for Drush video series
30 Jan 2015 10:29am GMT
My first year as a Sysadmin
This blog post is a short story of how I started working for a Drupal company, some of the things I've achieved during my first year in the industry and my impressions of working with a Drupal agency as a sysadmin.
Before I pelt you with details of my first year as a sysadmin, I think I should give you a little information about myself. I'm Emlyn, 23 years young and based in the UK...the West Midlands to be a little more precise.
I graduated from Coventry University with a 2:1 in Games Technology with the hope of becoming a games programmer. However, after graduating, I noticed my portfolio fell far short of other students on my course, and, I'll be honest, that bummed me out.
That was when I was approached by my cousin, Jamie, who works as a Systems Manager for Code Enigma, with the prospect of training to become a Junior Sysadmin. I gave it some thought; I had always been interested in Linux systems and wanted to know more about them. In fact, one of my modules at University was Operating Systems Security and I thoroughly enjoyed the assignment we were given where we had to create a shell script that provided the ability to display working processes, navigate a directory, list online users, amongst a few other things. So, I accepted the offer of a three month internship, which started in October 2013, which then turned into a permanent position in January 2014, and I really haven't looked back since!
As with every new job in a new field, training is required. For me, this was two weeks in Cardiff with Jamie, trying to learn as much as possible before working from home by myself. It was daunting, I'll be honest. I knew there was so much to learn in a very short space of time. Perhaps I put too much pressure on myself; no one expected me to become an expert in just two weeks!
On the very first day of my internship, I was given the task of 'building' a new server which would serve as an internal server. So, my first lesson was in Puppet and how to use it to provision a new server semi-manually. This blew my mind! A few simple-ish (well, now I think they're simple-ish) steps and Git pushes later and a new, usable server was up and running. Let me go back on myself, my first lesson was in Puppet and Git. One interlinked the other, and vice versa.
In a sense, I was thrown in at the deep end, given tickets to work on myself. Jamie pointed me in the right direction and gave me hints and tips that aided me in my work. In all honesty, his method of training me was brilliant, perfect. I'd try the work assigned to me first, and ask for help when I needed it.
Over the course of the two weeks, Jamie never showed any impatience or annoyance at what I was doing, even if I did something completely wrong or didn't understand what had to be done. He taught me an important part of being a sysadmin: patience, especially patience towards clients. I had to understand that the client may not know as much as me, even though I'd only been in the industry for two weeks myself!
Over the course of my three month internship, and in fact the following nine months, my training never really stopped. I was learning new things every single day, all the while fine-tuning my newly acquired skills. Another important lesson I learnt during my first year as a system administrator was that I will never know everything there is to know in being a sysadmin, there will always be something new to learn.
Working from home
Being given the chance to pursue a totally new career and develop new skills was fantastic and an opportunity I couldn't turn down, but what put the icing on the cake was that I'd be working from the comfort of my own home. However, I realised that I was going to have to be very disciplined, even more so than I normally would. It dawned on me that my fellow colleagues would be trusting me to work efficiently and I did not want to let them down by being slack just because I was working from home.
Working from home has its advantages, as you can imagine. No suit and tie and no long commute to work every morning. So there's not a mad rush in the morning and I don't have a busy office environment around me to distract me from my work. However, I am alone (as are my colleagues), which means not being able to walk up to them should I have a question or concern and not being able to go for a drink or food after work. But, these disadvantages, I feel, are out weighed by the advantages of working from home.
Running a distributed company can be quite challenging. My boss, Greg, is currently working on a series of blog posts in which he goes into detail about being Spread About. It's well worth a read.
What was I expecting?
I'll be honest, I didn't know what the job was going to be like! All I knew was that I was going to be learning a lot in a short space of time. From the email conversation I had with Jamie before starting, I had a feeling it was going to be all hands on deck. A lot of the time, I've been kept busy all day dealing with several different clients, all wanting different things done. Other days, it's been a little less busy and I've been able to spend a bit more time on each task.
Surprises! Of all kinds of variety
I'd be lying if I said I hadn't been surprised by anything. I think what surprised me the most in my first year, and what still baffles my mind today, is the sheer number of tools and software available to a system administrator. For example, we use Percona as our database of choice, but we could use MongoDB, or MariaDB. Then there are multiple database caching systems to choose from, numerous HTTP accelerators, web servers and continuous integration tools! My point is there isn't a short supply of tools available; in hindsight, I'm not sure why that surprised me, but it did.
Top five things I've learnt
A year ago, I knew very little to nothing about being a system administrator. I could be very lazy and just list the top five things I've learnt in my job, but I'll try and be a bit more descriptive. In no particular order of importance:
Patience is actually a virtue! I've learnt that when dealing with a task, be it for a client or a personal task, to be patient with it. Getting frustrated and angry (perhaps covertly when dealing with a client) will only make matters worse and lengthen the time it takes to solve the problem. Clients who are not as technically knowledgeable appreciate patience; as I described above, Jamie was incredibly patient with me during my training, which helped me to understand the problem at hand more easily.
Security is important. Very important. I deal with client data on a daily basis, so being proactive in keeping my workstation and computer secure at all times is important. I've learnt to be vigilant when transferring data to a client or a colleague; rather than send them a sensitive document over plain text email, I'll upload it to a server the recipient has access to so they can grab it from there themselves. I'd GPG encrypt an email to them, but ever since the people who make the GPGTools plugin for the OSX mail app have started charging for the service (shakes fist), I've opted to use other means. We at Code Enigma like FOSS! Over the last year, Code Enigma have become ISO 27001:2013 certified, which meant I had to learn and understand how to handle data and documents properly.
Workflow is also important. I learnt about the simple, yet very effective, workflow used by Code Enigma in the first couple of weeks of joining the company. It's as straightforward as this: master -> stage -> production. Push changes to the master branch first, then merge them through to stage after some initial testing. Once the client is happy and has signed off the changes, push them through to production for deployment to the live site. Simples! However, before I joined CE, I didn't know or think like this. When I ran an online game with my brother (not in Drupal), I'd make changes to the code locally, with no local setup running, and FTP (ew) the updated files directly to the server, which affected the live site. Horrendous. Now, when I start work on a personal project, I have an exact workflow I want to follow.
Drupal...well, a small amount. A very small amount. Primarily, I'm a sysadmin, so I do a lot regarding setting up Drupal sites and debugging server issues relating to Drupal. I did a small amount of Drupal development at the start of my employment, so learnt a little bit about it which has fared me in good stead when it comes to dealing with simpler Drupal issues.
- Linux. Well, obviously not all of it, but I have learnt a lot in my first year. Obviously there are some things I've learnt that I need to improve on, but that's a given with most operating systems, especially Linux. I knew a little bit about Linux before joining CE, but only rudimentary stuff from using Ubuntu as my main OS for a little while. During my first year, I picked up some really useful tips and tricks, learnt of different command line tools and how to use them, such as Drush and learnt how to read system and access/error logs. That's just to name a few Linuxy things I've learnt.
What I hope to do/learn in the next year
There's so much out there to learn that appeals to me, I could probably write a separate blog post just about that! But what I really want to learn, that I think will benefit me as an individual and my role in Code Enigma, will both be time consuming and difficult: MySQL multi-master replication and DRBD, to assist our Australian sysadmin with server cluster issues, and Drupal 8. I've a head start (ish) on Drupal 8 in that I know a bit about PHP, but I've been made aware the PHP I know and have programmed in is archaic and old-fashioned. It's time to delve into Object-oriented programming!
It would be great (for me at least) to get a text-based, role-playing game up and running in Drupal, be it 7 or 8. But seeing as I want to develop my D8 skills, it makes sense to develop the game using the latter of the two. As I previously mentioned, I used to run an online text-based game with my brother, which used a very poorly written engine now that I look back on it. I've not seen many, if any, games of the sort created using Drupal. Even if no one plays the game, it'll still be an achievement in my eyes as I'll have improved my Drupal knowledge.
MySQL multi-master replication will be an important concept to understand and know how to use because we have a handful of clients that have a high availability layout setup with us, which include two application servers and two database servers, at least. If there's a blip in the network, replication between the servers can be affected, which requires manual intervention to put right. If this happens, our Australian sysadmin is woken up through the use of his batsignal, but if I could solve any replication issues and save him being woken up in the early hours of the morning, then it's a win-win for both of us; I'll have bolstered my knowledge and Mig won't be woken up abruptly.
What are my impressions after my first year?
My impressions after my first year as a system administrator for a Drupal agency are very high; the other sysadmins in our team are incredibly knowledgeable and can adapt to every situation and issue thrown at them. This has given me inspiration to develop my skills and knowledge to reach their level and some day leave the same kind of impressions on a future junior sysadmin.
My impressions for working for a Drupal agency are just as high. My colleagues are all very clued up in their area of expertise, from Drupal magic to content strategy to finance management. Everyone does their part for the company, be it providing bespoke tools for a website (such as the ones used for this very site) or by providing top level training to new, or old, Drupal agencies. It's an honour to be part of such a fantastic team!
Main image by Wendy Seltzer, released under the Creative Commons Attribution 2.0 Generic license.
30 Jan 2015 10:24am GMT
29 Jan 2015
In my last blog post I explained what the Panels Suite is and does. I explained how Panels itself is a User Interface on top of
theme(). That technical explanation of Panels underlines what I think is its main conceptual virtue:
Panels encourages a mental model of pulling data into a specific design component
At Palantir we're working with Design Components that are created in static prototypes. Design Components are the reusable pieces of front-end code that compose a design system. Design Components should not know about Drupal's internal implementation details. We're not alone in this thinking. (Inside the Drupal community, and outside of it).
The task of "theming a node" is now "print this node so that it renders as this design component." Unfortunately Drupal core does not have <code>hook_design_component()</code>. It has <code>hook_theme()</code>. Some of the entries in <code>hook_theme()</code> from core are essentially design components.
Entries like <code>'item_list'</code> and <code>'table'</code> are design components. They are conceptually based around their HTML rendering. They make sense independent of Drupal. To use them as a Drupal Developer you need to get your data organized before you call <code>theme()</code> (directly or otherwise).
On the other hand, much of the Drupal core usage of <code>hook_theme()</code> is not at all design component minded. <code>'node'</code>, <code>'user'</code>, <code>'comment'</code> all have entries in <code>hook_theme()<code>. In these elements you don't have to organize your data before calling <code>theme()</code>. You can give <code>theme()</code> a node object and after that <code>template_preprocesss_node()</code> has to do a ton of work before hitting the template.
It's no coincidence that the design component-ish <code>hook_theme()</code> entries have minimal preprocessing or no preprocessing whatsoever. The design component-ish entries like </code>'item_list'<code> know what the HTML will look like but have no idea what your data is other than you were able to get it into a list. The non-design component entries like node know exactly what the Drupal-meaning of the data is but know very little about the markup they will produce on most production sites.
Panels unites the two mindsets. It knows what the incoming data is (A node context, a user context, etc) and it knows what design component it will print as (the layout plugins.) If you put a debug statement inside of </code>panels_theme()</code> you will see the names of layouts and style plugins. These </code>hook_theme()</code> entries are more of the design components-ish <code>hook_theme()</code> entries. They know what their markup will be. And the part of Panels most people pay attention to, the drag-and-drop interface, is where you control how the data of a node is going to prepare itself for the design component.
And here is where the admin UI of Panels might set up a confusing mental model.
How it looks in the Panels admin UI
But at execution time it is
Or the way I think of it
Drupal Data → transforming Drupal data into printable variables → design components for those variables to print in
The next time I get into a discussion about Panels at a meetup, DrupalCamp, or DrupalCon, think I'll first ask, "Does Panels let you think about building websites the way you want to think about building websites?" I like to think about passing variables into encapsulated configuration associated with a specific design component. I prefer that mental model to the "show and hide based on globals" mental model of Core's Blocks or the "just call
theme() on a node and figure out the overrides later" mental model encouraged by
node--[content-type].tpl.php. As the Drupal community asks itself again how it wants to do rendering, let's also ask "how do we want to think about rendering?"
The rise of design component thinking in the wider Wweb development world is not turning back. Web Components and modern front end MVC frameworks encapsulate design components. They do not care about every single implementation detail and layer of a node object. They care about getting variables ready for printing and updating. Panels module may fall out of the picture once Web Components fully mature. Until then, Panels allows for us to think in ways we will need to think for Web Components to work with Drupal.
29 Jan 2015 9:00pm GMT
Drupal 8 has been all about pushing the boundaries, so why should help content be any different?
With the release of Drupal 8, we will also ship with tools to complement
hook_help() entries: if you, the developer, are providing a documentation page for your module, why not also provide an interactive step by step guide on how your module works as well?
The idea of Tour isn't a new one; it has been maturing over the past two years. It all began after the release of Drupal 7 when we decided to move the help passage from the front page to the help page. This meant that users new to Drupal would not see this text, and would have to struggle through with no guidance.
In light of that issue, the below was suggested;
How about creating a "Welcome" message that pops up in an overlay with that same information that continues to appear until either the user checks a box on the overlay saying to dismiss it or the user creates a piece of content on the site?
- Vegantriathlete, August 10, 2011
With tour.module committed to Drupal 8 core, we now have context-sensitive guided tours for Drupal's complex interfaces, and developers have a new way to communicate with the user. It doesn't stop at core either: contrib modules can ship with tours to describe how users can take full advantage of their modules. Distributions can also ship with tours on how to get started. Imagine a tour in the Commerce distribution that took the user through setting up products: That would be amazing! It would enable users to discover the pages they are looking for and take the guesswork out of finding pages.
29 Jan 2015 5:51pm GMT
There are alternatives to integrate in Drupal websites. Below we will give you a few reasons why we currently prefer the Bootstrap framework.
Why a HTML framework
First of all, why should you use a HTML framework? These possibilities also exist:
29 Jan 2015 4:58pm GMT
Nothing keeps Drupal tourists from spreading the word! We are passionate for Drupal and IT, so enjoy meeting like-minded people very much! Despite the cold winter weather, Ternopil welcomed us with warmth and friendliness. How was it? Our blog post will tell.
We were getting ourselves ready for the ride for almost a month. Our brandy Drupal van wanted to make nice impression too, that's why the journey hit off from the car wash :)Read more
29 Jan 2015 10:31am GMT
In An Introduction to Git Part 1, you learned what Gi
29 Jan 2015 6:00am GMT
28 Jan 2015
While we at Mediacurrent have been trying to bring internal focus and organization to our contributions, the rest of the Drupal community was planning a "Sprint Weekend" for January 17th and 18th.
28 Jan 2015 11:24pm GMT
Display Suite is one of the essential modules which I use on every project. It allows you to change the look and feel of entity bundles, i.e., content types, vocabularies, users and much more. Building custom layouts and adding fields is a breeze, but there's another feature you may not be aware of and that's custom field templates. Display Suite allows you to change the markup which is used to render individual fields.
The functionality to change field templates is off by default. To turn it on, you'll need to enable the "Display Suite Extras" sub-module and check the "Field Templates" on the Extras page.
In this tutorial, you'll learn how to enable "Field Templates" and how to use them.
28 Jan 2015 9:36pm GMT