Elsewhere

Commerce Guys: Cutting the Cord - Why choosing an open-source framework is analogous to ditching your cable provider

Planet Drupal - Thu, 25/06/2015 - 14:00
In today’s tech-driven culture, any business that’s looking to succeed must have an online presence. eCommerce, is rapidly becoming pervasive. There are plenty of high-cost, enterprise software solutions available as well as inexpensive SaaS options that provide turn-key ecommerce solutions.

Regardless of which solution you choose, both the enterprise solutions and the smaller SaaS solutions create liabilities and risk for your business. The reason is that they both lock your business into a cycle of license (or maintenance) fees and deep dependency on a single vendor to extend the feature set and remain relevant in the fast paced world of technology.

eCommerce software = Cable (or Satellite) TV. Think about it. How much of your TV lineup do you actually watch? Probably less than 10%. In fact, back in September of 2014, Nielson reported that most American Households watch only 17 of the 189 channels that the average TV service provider pipes into our homes. This wouldn’t feel so bad if the average cost for pay-TV service wasn’t climbing at an astronomical rate.

So it’s no surprise that many are deciding to ditch their cable company and get the specific entertainment options they actually use, without over-paying for services they don’t want and will never use. People ultimately want to choose their entertainment options and control what it costs. Do a Google Search for cord cutting and you’ll get countless articles detailing fed-up customers and fearful pay-TV executives. You’ll get even more links to how-to’s and YouTube videos with advice on how to get the content you want, often for free… or at the very least, less expensively via streaming services like Netflix, Hulu and others using devices like an Apple TV or Google ChromeCast (plus, more every day). It’s clearly a tipping point for home entertainment, and the big companies who provide the content are taking notice.

Something very similar is happening online.

Companies are also beginning to look at their eCommerce platform in the same light. Rather than a huge code base and feature set that makes vast assumptions about their requirements, many of which they will never use or simply won't fit their business model, they are looking for solutions that can exactly meet their current and future needs without costing a fortune.

As mentioned previously, any business today must be online. It’s not a nice to have anymore or a service reserved for companies with specific plans to sell online. Your customers will be shopping online. If not with you, then with your competitors. Companies today are increasingly choosing free open source solutions rather than proprietary solutions that lock them into contracts, license fees, and a single vendor. Those companies choose software that offers a flexible framework rather than rigid technology that can’t deliver on all their requirements. They are embarking on a strategy centered around a web publishing framework that allows them to build something that exactly matches their business needs and doesn’t come pre-packaged with anything that will compromise the experience the customer receives.

Only need a catalogue online? Get that without having to disable features that come with the enterprise software that’s costing X over the next Y years. Ready for eCommerce? Enable it. Need a new feature? Build it in-house, or pay a web developer to give you exactly what you want. The alternative is to submit a feature request and wait helplessly through the software vendors next (and next, and next) release cycle for the feature you need. An open-source framework allows you to build a modular web application with just the features you need... and none of the features you don’t.

That’s why Drupal is the perfect software for web publishing. And why over 1 million sites have been built with Drupal. Its modular architecture and community supported framework allows companies to get just the experience they are looking for without the bloat.

And thankfully for companies who have eCommerce requirements, Drupal Commerce provides the perfect extension of that framework. It brings the modular thinking to selling online, lets merchants pick only the features they need to sell their products online, and skips the licensing, the bloatware and the software release cycle. If you need to enable a specific third-party connection, or have a unique product to sell (like digital goods or subscriptions) there are modular components that let you do that. Enable them and you’re good to go. And if you’ve come up with a new idea and there isn’t a module that lets you just turn that on, well then, there are many services companies with developers ready to build it and huge community of developers to support it.

So if you’re planning on cutting the cord at home (or maybe you already have), why not do the same with your eCommerce solution??
Categories: Elsewhere

Microserve: Drupal go-live checklist (revisited)

Planet Drupal - Thu, 25/06/2015 - 11:52

A handy tool for every developers arsenal: a simple go-live checklist! When a site is finally ready to launch it can be easy to get excited and forget some of the important details, but having a checklist to hand can prevent any last minute slip ups. 

Here's my own personal checklist and below it a further description of each item with some hints and tips. Leave me a comment if you have any questions or think I've missed anything important!

Go-Live Checklist
  1. Check Status Report and Site Information page
  2. Disable Developer modules
  3. Disable any theme specific development settings
  4. Disable error message display
  5. Configure performance settings
  6. Check log messages and fix any apparent issues
  7. Check 404 and 403 reports
  8. Ensure custom 403 and 404 pages are in place
  9. Enable and configure Google Analytics module
  10. Ensure all Web Services are setup correctly
  11. Audit users accounts and ensure all admins use a secure password
  12. Ensure best practices are followed for SPAM prevention
  13. Configure basic SEO practices
  14. Test email

...and here's those points explained in detail:

1. Check Status Report and Site Information page

You should always start by checking the status report - /admin/reports/status. This page shows you all of the basic requirements for your Drupal site to run correctly.

Any issues will be highlighted in red and typically have a link to a configuration page or the documentation to help you resolve the problem.

The site information config page holds all of the most common site information, such as the website name and email address.

It's worth double checking that all of this information is correct. It could be quite embarrassing if your first newsletter arrives from dev@example.com.

2. Disable Developer modules

Developer modules unnecessarily bloat your website so these should be disabled when going live. If they haven't been configured out the box then you can safely uninstall these too without worrying about losing any information.

It’s quite common to cram your website with contrib modules only to find out that numerous modules haven’t actually been used or were replaced by a similar module later in the development process, so these should be removed and uninstalled too.

There are also a number of Core modules we regularly uninstall such as Color, Comment, Dashboard, and Help as these Core modules are often unused on your average Drupal site. In our opinion Dashboard and Help simply add more links to the menu which unnecessarily confuse content editors.

3. Disable any theme specific development settings

This may be completely different for every theme but most themes have a number of development settings to help speed up development. which should be turned off when going live to remove any performance bottlenecks created by them.

This is also a good chance to disable (and remove) any themes which haven’t been used.

4. Disable error message display

Nice and simple; head to /admin/config/development/logging and set “Error messages to display” to “None”. This prevents any embarrassment and confusion created when your end users start seeing error messages on the page which to them will look like technical gibberish!

5. Configure performance settings

The site performance page - /admin/config/development/performance will allow you to configure a number of options to help optimise your Drupal site. This includes page caching and optimising CSS and JavaScript files.

See our series on High Performance in Drupal for some expert tips - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code.

6. Check log messages and fix any apparent issues

Assuming you have the core database logging module (dblog) enabled you should have a list of log message which can be found at /admin/reports/dblog

Most messages will simply be notices which can be ignored,  though often there may be certain errors which saturate and fill up the log. Each log message requires a db write so a large list of regular messages can have a large impact on site performance. One example of this could be an undefined variable which doesn’t appear to cause any issues, but creates an error message to be logged on every page view.

It is good practice to regularly check the error log and periodically fix any recurring errors which are being reported.

7. Check 404 and 403 reports

Not only should these be checked prior to going live, but they should be periodically checked to ensure end users aren’t suffering from recurring 404 or 403 errors. Simply check both reports - /admin/reports/access-denied and /admin/reports/page-not-found - and look out for entries which have an unusually high count. Once you’ve found these question why they are a problem and get them fixed. If you have the URL Redirect module enabled there should be a simple link you can use labelled “Fix 404 pages with URL redirects”.

You may find some odd entries like “wp-login.php”, though these will just be from spam bots so they can be ignored.

Another little tip: Some of your links may not  appear in this report as they work, but are still problematic as they’re actually links to your development or test sites. Enable Pathologic as an input filter to help find and remove any of these.

8. Ensure custom 403 and 404 pages are in place

This is a nice little touch which doesn’t have to take any longer than 5 minutes. Simply create two basic pages; one for your 404 page and one for your 403 page, then set them as up under /admin/config/system/site-information.

The aim of these pages is to funnel lost visitors to other areas of your site to help them find what they were looking for. Some people choose to make these as simple as possible whilst others put a bit more “flare” into them. For some inspiration check out 33 brilliantly designed 404 error pages.

If your site uses the Search module you could also try utilising the Search 404 module - this handy little module performs a search on the keywords in the URL of the page which can't be found.

9. Enable and configure Google Analytics module

The first thing you want to do when you launch is check out your visitor stats; though the last thing you want to see is that none of this data exists because you forgot to setup Google Analytics properly!

Simply enable the Google Analytics module and add your GA Property ID under /admin/config/system/googleanalytics .

For best results we recommend overriding the GA ID on dev and test sites, that way your analytics results won't be skewed by internal traffic from your development sites.

10. Ensure all Web Services are setup correctly

Many web services such as Mollom or Typekit require a domain name specific API key to use. If you use any of these services on your website, you should ensure that you've registered your real domain name with the service and you've updated Drupal with your new API key.

11. Audit users accounts and ensure all admins use a secure password

It’s easy when first developing a site to use a simple login such as “admin” with the password “pass” so ensure all admin users have set a secure password if they haven’t already. We recommend using a tool like LastPass to generate and remember strong passwords.

Before you go live double check there aren’t any users with the admin role that you don’t want to have full access to the site. Ideally this should be a developer only role and your content editors should use another role with reduced permissions.

12. Ensure best practices are followed for SPAM prevention

The pro’s and con’s of different Spam modules and techniques is a story for another day, but there’s a few basic steps you can take:

  • If your site doesn’t use comments then disable the comments module. If it does, ensure permissions are correctly setup and that comments are only enabled on the content types they are required on.
  • Check the “Who can register accounts?” setting - /admin/config/people/accounts. If your only users are administrators simply change this to “Administrators only” to avoid an influx of spam user accounts.
  • Use Honeypot or Mollom to help reduce spam on contact and comment forms.
13. Configure basic SEO practices

This will be covered in a later blog post in further detail, but there’s a few tips you can use to ensure your site gets a head start here:

  • Redirect traffic from the non-www version of the domain to the www version (or vice versa) to avoid the site being indexed twice.
  • Check your haven’t left anything like “Disallow: /” in your robots.txt file which would prevent Google crawling your site correctly.
  • Lock your dev and test environments to ensure these aren’t accessible by visitors or crawled by Google.
  • Ensure you have added, enabled and configured the Global Redirect, URL Redirect and Pathauto modules.
14. Test email

Ahh, good old we-nearly-forgot-about-it email. You’d be surprised how many sites have issues sending email, especially when you have smaller self-hosted sites where there is no key reason to check this.

Fire off a forgotten password email when the site is ready on the liver server and ensure it reaches you OK without being sent to spam.

Personally we prefer using Mandrill on any of our sites which rely on email. Mandrill is a free tool which helps prevent email being marked as spam and provides details of all outgoing mails in a clean, easy to use interface.

Rick Donohoe
Categories: Elsewhere

Drupal core announcements: Update: Drupal 8 beta 12 rescheduled for June 29; get ready for hook_update_N() in core

Planet Drupal - Thu, 25/06/2015 - 00:35

We've rescheduled Drupal 8 beta 12 for June 29, 2015 to provide a little more leeway time for Drupal 8 core issues that require an update function. Starting June 29, any Drupal 8 core issue that includes a data model change must include an update function and update path test. See the previously announced core policy on requiring hook_update_N() for more information.

Identify your data model changes now!

If you have any core patches that are currently under development, please start identifying the data model changes in those patches now. Tag any issue that requires a data model change with D8 upgrade path and document the specific data model changes in the issue summary. Or, help triage major issues with specific attention to the data model changes.

It's actually also a good idea to start writing hook_update_N() implementations for your patches now! This will ensure in-progress issues can be committed as soon as possible following the next beta, and if your patch is ready before June 29, your update function will still help provide the corresponding update for the head2head project. Plus, if you uncover a critical limitation with Drupal 8 core's update functionality while working on your update function during the next week, the upcoming D8 Accelerate critical issues sprint will be an opportunity to get that critical issue fixed and unblock your patch.

Note for Drupal site owners and developers

Betas are good testing targets for developers and site builders who are comfortable reporting (and where possible, fixing) their own bugs. Betas are not supported releases of Drupal, and generally are not recommended for non-technical users, nor for production websites. The current beta release includes known critical bugs, including publicly disclosed security vulnerabilities. More information on beta releases.

The addition of update functions for Drupal 8.0.x issues should make it easier for developers to update their existing development sites between beta releases using update.php. However, these update functions may include bugs or even introduce data integrity issues, so developers should always back up the site and be prepared to rebuild it from scratch or manually update or migrate the data in case update.php fails to update it properly.

Categories: Elsewhere

Tom Geller: Moving on from Drupal

Planet Drupal - Thu, 25/06/2015 - 00:12

In the Esperanto language there was a great writer and activist known as "Kabe". After creating magnificent translations and reaching a position of authority, he suddenly left Esperanto life, never to participate again. So notorious was his disappearance, the language gained the verb "Kabei" -- to vanish suddenly from a position of great visibility.

I'd be flattering myself to compare my position in the Drupal world to Kabe's in Esperantio -- the Esperanto world. But my lynda.com courses and other writings about Drupal made me fairly well-recognized in Drupal circles.

I've been absent from those circles for the last couple of years, and feel the need to give closure to -- and recognize -- those I got to know there.

I got started in Drupal because I wanted to build a dynamic website to promote a book I'd written. It was a period of great growth for Drupal, and lynda.com accepted my proposal to create a seven-hour "Essentials" video course. (I think they agreed because their first CMS course -- on WordPress -- was selling pretty well.) That led to seven more, a book, a magazine column, various presentations, and a lot of corporate work.

Was I a "Drupalista"? That's tough to say. I've sincerely enjoyed working with it: Although I've come to recommend WordPress for inexperienced site builders with minimal needs, I'm still thrilled with how much I can accomplish with Drupal and a free afternoon. As I (like most people) have come to live more and more online, Drupal has given me more control over my environment. For example, I'm not afraid that I'll lose a major chunk of my history as LiveJournal slips down the tubes: Through Drupal I made a local copy, privately linking commenters to their real-wold contact information. Those tools, those gifts of the Drupal community, are still with me.

We grew apart. Drupal ceded the mom-and-pop market to other platforms, focusing instead on enterprise needs. That's a fine match... but it's not what interests me, personally. Coding -- a skill I don't have -- eclipsed site-building, evidenced by the increasing percentage of Planet Drupal posts on the subject. And Drupal 8's unexpectedly long development time caused a major writing project to stall after I'd put in a month of work.

But oh! What a fine relationship we've had. I'm scared to list the people who have made my time in "Drupalio" so much fun -- I'm sure I'd miss many. But I want to recognize everybody who helped me on Drupal.org; those involved with Drupal companies I've worked with (Commerce Guys, Mediacurrent, Acquia, Phase2 Technology, DrupalEasy, Tag1 Publishing, TopNotchThemes); those who corresponded privately about Drupal matters; and those who continue to make Drupal great. I'd be very happy to hear from you directly, and will continue to check in on drupal.org (where I'm tgeller) from time to time.

I've gone back to general technology journalism and communications. Lately I've been quite happy working in video, and have started a U.S.-based agency, Tom Geller Productions. Making a monthly video for The Association for Computing Machinery has put me in touch with people doing fundamental research. I intend to do for that community what I've tried to do for the Drupal community: to make their work clear and accessible to those without specialist knowledge.

Esperantio and "Drupalio" are quite different. But they're similar in an important way -- one that's shared by any international community of people gathered for a righteous cause. After a time, the cause changes and falls away, leaving intact relationships that linger. As Wavy Gravy said, "It's all done with people." Although I might kabei, look forward to seeing you people, wherever we meet.

Blog category: Drupal Planet
Categories: Elsewhere

Gizra.com: Why PhantomJS When You Can Chrome

Planet Drupal - Wed, 24/06/2015 - 23:00

Following our unfortunate bug in Shoov which caused login to stop working, we decided to write a Behat test that will continuously check the live site and make sure login with GitHub is working properly.

Writing the Behat test was pretty easy, however it had a major problem - it didn't work.

@javascript Scenario: Login to shoov Given I am an anonymous user When I visit the homepage And I login with my GitHub account Then I should wait for the text "My Account" to "appear"

When Behat sees the @javascript tag in the begining of the scenario, it launches it (with the help of Mink extension) in PhantomJS, Firefox or Chrome.
PhantomJS is usually the easiest to configure and hook into the CI workflow later on.

But the test we wrote just failed on all versions of PhantomJS we tried. Which made us switch to Firefox instead. Travis CI is kind enough to have a headless Firefox installed in their machine which we could use. Unfortunately, Firefox didn't like our test either, but for another reason - it couldn't parse the xpath we use to find our text elements.

So after spending some time trying to figure out a workaround, I suddenly stared at the browser I was using to find the answer - Chrome!

Behat test running on headless Chrome, seen via VNC

Continue reading…

Categories: Elsewhere

Forum One: Programmatically Restricting Access to Drupal Content

Planet Drupal - Wed, 24/06/2015 - 19:01

Have a requirement like “I want users to not be able to add, update, delete or view content if some condition is true?” If so, hook_node_access might be all you need. This hook simply allows you to alter access to a node. Now let’s learn how to use it.

How this hook works

Anytime a user accesses a node (to add, update, delete or view it) this hook is called and can be used to alter that access decision. It receives three parameters.

  • $node – Contains information about the node being accessed (or base information, if it is being created)
  • $op – What type of access it is (create, update, delete, view)
  • $account – Information about the user accessing the node

It expects a return value to alter the access, which is; NODE_ACCESS_DENY, NODE_ACCESS_IGNORE or NODE_ACCESS_ALLOW. Best practice is to not use allow and use either deny or ignore (ignore is the default, if no return is given). You get far less permissions headaches this way.

I use this module often for customized workflow requirements. The most recent use case was “I want to deny update access to all users who try to update a node based on a user select field on the node selecting them or not.”

This is all done with one simple hook in a custom module (see below).

NOTE: There are some instances this hook is not called/skipped. Refer to the hook’s link for those cases.

/** * Implements hook_node_access(). * * Enforces our access rules for custom workflow target content to force updates * only if the user is targeted in the user select field */ function mymodule_node_access($node, $op, $account) { // If a node is being updated if ($op == 'update') { // If the user select field exists on this node if (isset($node->field_my_user_select)) { // If the user select field is not empty if (!empty($node->field_my_user_select)) { // If the user id in the user select field does not match the current user if ($node->field_my_user_select[LANGUAGE_NONE][0]['target_id'] != $account->uid) { // The users are not the same. Deny access to update in this case return NODE_ACCESS_DENY; } } } } // Else ignore altering access return NODE_ACCESS_IGNORE; }
Categories: Elsewhere

Palantir: Twin Cities or Bust!

Planet Drupal - Wed, 24/06/2015 - 16:29

We love Drupal Camps for a lot of reasons, and the popular Camp in the Twin Cities is no different. We get to learn about new projects, see old friends, and discover interesting ideas and solutions to challenges in Web development, design, and strategy. In addition, not only does our Senior Web Designer Carl Martens live in the Twin Cities area, we’ve worked with a number of clients there, including the University of Minnesota and PRI, among others.

This year, we have six Palantiri in attendance, presenting sessions on a number of important topics like Drupal 8, testing, technical debt, design systems, and much more. The Camp also gives us a unique opportunity to talk shop with past, current, and potential clients to learn about their projects and understand the challenges our expertise can help solve for them. Heading to the Camp? Please do let us know via our contact form.

We give an overview of our sessions for Twin Cities, and propose why each is important for your project or those working on it. We’ll update this post once the recordings are online.

Rendering HTML With Drupal: Past, Present, and Future

by Steve Persch
Friday, June 26, 10:30am

What is it about?
This presentation will review the mental models used in Drupal theming and propose a workable path forward. For years, Drupal core has encouraged a mindset of altering and overriding its internal data structures. Developers in the Drupal 6 era created a philosophy called “sustainable theming” that relied heavily on CSS to work best with Core’s tendencies. The rapid acceleration in the wider Front-End community in recent years has brought new underlying assumptions and new ways of thinking. Expectations for how to construct Drupal sites have changed. The future holds clear decoupling with Javascript MVC frameworks, Web Components and some traditional HTML frameworks that encapsulate Front-End pieces that can work with multiple data providers. Can you make Drupal’s components be those components? Bonus: the phrase "Headless Drupal" will come up at least a dozen times.

Why is it important for your project?
Knowing the history of a system helps round out your overall knowledge of that system. As such, you'll learn how Drupal's theming system has been shaped by expectations of different eras, and how CSS usage has evolved, ultimately learning how to spot patterns that move toward the future of front-end development. In addition, you’ll learn the importance of discussing with theming choices with team members, and ways to future-proof their code and workflow.

Drupal 8: The Crash Course

by Larry “Crell” Garfield
Friday, June 26, 10:30am

What is it about?
One of the most widely-used and mature Content Management Systems on the planet, Drupal runs more than one in fifty websites in the world. However, it has always been something of an odd duck, with an architecture and design very different than anything else in PHP. Enter Drupal 8: almost a complete rewrite under the hood, Drupal 8 is a modern, PHP 5.4-boasting, REST-capable, object-oriented powerhouse. Now leveraging 3rd party components from no less than 9 different projects, Drupal 8 aims to be the premiere Content Management Platform for PHP.

Why is it important for your project?
A bit of Drupal 8 preparedness never hurt anyone. This session will provide a walkthrough of Drupal's key systems and APIs, intended to give developers a taste of what building with Drupal 8 will be like, and should be able to recognize common patterns in Drupal 8 development, and identify the Drupal 8 equivalents of common tasks from Drupal 7 at the end of it.

Design Systems and Drupal

by Larry “Crell” Garfield and Carl Martens
Saturday, June 27, 10:30am

What is it about?
Modern Web design demands visual systems that ensure content is delivered to our myriad devices, from smartphones to tablets to desktop displays and beyond, in usable ways. It requires thinking in terms of content that gets presented, often in a variety of different ways, rather than simply presentation. In this session, Larry and Carl will provide practical examples for how modern, modular design systems and practices can map directly to Drupal’s Views module, view modes, image styles, panels and other common site building tools.

Why is it important for your project?
You'll walk away with information that will help you leverage Drupal’s strengths through leading edge Web design, to both see and understand the basic concepts of design-system thinking, content strategy, and Drupal as a unified worldview that results in better, faster, and more consistent sites.

Technical Debt Insights from the Lorax

by Andrea Soper and Joe Purcell
Saturday, June 27, 1:00pm

What is it about?
Technical debt is a common analogy to describe the cost of code mess and poor architecture. However, how far can the monetary analogy go? In this session we will look at insights from the Lorax and “environmental debt”. Specifically, Andrea and Joe will build an argument for why the monetary comparison communicates the wrong idea about how technical debt is measured and how it impacts business. They will also include measures and practices to mitigate such technical debt.

Why is it important for your project?
If you deal with the challenge of communicating the business cost of technical debt, want a clearer understanding of what technical debt is and how to measure it, or want advice on how to mitigate against technical debt, this session will help. The goal is cleaner, more sustainable code and architecture for you, your team, your project, and the future.

On PhpSpec and Not the Drupal Way

by Michelle Krejci
Saturday, June 27, 2:15pm

What is it about?
This session gives you an introduction to the distinctions between unit, integration, and system testing, an introduction to behavior driven development (BDD), and, of course, using PhpSpec (a BDD tool) to isolate and spec out functionality in your Drupal codebase. PhpSpec is a toolset for building out testable pieces of functionality strictly designed to meet —and only meet—the project requirements that you have made explicit. Identify your inputs, test your expected outputs. That's it. The bigger question is: how do we as developers mature our skills and deliver testable, functional code while we continue to work on Drupal 7?

Why is it important for your project?
Proper testing breeds successful projects, plain and simple. You'll walk away with not only an understanding of the cost/benefit tradeoff of unit testing vs. system testing, you'll also learn the importance of building out custom functionality in Drupal using PhpSpec. The ultimate goal is helping you write better code and modernize your developer skills. Project Managers are welcome, too!

Heading to Twin Cities? Let us know in the comments, @ reply us on Twitter, or get in touch via email.

Categories: Elsewhere

Localize.drupal.org: Test the staging version of localize.drupal.org on Drupal 7 NOW!

Planet Drupal - Wed, 24/06/2015 - 16:13

What, localize.drupal.org still runs on Drupal 6? Yeah. It is absolutely time to update to Drupal 7 so we can keep improving the site on an up to date platform, so we need your help to try the new staging version out. Sebastien Corbin and Gábor Hojtsy with the invaluable help of the Drupal Association prepared the staging site and hope it is near ready for the upcoming live update. But we need more testers to ensure it actually is. Here is how the test works:

  1. See all instructions for testing at https://www.drupal.org/node/2487972, including how to report issues
  2. Everybody with existing accounts or new staging registrations is welcome (note that the site is not rebuilt, so if you don't already have a drupal.org account, you need to create one on staging)
  3. This public testing runs until the 8th of July (for 2 weeks)

If you test now, we can fix issues ahead of the launch, so you would not need to complain after the update. Any questions? Post on the issue at https://www.drupal.org/node/2487972

read more

Categories: Elsewhere

Realityloop: Giving back to the community: Community Tools

Planet Drupal - Wed, 24/06/2015 - 11:37
24 Jun Brian Gilbert

At DrupalCon Sydney where I was the Community track chair, for the first time at a DrupalCon both Stuart and I had offered to help as mentors at the post conference sprint. We felt in a relatively good position to do this as we’ve been running a mentoring event locally in Melbourne nearly every month since some time in 2010, which is another story in itself.

This naturally led on to us being mentors at DrupalCon Portland. During the mentor BOF’s while mostly listening, I was already thinking how can I make things better and the thing that stuck out to me were the common issues that often came up while getting a first time sprinters set up with a local development stack:

  • Bandwidth usage
  • Different stacks (MAMP, WAMP, XAMPP, etc)
  • Mentors having to support a stack they’re not familiar with
  • Time of setup (some users would take nearly an hour to setup)

Around the same time Stuart and I had been playing around with BitTorrent Sync (BTSync), which at that time was pretty new, but in my mind a promising potential solution to the bandwidth component of the problem.

I also thought that Acquia Dev Desktop (ADD) may be a better option for setting up a local stack than using any of the other *AMP stacks listed above. While also simplifying the support task for mentors that are essentially volunteering their time.

Eventually I started to talk to some of the more seasoned mentors about my ideas and there was some interest in my thoughts on BTSync, but a lot of kickback on using ADD due to previous sprints where various people had been burned trying to use ADD with Drupal 8 in the past.

As luck would have it one of the mentors that worked at Acquia, scor AKA Stéphane Corlosquet, was at these BOF’s also and we exchanged details. See the relevant issue at: https://www.drupal.org/node/2232043.

Attending what is now known as the First Time Sprinters workshop in Portland I was surprised when it was suggested that attendees all go and download MAMP/WAMP/XAMPP “now”.. It was no wonder the wifi had a history of dying during sprints, and it didn’t disappoint this time going down at exactly this point during the Portland sprints.

Needless to say this was enough motivation for me to implement and prove my thoughts, so I started building what eventually became the Community Tools Installation process.

What were the constraints?

There wasn’t that many, but these were the key things:

  • Installation is fast
  • Lean on the network
  • Doesn't break anything existing on a users machine.

It seems common for people to think that we are putting this forward as the ideal development stack, this is not at all the case, it is simply designed to be the fastest way to get someone up and running with a capable stack.

By using BTSync the majority of the network traffic for the tools is served from within the sprint room itself from the laptops of mentors that have pre-synced it.

BTSync has two levels of access to a shared folder, one that is read/write (only known to me) and one that is read only which is given to everyone else. This means we don’t run the risk of spreading malware that could arise through the use of USB keys shared with approximately 200 people.

BTSync also allows for last minute changes to be made that will sync out to all users, meaning we can respond to issues that arise quickly and not have to re-image a bunch of USB keys just before the workshop.

In the beginning there was a lot of pressure to include MAMP and other tools in the package, but I was eventually able to work with Acquia via scor to improve the ADD2 Beta such that it was the clear winner for this specific use case. Related issue: https://www.drupal.org/node/2232043.

ADD2 installs it’s webserver and database using ports for these services that are to my knowledge unique, meaning that it will not conflict with any existing web stack a user has set up.

ADD2’s supplied configurations (PHP/MySQL) also work out of the box with Drupal 8, something that often needed changing with other stacks.

Why this collection of tools?

The components were primarily chosen based on relevance to the typical activities performed by a first time sprinter during the sprint day, these are:

  • Use IRC (Limechat / Hexchat)
  • Edit code (SublimeText)
  • Use Git to apply and create patches (Git)
  • Run Drupal 8 (Acquia Dev Desktop 2)
  • Install Drupal 8 (Drupal Core — dev branch)

Initially the tools came with a PDF that walked you through each of the installation steps, pretty quickly I saw that people weren't reading this and making mistakes in the installation, so fairly promptly I started scripting as much of the installation as possible to reduce the chance of user error and also reduced the installation time. Related issue: https://www.drupal.org/node/2294267.

The OSX scripting was easy but It was fun having to learn how to code a .BAT file after not having used windows for several years.

At this stage the only manual step of the installation apart from selecting which parts you want to install is adding the site in ADD which has substantially reduced the size of the PDF that nobody reads ;)

The script prompts to see if you want to install an IRC client and a code editor, it then checks if you have git installed or not and prompts to install and configure git to d.o standards.

To save bandwidth Drupal 8 core is included in the tools package that is synced, extracted during the installation and then a git pull is executed to only grab recent changes saving again on bandwidth.

At this stage I’m very confident this is as lean as it can get without creating a customised install package specific to each operating system.

How has it performed?

After testing it at local events the concept was proven, the first real test at scale at DrupalCon Austin, about 50 people out of 200 had issues with it syncing but I considered it a success.. and the network stayed up!

We used it again in DrupalCon Amsterdam where I don’t think we had as many issues with people getting it synced but did still have to use USB drives for some people.

And I used it at DrupalSouth Melbourne earlier this year where it synced perhaps the fastest ever and we didn't have to use any USB thumb drives.

What could be improved?

It’s fairly clear that there are some limitations built into BTSync, and that the venue network setup can sometimes cause issues. I am constantly on the lookout for a better transport method (ideally looking for something open source instead of BTSync or for the Sync team to provide a free pro account so that we can share these secrets with unlimited users)

I think having a web server at the venue that could serve the tools would provide the most added benefit to the existing setup, while removing the weakest remaining link (BTSync) and also opening up the possibility of using tools that are larger in file size.

Linux doesn’t have ADD so the current experience is quite different for Linux users, and in my not consistent enough. To some degree we expect these users to already know how to set up a stack which isn’t the best assumption to make.

Statistics

Tools download file sizes:

  • Linux         510MB
  • OS X         247.5MB
  • Windows  290.3MB

External Bandwidth usage during installation:

On OSX Git is installed via download of the command line tools.. ~120MB
For OSX and the rest the only the Git pull to update core ~20MB or less

Installation time:

  • Linux          ~5 minutes
  • OS X           ~4 to 7 minutes depending on if you already had git installed or not
  • Windows     ~5 minutes
Where to from here?

There are several community members that are pushing for vagrant to be for the stack part of this toolset, I think that it will go a long way to resolving the inconsistencies that we currently see with Linux setups, talking about it in the office we all think it needs a pretty control panel to make it easier for as wide a group of end users as possible. But there are some considerations that still need to be factored in. Related issues: https://www.drupal.org/node/2233509 and https://www.drupal.org/node/2232049.

This is a recount of events spanning several years, I've done my best to be as accurate as possible please forgive me if there may be some small factual errors in my recounting of things.

drupal planetdrupal 8
Categories: Elsewhere

Blair Wadman: 19 simple methods to improve the page speed performance of a Drupal site

Planet Drupal - Wed, 24/06/2015 - 11:29

Site speed is one of the most critical factors when running a site. If a site takes too long to load, visitors will hit the back button and go elsewhere. Google is well aware of this, so slower sites will not rank as well as fast sites (all other things being equal).

Drupal performance optimisation can be a complicated specialisation in its own right. Consultants and Drupal agencies can spend days or even weeks investigating performance issues and fixing them. But there are many quick fixes and simple methods that you can implement right away. You don’t have to implement absolutely everything on this list - you can implement some and monitor the difference it makes to the site speed....

Categories: Elsewhere

Modules Unraveled: 140 Using the Math Field Module to Compute Values Without the PHP Filter with Caleb Thorne - Modules Unraveled Podcast

Planet Drupal - Wed, 24/06/2015 - 07:00
Published: Wed, 06/24/15Download this episodeMath Field Module
  • What does the Math Field module do?
  • Why did you develop it? What hole does it fill?
  • You mentioned EntityForm...
  • How does it compare to the Computed Field and other modules?
  • What are the limitations? When wouldn’t you use it?
  • You mentioned before we started recording that you actually rewrote the entire module to use core’s AJAX framework instead of custom jQuery. Why was that? and how did it go?
Use Cases
  • What types of sites do you see this being of most use?
  • I might be using this on an upcoming project
Future
  • What are your plans for D8?
  • What other general features are planned? I saw the note on the project page about issues with multiple parameters and multivalue fields.
Questions from Twitter
  • Rick Nashleanas
    Any performance implications using the Math Field module? drupal.org/node/2484065 (Yea, I know, this is a plant!)
  • David Csonka
    Is there a practical limit to how many Math Field fields you can have calculating in a piece of content? Performance?
  • Rick Nashleanas
    What's the most complicated implementation you've done with the Math Field module?
Episode Links: Caleb on drupal.orgCaleb on TwitterMath Field ModuleBlog Post about Math FieldTags: planet-drupal
Categories: Elsewhere

Open Source Training: The Beginner's Guide to Drupal Security Releases

Planet Drupal - Wed, 24/06/2015 - 02:05

There was a Drupal security release this week.

This release managed to confuse several of our users, because it wasn't clear if they should update their sites.

Security release information is rarely, if ever, written in plain English. And these week's updates were additionally confusing because they only impacted some Drupal sites.

So here, upon request, is our plain English guide to Drupal security releases.

Categories: Elsewhere

Drupal Association News: Drupal Association Board Meeting: 17 June, 2015

Planet Drupal - Tue, 23/06/2015 - 22:59

First things first - an apology. I realize it's been a couple of month since I put up a post about our Board meetings. I definitely apologize, and will try not to let that happen again. However, know that you can always see the meeting minutes, materials, and recordings on our site. And, if you ever have any questions, you can find me on Twitter, D.O, in IRC (drupalhross), or you can send me an email (you know, if you are old school). 

The June board meeting covered the month of May at the Association, which was a rather big month. As usual, we had a number of items to cover in our operational upate, and then we dove into updates from the Drupal.org Working Groups

Operational Update
  • Drupal 8 Accelerate had a great month in May, adding $55,000 to the total of over $213,000 now raised to help close D8 release blockers. Huge thanks to Catalyst IT, Open Source Developers Conference Australia, Siteground, Figleaf Software and Duo Consulting for the $1,000+ donations in May. You can see how every dollar is directly impacting Drupal 8.
  • We had a DrupalCon! We'll give you a full wrap up in August when all the details, including financials are available. 
  • Content Strategy is coming to Drupal.org. In an nutshell, we are excited to have completed a content strategy process with Forum One. With the strategy document complete, we can begin implementation. In the next few months we'll be introducing changes to the site to support the new information architecture and content governenace. When everything is in place, you will see a site that is easier to navigate and gives topic owners more flexibility in the types of content and permissioning they can use. You can see all the details in the DrupalCon LA session we hosted. 
  • As we shared in last week's post, our revenue continues to come in slower than planned. In Executive Session we shared a mid-year adjustment to the plan that we have now begun executing. Although we are not meeting our original goals, we remain excited about the possibilities for the Association - we are still growing. Especially reassuring is that all the Drupal 8 content we release is snapped up quickly.
Working Group Updates

Last quarter the Working Groups met in-person at DrupalCon Los Angeles. During the meeting, the groups discussed their role in producing the Drupal.org roadmap and began the process of re-prioritizing the work. We have definitely discovered a broader need for the Association engineering team across the Drupal ecosystem, and need a better process to allow for unplanned work to be prioritized. A good example is DrupalCI, which morphed from an entirely volunteer-run initiative to work supported heavily by Association staff. 

The Working Groups have also proposed charter changes in to the Executive Committee for review. We are looking to expand the number of community members on each group and further clarify the roles. 

Thanks and see you next month!

That's all we had for this board meeting, but more is planned for July and beyond. Check out all our upcoming board meetings and register to attend. 

Flickr photo: pdjohnson

Categories: Elsewhere

DrupalCon News: Get an Advantage by Sponsoring at DrupalCon

Planet Drupal - Tue, 23/06/2015 - 20:43

DrupalCon Barcelona is going to be an incredible event in a beautiful city with a great Drupal community. Sponsoring give your organization visibility and recruting benefits you can’t find at another event.

Categories: Elsewhere

mark.ie: Revert a Drupal Database Update

Planet Drupal - Tue, 23/06/2015 - 20:40
Categories: Elsewhere

Red Crackle: Drupal Performance Optimization Checklist

Planet Drupal - Tue, 23/06/2015 - 20:15
You must have read plenty of articles on how to tune your Drupal site to improve its page load times. This post assembles an exhaustive list of all the configurations and tweaks you can do to improve Drupal's performance before increasing RAM and CPU speed of your server. The list contains components from the full stack, including Drupal application and modules, front-end proxies, CDN, webserver, PHP, database, OS and server hardware.
Categories: Elsewhere

InternetDevels: DrupalTour Lviv

Planet Drupal - Tue, 23/06/2015 - 17:25

What do we get if we combine two popular memes: "Keep calm and code on" and "Keep calm and visit Lviv"? And if we add the fast green Drupal bus, good spirits and exciting IT reports? Of course, we get DrupalTour in the city of Lviv which is the capital of the Ukrainian web development services!

Read more
Categories: Elsewhere

DrupalCon News: The Critcal Importance of Sending Your Team to DrupalCon

Planet Drupal - Tue, 23/06/2015 - 16:37
It may not feel like it at first, but choosing to send your team to DrupalCon is one of the best (and most important) decisions your business can make. While it may not immediately be clear what the ROI is for attending DrupalCon, the value of having your company’s employees at the event is huge. Here’s why. 1. Learn About Bleeding Edge Best Practices
Categories: Elsewhere

Drupal Watchdog: Responsive Themes

Planet Drupal - Tue, 23/06/2015 - 16:23
Feature

In 2010, Ethan Marcotte published his seminal article, “Responsive Web Design,” and the way we build web sites was forever changed. Although Drupal 7 came out at the beginning of 2011, there was nothing in core to support the themers who wanted to build responsive websites. By 2012, all of the popular base themes offered a stable release which included a responsive starting point. As of Drupal 8, the core themes, and the administrative interface, will be responsive – making Drupal usable at any viewport width.

The original tenets of responsive web design had three directives:

  1. Use a fluid grid to lay out page elements.
  2. Make images flexible, and responsive to their parent container.
  3. Use media queries to specify which styles should be assigned for any given viewport width.

In practice, it has been a lot more complicated to implement these guidelines so that they work across devices and are respectful of the slower connection speeds we often experience on mobile devices.

In this article we'll take a look at how to implement each of these three principles in your Drupal 8 themes. The article was written against Drupal 8.0-alpha13. Some things are likely to have changed between now and Drupal 8's official release. Where possible, I've noted where this might be the case.

Fluid Grids

Out of the box Drupal 8 does not provide any support for a universal fluid grid. It does, however, provide the cleanest, most semantic markup of any version of Drupal to date. Markup is almost entirely contained in template files, and the theme function has been virtually eliminated from core. All of these changes were accomplished by the team working to convert Drupal from PHPTemplate to Twig. As a result, it will be significantly easier to drop in your grid layout system of choice – whether it is custom built, or part of a framework such as Bootstrap or Foundation.

Working with a base theme is still, of course, an option for you. As of this writing, there are no base themes with a completely functional Drupal 8 release; however, a few have Drupal 8 branches if you'd like to help with their upgrade process.

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator - Elsewhere