Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Mar 14 2019
Mar 14

We're continuing our popular "Support Wizard Help Desk" at Drupalcon 2019! Book some time with myDropWizard for some FREE help with your Drupal site!

You're a first time Drupalcon attendee? You're a veteran Drupaler? Either way, you made part of your Drupalcon mission to fix a lingering issue - or at least to be pointed in the right direction!

We're here to help!

We spend our days helping Drupalers just like you every day with their support needs, so we thought "Let's bring that myDropWizard Support Face-to-Face with Drupalers: FOR FREE!"

So, drop by Booth #811 or (better yet!) schedule with us below!

Where we'll be and when

  • Our booth: We again sponsored DrupalCon this year and will have a booth in the exhibit hall! We're in booth #811!
  • Everywhere! Just like you we want to get around the convention to see everyone and everything. Stop us and say "hello!"

Schedule a one-on-one meeting

Again, we'll be happy to discuss your current challenges (or successes!) anywhere at Drupalcon, but if you want to be double extra sure that you'll be able to chat with us, schedule a one-on-one meeting with us!

We like to keep things simple, so just drop us an email to schedule a meeting with either Elliot or David:

[email protected].

Can't wait to see you there!

We're super friendly, non-imposing people who love Drupal and the Drupal community. :-) We all look forward to hearing how your organization is using Drupal and how we can help! Have a great week in Seattle!

Mar 13 2019
Mar 13

Note: This post refers to Drupal 8, but is very applicable to Drupal 7 sites as well

Most Drupal developers are experienced building sitewide search with Search API and Views. But it’s easy to learn and harder to master. These are the most common mistakes I see made when doing this task:

Not reviewing Analytics

Before you start, make sure you have access to analytics if relevant. You want to get an idea of how much sitewide search is being used and what the top searches are. On many sites, sitewide search usage is extremely low and you may need to explain this statistic to stakeholders asking for any time-consuming search features (and yourself before you start going down rabbit holes of refinements).

Take a look for yourself at how the sitewide search is currently performing for the top keywords users are giving it. Do the relevant pages come up first? You’ll take this into account when configuring boosts.

Using Solr for small sites

Drupal 8 Search API comes with database search included. Search API DB has come a long way over the years and is likely to have the features you need for smaller sites. Using a Solr backend is going to add complexity that may not be worth it for the amount of value your sitewide search is giving. Remember, if you use a Solr backend you have to have Solr running on all environments used in the project and you’ll have to reindex when you sync databases.

Not configuring all environments for working Solr

Which takes us to this one. If you do use Solr (or another server-side index) you need to also make sure your team has Solr running on their local environments and has an index for the site. 

Your settings.php needs to be configured to connect to the right index on each environment. We use Probo for review sandboxes so we need to configure our Probo builds to use the right search index and to index it on build.

Missing fields in index or wrong type

Always included the ‘Rendered HTML’ field in your search index rather than trying to capture every text field on all your content types and then having to come back to add more every time you add a field. Include the title field as well, but don’t forget to use ‘Fulltext’ as its field type. Only ‘Fulltext’ text fields are searchable by word.

Not configuring boosts

In your Processor settings, use Type-specific boosting and Tag-boosting via HTML filter. Tag boosting is straightforward: boost headers. For type-specific boosting you’re not necessarily just boosting the most important content types, but also thinking about what’s in the index and what people are likely looking for. Go back to your analytics for this. 

For example, when someone searches for a person’s name, are they likely wanting the top result to be the bio and contact info, a news posting mentioning that person, or a white paper authored by the person? So, even if staff bios are not the most important content on the site, perhaps they will need to be boosted high in search, where they are very relevant.

Not ordering by relevance

Whoops. This is a very common and devastating mistake. All your boost work be damned if you forget this. The View you make for search results needs to order results by Relevance: Descending.

Using AJAX

Don’t use the setting to ‘Use AJAX’ on your search results View. Doing so would mean that search results don’t have unique URLs, which is bad for user experience and analytics. It’s all about the URLs not about the whizzbang.

Not customizing the query string

Any time you configure a View with an exposed filter, take the extra second to customize the query string it is going to use. ‘search’ is a better query string than ‘search_api_fulltext’ for the search filter. URLs are part of your user interface.

No empty text

Similarly, when you add an exposed filter to a search you should also almost always be adding empty text. “No results match your search” is usually appropriate.

Facets that don’t speak to the audience

Facets can be useful for large search indexes and certain types of sites. But too many or too complex facets just create confusion. ‘Content-type’ is a very common facet, but if you use it, make sure you only include in its options the names of content types that are likely to make sense to visitors. For example, I don’t expect my visitors to understand the technical distinction between a ‘page’ and a ‘landing page’ so I don’t include facet links for these.

A screen shot of facets in DrupalYou can exclude confusing facet options 

Making search results page a node

I tell my team to make just about every page a visitor sees a node. This simplifies things for both editors and developers. It also ensures every page is in the search index: If you make key landing pages like ‘Events Calendar’ as Views pages or as custom routes these key pages will not be found in your search results. 

One important exception is the Search Results page itself. You don’t want your search results page in the search index: this can actually make an infinite loop when you search. Let this one be a Views page, not a Views block you embed into a node.

Important page content not in the ‘content’

Speaking of blocks and nodes, the way you architect your site will determine how well your search works. If you build your pages by placing blocks via core Block Layout, these blocks are not part of the page ‘content’ that gets indexed in the ‘Rendered HTML.’ Anything you want to be searchable needs to be part of the content. 

You can embed blocks in node templates with Twig Tweak, or you can reference blocks as part of the content (I use Paragraphs and Block Field.)

Not focusing on accessibility

The most accessible way to handle facets is to use ‘List of Links’ widget. You can also add some visually hidden help text just above your facet links. A common mistake is to hide the ‘Search’ label on the form. Instead of display: none, use the ‘visually-hidden’ class.

Mar 07 2019
Mar 07

Linking patterns allows us to give our users a real feeling for how the website is going to work, on real devices, which things like InVision can never do. Here's some simple approaches.

When using PatternLab, you can link to a pattern by creating a variable such as {{ url }}. Then in your corresponding JSON or YML file, you can setting this variable equal to something like

url: link.pages-contact

or

url: link.pages-homepage.

We often use this when creating menu items, since in Drupal our menu items template looks for two parts to the menu link: title and url, something like this:

 menu: 
  items: 
    item_1:
       title: 'About Us' 
       url: link.sample-pages-basic-page 
    item_2: 
      title: 'Contact Us' 
      url: link.sample-pages-basic-page-contact-us 

This works great when working with a template that has a specific variable for the URL, such as the link to a node in node.html.twig, so we can link the title in our teaser template in PL to our sample blog pattern, for example.

But if we have a link field, such as a Call to Action in a paragraph bundle we might have something like this in our pattern:

{{ cta_link }}

and this in our corresponding YML file:

cta_link: 'Click Me!' 

We don't have PL paths in those links, because if we swap `#` for a `link.sample-pages-basic-page` it'll just render that as a string. And we don't want to break the variable into two parts, because in the Drupal template, we want to be able to {% set cta_link = content.field_cta %} and let Drupal do all its render magic.

The solution? Don't break up variable into two parts, concatenate what you want in YML instead to allow us to link to specific patterns:

cta_link: 
  join(): - 'See Ways to Help'

Now, the first part will render as a string, the second as a variable to the pattern you want to link to, and the third part as a string.

We could also create a link pattern, and do something like this:

cta_link: 
  include(): 
    pattern: 'organisms-link' 
    with: 
      url: 'link.sample-page-homepage' 

I don't, because, in general, I don't like patterns to depend on other patterns. This is simply so I can drag and drop them from project to project without any friction. Each component has everything it needs contained within it. It also means in case of something like a link field, we can let Drupal do as much of the heavy lifting as possible.

Feb 28 2019
Feb 28

basketball hoop demonstrating a goalChoosing good SEO goals is a critical first step in your digital marketing campaign. As with any long-term endeavor, knowing your marketing end goals and working directly toward them saves time, money, and stress.

Good SEO cannot be done in a vacuum. It depends on business goals, the needs of the sales and customer support team, and intimate knowledge of the competitive landscape in which you work. Engage the critical stakeholders in each area of your business and work together to come up with a list of needs. You may be surprised at how SEO can help each team meet its objectives.

It’s important to choose the right goals before implementing any SEO strategy and get continual buy-in from your team. Combine and categorize ideas to find the ones that digital marketing is well suited for. If possible, pick some “easy” objectives and start stacking up quick wins with your team. This buys you time for longer-term strategies that SEO is suited for.

If you’re struggling to get buy-in from team members, or they don’t have enough knowledge to understand how SEO can help their department, it may help to bring some ideas into the conversation to get the creative juices flowing.

Let’s look at seven different SEO Goals and how they can impact your business.

hands with fingers that are also handsSEO Objective #1: Lead Generation and Direct Marketing

Build customers and revenue, one form-pop at a time.

If you are a lead-driven business, it’s likely that your customers require at least one personal contact from your company before they buy. You may have a higher-than-average purchase price, or your solution involves customization. The key to a thriving lead generation SEO campaign is the conversion rate.

CRO (Conversion Rate Optimization) is almost always the best place to start when you are looking for more leads from your website. It’s easier to make direct changes that can dramatically increase your lead flow.

Implement A/B testing to try different approaches that make it easier for your customers to convert. Here are several ways to make an impact right away:

  • Shorten your forms. Do you really need 2 different phone numbers and a full mailing address on the very first customer interaction?
  • Inform your visitor precisely what will happen when they submit the form.
  • Don’t use the word “Submit” on your form buttons (Who wants to submit, anyway? It sounds painful.)

Once your on-page conversion rate is at least 5% (or higher—hopefully much higher), you can turn your attention to increasing targeted traffic. This can be accomplished by creating excellent customer-focused content and don’t be afraid to ask for the conversion. Consider offering a valuable freebie for newsletter signups and then market to your newsletter to create demand.

Capturing their information is only the first step. Make sure you use a good marketing automation tool and CRM to keep in touch with your customers.

 crowd of people walkingSEO Objective #2: Increase Raw Traffic to Your Website

Traffic for traffic’s sake.

This is just what it sounds like. Get as many click-throughs to your content and try to keep them on your site as long as possible. You want to use this objective when you can monetize traffic without actions or financial transactions. If for example, your site is sponsored or ad-driven, this is an excellent place to start.

Concentrate your efforts on great content and conduct keyword research to find topics that are of high interest to your target audience. And make sure to use those keywords in your content.

Use Google Answers to find questions that people ask and then write a series of blog posts to answer them. This will earn traffic on long-tail Google queries. Make sure your articles are easy to share and optimized for viral spreading by employing share buttons.

However, be cautious about using clickbait or fake news to drive adrenal-based clicking. People are becoming savvy to this kind of egregious traffic generation, and you could set yourself up to tarnish your brand for a short-term gain. Focus instead on helpful, interesting, or timely content that truly provides value to your target audience. Provide follow-up content and give them a reason to stay. Bounce rate is an important SEO ranking factor so do what you can to increase the time that visitors spend on your site.

online shopping or ecommerceSEO Objective #3: Increase E-commerce Sales

Focus on driving relevant traffic to your online store and boost transactional sales.

About 10% of the retail sales in the USA comes from e-commerce. Only about half of that is Amazon, which means there are millions of other websites competing with you for your customers’ clicks and purchases. Leveraging SEO can create long-term, competitive advantages for any business in this hyper-competitive space.

When you have transactional products and/or services for sale on your site, do not overlook the funnel in your keyword strategy. Generally speaking, this means the more precisely a visitor is searching for a product, the closer they are to making a purchase.

  • Industry words (“vacuum”) are top-of-the-funnel. They require a lot of information, are looking broadly for a solution, and may not even be looking for the product that you offer.
  • Generic product names (“vacuum cleaner”) can be considered top or mid-funnel. They know they need a solution but don’t necessarily know what. Provide comparative information, and show your product in many different scenarios.
  • Longer tail generic phrases (“robot vacuum” or “automatic robot vacuum cleaner”) could be considered mid to low in the funnel. They know what they want and are looking to compare similar products to help them make a decision.
  • Branded searches usually are considered lowest in the funnel, especially when combined with buy words (“buy roomba vacuum” or “discount roomba vacuum”).
  • Specific part numbers can be a good indicator that someone is looking to buy right this minute. Maybe its a replacement or refillable part, or that they know exactly what they want. You will find the more specific the keyword, product name, or even part number, the more likely your visitors will purchase. Optimize content for the problems that your product solves; create very focused content that builds confidence and leads your customer through the purchase.

Once you’ve identified your audience and keywords, focus on making the transaction as easy as possible with conversion rate optimization (CRO). The objective of CRO is to increase average conversion value. A good way to test the efficacy and potential ROI of keywords and phrases is to conduct a pay-per-click campaign to discover if they are providing traffic and conversions.

cow surprised at getting a brandSEO Objective #4: Branding

Increase customer awareness and lower resistance to future transactions.

Branding is often overlooked but is a mission-critical part of an ongoing marketing campaign.

If you’re just starting to build your brand with your target market, branding eases future conversations by creating space for you in your customer’s mind. It’s easier to engage with a known company than a new entity you only recently found.

For established brands, ongoing branding protects your domain and builds trust. Ranking well for industry terms around your business can create awareness of new solutions and gain a quick customer while lesser brands struggle. Leverage your brand by making your presence known in keyword searches that involve competitive words and products. Make sure you are part of every conversation.

SEO gets consumers participating and interacting with your brand. Your keyword focus becomes straightforward as you will be targeting your company and product name so you will achieve more with less intensive effort. Make sure your site is accessible with good link structure and focus on links from high-quality sources that legitimize your brand. These high-quality links are valuable to Google as an indicator of the importance of your website.

star wars troopers needing reputation managementSEO Objective #5: Reputation Management

Protect your brand.

We get it. Everybody makes mistakes. In the Internet era, every mistake is magnified and can stick around hurting your brand for months or years.

When you are trying to protect your brand from having a negative reputation or change an existing negative image, SEO can be a huge help in achieving this perspective shift.

First, own your brand name in all its forms. You want to have 10 out of 10 branded search results in Google in your control. This involves optimizing pages on many different domains so you can “own” complete pages of search results. Create presences on Facebook, Linkedin, Github, Reddit, Twitter, etc. and run branded SEO campaigns on those pages. When you own the top 10, don’t relax. Keep steady pressure with additional unique content and links relevant to your brand.

Then, focus on keywords that are highly relevant to your brand. It could be your legal business name, personal name, brand name or a popular variant. Use public relations, press releases, social media profiles, links from networks of sites you may own or control.

Do not underestimate the power of a personal response from the founder or CEO to an online complaint. However, if you aren’t experienced or comfortable doing this, consider using outside professionals, because responses must be carefully crafted. Quick, unconsidered comments can be seen as flippant, out-of-touch, uncaring, or worse: defensive and angry. However, an appropriate word can diffuse a situation and actually increase customer loyalty in the long run.

Even if you don’t have a negative situation, consider starting now to protect your brand. Reputation management is one of the most challenging SEO practices when done in an emergency. Plan ahead, build your reputation, and be ready when an emergency does happen.

girl holding a sparklerSEO Objective #6: Customer Service

Your customers are asking questions on Google. Make sure the answers come from you.

If you want long-term relationships with your customers, be there when they need you. That means anticipating their needs after the sale and providing answers to questions that they have at each stage of the ownership cycle of your product. Each interaction is an opportunity to reinforce your brand in their mind, control negative impressions, and build a relationship that will last.

Find content ideas by mining your customer service logs, online support requests, or looking at other companies in your industry. Answer questions with a blog post, video, or instructional document and then link to it from relevant places on your website. That’s just the beginning.

Another tactic for acquiring new customers is to create content that answers questions about competitor’s products! Help them without reservation, and gently guide them to your solution.

one smiley face in a sea of unhappy facesSEO Objective #7: Target a Specific Person or Company

Reach out and touch someone.

One last SEO objective to consider is the Internet’s unique ability to target specific individuals with your content. Say that a salesperson has been trying to break into a company with your product. But, try as they might, they can’t get past the gatekeepers for a phone call. Email isn’t working, and cold calling is a non-starter. Should you give up? Hardly.

There is an entire marketing sub-industry around the idea of marketing to the individual. It’s called Account Based Marketing (ABM). ABM is a strategic approach to business marketing in which an organization communicates with individual prospects or customer accounts as markets of one. Although it’s typically employed in enterprise level sales organizations, companies of any size can and do use these techniques to make key account acquisition easier.

The first step is to clearly identify the exact people you need to market to. The list is usually relatively short, 25-100 people. You can then combine SEO practices—like buying their name on Google Adwords or Linkedin and running a simple ad which leads to a personalized landing page—with the best of ABM and create unique solutions to help you reach new customers.

Final Thoughts

This stuff isn’t easy. If it were, business wouldn’t need marketing professionals like yourself to figure out these objectives and implement them. There is no cookie cutter approach to marketing. Every company has different customers, products, and competitive pressures, so be careful when applying these objectives to your situation. Nothing can replace genuine conversations and openness.

And these are just some of the top objectives of SEO. Here are several secondary objectives that I’ve seen over the years:

  • Increase the number of product pages in Google SERPs
  • Reduce leads from low-budget customers
  • Reduce customer service calls
  • Apple/Android App Store SEO
  • Amazon product listing SEO
  • Educate the consumer
  • Measure coupon use
  • Event-specific SEO
  • Drive retail sales
  • Reduce returns
  • Ego

Whether your objectives are on this list or not, Volacci stands ready to help you create the best possible online presence for your business. If you’d like a quick leg-up on your Drupal SEO, take a look at our SEO Quick Start Plans and give us a call us today. Whatever your objectives, Volacci can help.

Feb 25 2019
Feb 25

Using a smart SQL query with subqueries, we reduced the time to build a data export by a factor of (at least) 50. On the development system with little data, we got from the response from 11 seconds to about 0.25 seconds.

To make this possible, we had to use a generated column to be able to create an index on a field inside a JSON column. Doctrine does not know Generated Columns, so we had to hide the column and index from the Doctrine Schema Generator.

Our use case is that we have a table with orders. We have to build a report that shows sums of the orders by regions (zip codes in our case). The address on the order is not allowed to change, the goal is to record to what address an order has actually been shipped. Rather than linking to a different table with foreign key, we decided to denormalize the address on the order as a JSON MySQL field.

The first approach queried the zip codes table and then looped over the zip codes to query the order database for each of the 3 different sums the report contains. This of course leads to 3*n queries. Add to this that each query is highly inefficient because it needs to do a full table scan because one criteria involves accessing the zip code in the JSON field with MySQL JSON functions. At some point we started hitting timeout limits for the web request to download the export...

Using Subqueries

This is one place where using the ORM for reading is a trap. Writing direct SQL is a lot easier. (You can achieve the same with DQL or the Doctrine Query Builder and hydrating to an array.)

We converted the query into one single query with subqueries for the fields. Instead of looping over the result of one query and having a query for each row in that result, we unified those into one query:

SELECT 
    a.zip,
    (
        SELECT COUNT(o.id) 
        FROM orders AS o
        WHERE o.state = ‘confirmed’ 
          AND JSON_CONTAINS(a.zip, JSON_UNQUOTE(JSON_EXTRACT(o.delivery_address, '$.zip'))
          ) = 1
    ) AS confirmed,
    (
        SELECT COUNT(o.id) 
        FROM orders AS o
        WHERE o.state = ‘delivered’ 
          AND JSON_CONTAINS(a.zip, JSON_UNQUOTE(JSON_EXTRACT(o.delivery_address, '$.zip'))
          ) = 1
    ) AS delivered,
    ...
FROM areas AS a
ORDER BY a.zip ASC

Each subquery still needs to do a table scan for each row to determine which orders belong to which region. We found no fundamentally easier way to avoid having to select over all orders for each row in the areas table. If you have any inputs, please use the comments at the bottom of this page. What we did improve was having an index for those subqueries.

MySQL Generated Columns

Since version 5.7, MySQL supports “Generated Columns”: A column that represents the result of an operation on the current row. Among other things, generated columns are a neat workaround for creating an index on a value stored inside a JSON data field. The MySQL configuration is nicely explained in this article. For our use case, we have something along the following lines:

ALTER TABLE orders 
     ADD COLUMN generated_zip CHAR(4) GENERATED ALWAYS AS
        (JSON_UNQUOTE(JSON_EXTRACT(delivery_address, '$.zip'))
CREATE INDEX index_zip ON orders (generated_zip)

With that, our query can be simplified to be both more readable and use a field where we can use an index:

SELECT 
    a.zip,
    (
        SELECT COUNT(o.id) 
        FROM orders AS o
        WHERE o.state = ‘confirmed’ 
          AND o.generated_zip = a.zip
    ) AS confirmed,
    (
        SELECT COUNT(o.id) 
        FROM orders AS o
        WHERE o.state = ‘delivered’ 
          AND o.generated_zip = a.zip
    ) AS delivered,
    ...
FROM areas AS a
ORDER BY a.zip ASC

So far so good, this makes the query so much more efficient. The rest of this blogpost is not adding further improvements, but explains how to make this solution work when using the Doctrine Schema tool / Doctrine Migrations.

Working around Doctrine

While Doctrine is an awesome tool that helps us a lot in this application, it does not want to support generated columns by design. This is a fair decision and is no impediment for us using them for such queries as the one above.

However, we use Doctrine Migrations to manage our database changes. The migrations do a diff between the current database and the models, and produce the code to delete columns and indices that do not exist on the models.

It would help us if this issue got implemented. Meanwhile, we got inspired by stackoverflow to use a Doctrine schema listener to hide the column and index from Doctrine.

Our listener looks as follows:

getTable()) {
            if ('generated_zip' === $eventArgs->getTableColumn()['Field']) {
                $eventArgs->preventDefault();
            }
        }
    }

    public function onSchemaIndexDefinition(SchemaIndexDefinitionEventArgs $eventArgs)
    {
        if ('orders' === $eventArgs->getTable() 
            && 'index_zip' === $eventArgs->getTableIndex()['name']
        ) {
            $eventArgs->preventDefault();
        }
    }

    /**
     * Returns an array of events this subscriber wants to listen to.
     *
     * @return string[]
     */
    public function getSubscribedEvents()
    {
        return [
            Events::onSchemaColumnDefinition,
            Events::onSchemaIndexDefinition,
        ];
    }
}
Feb 25 2019
Feb 25

This PSA is now out of date. Read: Extending Drupal 7's End-of-Life - PSA-2020-06-24

Drupal 7 was first released in January 2011. In November 2021, after over a decade, Drupal 7 will reach end of life (EOL). (More information on why this date was chosen.) Official community support for version 7 will end, along with support provided by the Drupal Association on Drupal.org. This means that automated testing services for Drupal 7 will be shut down, and there will be no more updates provided by the Drupal Security Team.

When this occurs, Drupal 7 will be marked end-of-life in the update manager, which appears in the Drupal administrative interface. Updates, security fixes, and enhancements will no longer be provided by the community, but may be available on a limited basis from select commercial vendors.

If you have a site that is running on Drupal 7, now is the time to start planning the upgrade. Note that the transition from Drupal 8 to Drupal 9 will not be the significant effort that the transition from 7 to 8 was. In fact, the first release of Drupal 9 will be identical to the last release of Drupal 8, except with deprecated code removed and dependencies updated to newer versions. (See Plan for Drupal 9 for more information on Drupal 9.)

What this means for your Drupal 7 sites is, as of November 2021:

  • Drupal 7 will no longer be supported by the community at large. The community at large will no longer create new projects, fix bugs in existing projects, write documentation, etc. around Drupal 7.
  • There will be no more core commits to Drupal 7.
  • The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules, themes, or other projects. Reports about Drupal 7 vulnerabilities might become public creating 0 day exploits.
  • All Drupal 7 releases on all project pages will be flagged as not supported. Maintainers can change that flag if they desire to.
  • On Drupal 7 sites with the update status module, Drupal Core will show up as unsupported.
  • After November 2021, using Drupal 7 may be flagged as insecure in 3rd party scans as it no longer gets support.
  • Best practice is to not use unsupported software, it would not be advisable to continue to build new Drupal 7 sites.
  • Now is the time to start planning your migration to Drupal 8.

If, for any reason, you are unable to migrate to Drupal 8 or 9 by the time version 7 reaches end of life, there will be a select number of organizations that will provide Drupal 7 Vendor Extended Support (D7ES) for their paying clients. This program is the successor to the successful Drupal 6 LTS program. Like that program, it will be an additional paid service, fully operated by these organizations with some help from the Security Team.

The Drupal Association and Drupal Security Team will publish an announcement once we have selected the Drupal 7 Vendor Extended Support partners.

If you would like more information about the Drupal release cycle, consult the official documentation on Drupal.org. If you would like more information about the upcoming release of Drupal 9, join us at DrupalCon Seattle.

Information for organizations interested in providing commercial Drupal 7 Vendor Extended Support

Organizations interested in providing commercial Drupal 7 Vendor Extended Support to their customers and who have the technical knowledge to maintain Drupal 7 are invited to fill out the
application for the Drupal 7 Vendor Extended Support team. The application submission should explain why the vendor is a good fit for the program, and explain how they meet the requirements as outlined below.

Base requirements for this program include:

  • You must have experience in the public issue queue supporting Drupal 7 core or Drupal 7 Modules. You should be able to point to a history of such contribution. One way to measure this is issue credits, but there are other ways. You must continue this throughout your enrollment in the program. If you have other ways to show your experience, feel free to highlight them.
  • You must make a commitment to the Security Team, the Drupal Association, and your customers that you will remain active in this program for 3 years.
  • As a partner, you must contribute to at least 20% of all Drupal 7 Vendor Extended Support module patches and 80% of D7ES core patches in a given year. (Modules that have been moved into core in Drupal 8 count as part of core metrics in Drupal 7) .
  • Any organization involved in this program must have at least 1 member on the Drupal Security Team for at least 3 months prior to joining the program and while a member of the program. (See How to join the Drupal Security Team for information.) This person will need a positive evaluation of their contributions from the Security Working Group.
  • Payment of an Drupal 7 Vendor Extended Support annual fee for program participation is required (around $3000 a year). These fees will go to communication tools for the Drupal 7 Vendor Extended Support vendors and/or the greater community.
  • Payment of a $450 application fee is required.
  • Your company must provide paid support to Drupal 7 clients. This program is not for companies that don't provide services to external clients.
  • Application review process:

  1. We will confirm that each vendor meets the requirements outlined above and is a good fit for the program.
  2. If the Security Working Group does not think you are a good fit, we will explain why and decline your application. If you are rejected, you are able to reapply. Most rejections will be due to Organizations not having enough ongoing contribution to Drupal 7 and Organizations not having a Drupal Security Team member at their organization.
  3. The Drupal Association signs off on your participation in the program.
  4. If you are accepted, you will be added to the Drupal 7 Vendor Extended Support vendor mailing list.
  5. The Security Working Group will do a coordinated announcement with the vendors to promote the program.

If you have any questions you can email [email protected]

Feb 25 2019
Feb 25

Earlier we wrote about stress testing, featuring Blazemeter where you could learn how to do crash your site without worrying about the infrastructure. So why did I even bother to write this post about the do-it-yourself approach? We have a complex frontend app, where it would be nearly impossible to simulate all the network activities faithfully during a long period of time. We wanted to use a browser-based testing framework, namely WebdriverI/O with some custom Node.js packages on Blazemeter, and it proved to be quicker to start to manage the infrastructure and have full control of the environment. What happened in the end? Using a public cloud provider (in our case, Linode), we programmatically launched the needed number of machines temporarily, provisioned them to have the proper stack, and the WebdriverI/O test was executed. With Ansible, Linode CLI and WebdriverIO, the whole process is repeatable and scalable, let’s see how!

Infrastructure phase

Any decent cloud provider has an interface to provision and manage cloud machines from code. Given this, if you need an arbitrary number of computers to launch the test, you can have it for 1-2 hours (100 endpoints for a price of a coffee, how does this sound?).

There are many options to dynamically and programmatically create virtual machines for the sake of stress testing. Ansible offers dynamic inventory, however the cloud provider of our choice wasn’t included in the latest stable version of Ansible (2.7) by the the time of this post. Also the solution below makes the infrastructure phase independent, any kind of provisioning (pure shell scripts for instance) is possible with minimal adaptation.

Let’s follow the steps at the guide on the installation of Linode CLI. The key is to have the configuration file at ~/.linode-cli with the credentials and the machine defaults. Afterwards you can create a machine with a one-liner:

linode-cli linodes create --image "linode/ubuntu18.04" --region eu-central --authorized_keys "$(cat ~/.ssh/id_rsa.pub)"  --root_pass "$(date +%s | sha256sum | base64 | head -c 32 ; echo)" --group "stress-test"

Given the specified public key, password-less login will be possible. However this is far from enough before the provisioning. Booting takes time, SSH server is not available immediately, also our special situation is that after the stress test, we would like to drop the instances immediately, together with the test execution to minimize costs.

Waiting for machine booting is a slightly longer snippet, the CSV output is robustly parsable:

## Wait for boot, to be able to SSH in.
while linode-cli linodes list --group=stress-test --text --delimiter ";" --format 'status' --no-headers | grep -v running
do
  sleep 2
done

However the SSH connection is likely not yet possible, let’s wait for the port to be open:

for IP in $(linode-cli linodes list --group=stress-test --text --delimiter ";" --format 'ipv4' --no-headers);
do
  while ! nc -z $IP 22 < /dev/null > /dev/null 2>&1; do
    sleep 1
  done
done

You may realize that this is overlapping with the machine booting wait. The only benefit is that separating the two allows more sophisticated error handling and reporting.

Afterwards, deleting all machines in our group is trivial:

for ID in $(linode-cli linodes list --group=stress-test --text --delimiter ";" --format 'id' --no-headers);
do
  linode-cli linodes delete "$ID"
done

So after packing everything in one script, also to put an Ansible invocation in the middle, we end up with stress-test.sh:

#!/bin/bash

LINODE_GROUP="stress-test"
NUMBER_OF_VISITORS="$1"

NUM_RE='^[0-9]+$'
if ! [[ $NUMBER_OF_VISITORS =~ $NUM_RE ]] ; then
  echo "error: Not a number: $NUMBER_OF_VISITORS" >&2; exit 1
fi

if (( $NUMBER_OF_VISITORS > 100 )); then
  echo "warning: Are you sure that you want to create $NUMBER_OF_VISITORS linodes?" >&2; exit 1
fi

echo "Reset the inventory file."
cat /dev/null > hosts

echo "Create the needed linodes, populate the inventory file."
for i in $(seq $NUMBER_OF_VISITORS);
do
  linode-cli linodes create --image "linode/ubuntu18.04" --region eu-central --authorized_keys "$(cat ~/.ssh/id_rsa.pub)" --root_pass "$(date +%s | sha256sum | base64 | head -c 32 ; echo)" --group "$LINODE_GROUP" --text --delimiter ";"
done

## Wait for boot.
while linode-cli linodes list --group="$LINODE_GROUP" --text --delimiter ";" --format 'status' --no-headers | grep -v running
do
  sleep 2
done

## Wait for the SSH port.
for IP in $(linode-cli linodes list --group="$LINODE_GROUP" --text --delimiter ";" --format 'ipv4' --no-headers);
do
  while ! nc -z $IP 22 < /dev/null > /dev/null 2>&1; do
    sleep 1
  done
  ### Collect the IP for the Ansible hosts file.
  echo "$IP" >> hosts
done
echo "The SSH servers became available"

echo "Execute the playbook"
ansible-playbook -e 'ansible_python_interpreter=/usr/bin/python3' -T 300 -i hosts main.yml

echo "Cleanup the created linodes."
for ID in $(linode-cli linodes list --group="$LINODE_GROUP" --text --delimiter ";" --format 'id' --no-headers);
do
  linode-cli linodes delete "$ID"
done

Provisioning phase

As written earlier, Ansible is just an option, however a popular option to provision machines. For such a test, even a bunch of shell command would be sufficient to setup the stack for the test. However, after someone tastes working with infrastructure in a declarative way, this becomes the first choice.

If this is your first experience with Ansible, check out the official documentation. In a nutshell, we just declare in YAML how the machine(s) should look, and what packages it should have.

In my opinion, a simple playbook like this below, is readable and understandable as-is, without any prior knowledge. So our main.yml is the following:

- name: WDIO-based stress test
  hosts: all
  remote_user: root

  tasks:
    - name: Update and upgrade apt packages
      become: true
      apt:
        upgrade: yes
        update_cache: yes
        cache_valid_time: 86400

    - name: WDIO and Chrome dependencies
      package:
        name: "{{ item }}"
        state: present
      with_items:
         - unzip
         - nodejs
         - npm
         - libxss1
         - libappindicator1
         - libindicator7
         - openjdk-8-jre

    - name: Download Chrome
      get_url:
        url: "https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb"
        dest: "/tmp/chrome.deb"

    - name: Install Chrome
      shell: "apt install -y /tmp/chrome.deb"

    - name: Get Chromedriver
      get_url:
        url: "https://chromedriver.storage.googleapis.com/73.0.3683.20/chromedriver_linux64.zip"
        dest: "/tmp/chromedriver.zip"

    - name: Extract Chromedriver
      unarchive:
        remote_src: yes
        src: "/tmp/chromedriver.zip"
        dest: "/tmp"

    - name: Start Chromedriver
      shell: "nohup /tmp/chromedriver &"

    - name: Sync the source code of the WDIO test
      copy:
        src: "wdio"
        dest: "/root/"

    - name: Install WDIO
      shell: "cd /root/wdio && npm install"

    - name: Start date
      debug:
        var=ansible_date_time.iso8601

    - name: Execute
      shell: 'cd /root/wdio && ./node_modules/.bin/wdio wdio.conf.js --spec specs/stream.js'

    - name: End date
      debug:
        var=ansible_date_time.iso8601

We install the dependencies for Chrome, Chrome itself, WDIO, and then we can execute the test. For this simple case, that’s enough. As I referred to earlier:

ansible-playbook -e 'ansible_python_interpreter=/usr/bin/python3' -T 300 -i hosts main.yml

What’s the benefit over the shell scripting? For this particular use-case, mostly that Ansible makes sure that everything can happen in parallel and we have sufficient error-handling and reporting.

Test phase

We love tests. Our starter kit has WebdriverIO tests (among many other type of tests), so we picked it to stress test the full stack. If you are familiar with JavaScript or Node.js the test code will be easy to grasp:

const assert = require('assert');

describe('podcasts', () => {
    it('should be streamable', () => {
        browser.url('/');
        $('.contact .btn').click();

        browser.url('/team');
        const menu = $('.header.menu .fa-bars');
        menu.waitForDisplayed();
        menu.click();
        $('a=Jobs').click();
        menu.waitForDisplayed();
        menu.click();
        $('a=Podcast').click();
        $('#mep_0 .mejs__controls').waitForDisplayed();
        $('#mep_0 .mejs__play button').click();
        $('span=00:05').waitForDisplayed();
    });
});

This is our spec file, which is the essence, alongside with the configuration.

Could we do it with a bunch of requests in jMeter or Gatling? Almost. The icing on the cake is where we stress test the streaming of the podcast. We simulate a user who listens the podcast for 10 seconds. For for any frontend-heavy app, realistic stress testing requires a real browser, WDIO provides us exactly this.

The WebdriverIO test execution - headless mode deactivated

Test execution phase

After making the shell script executable (chmod 750 stress-test.sh), we are able to execute the test either:

  • with one visitor from one virtual machine: ./stress-test.sh 1
  • with 100 visitors from 100 virtual machines for each: ./stress-test.sh 100

with the same simplicity. However, for very large scale tests, you should think about some bottlenecks, such as the capacity of the datacenter on the testing side. It might make sense to randomly pick a datacenter for each testing machine.

The test execution consists of two main parts: bootstrapping the environment and executing the test itself. If bootstrapping the environment takes too high of a percentage, one strategy is to prepare a Docker image, and instead of creating the environment again and again, just use the image. In that case, it’s a great idea to check for a container-specific hosting solution instead of standalone virtual machine.

Would you like to try it out now? Just do a git clone https://github.com/Gizra/diy-stress-test.git!

Result analysis

For such a distributed DIY test, analyzing the results could be challenging. For instance, how would you measure requests/second for a specific browser-based test, like WebdriverI/O?

For our case, the analysis happens on the other side. Almost all hosting solutions we encounter support New Relic, which could help a lot in such an analysis. Our test was DIY, but the result handling was outsourced. The icing on the cake is that it helps to track down the bottlenecks too, so a similar solution for your hosting platform can be applied as well.

However what if you’d like to somehow gather results together after such a distributed test execution?

Without going into detail, you may study the fetch module of Ansible, so you can gather a result log from all the test servers and have it locally in a central place.

Conclusion

It was a great experience that after we faced some difficulty with a hosted stress test platform; in the end, we were able to recreate a solution from scratch without much more development time. If your application also needs special, unusual tools for stress-testing, you might consider this approach. All the chosen components, such as Linode, WebdriverIO or Ansible are easily replaceable with your favorite solution. Geographically distributed stress testing, fully realistic website visitors with heavy frontend logic, low-cost stress testing – it seems now you’re covered!

Feb 23 2019
Feb 23

This Public Service Announcement is a follow-up to SA-CORE-2019-003. This is not an announcement of a new vulnerability. If you have not updated your site as described in SA-CORE-2019-003 you should do that now.

There are public exploits now available for this SA.

Update, February 25: Mass exploits are now being reported in the wild.

In the original SA we indicated this could be mitigated by blocking POST, PATCH and PUT requests to web services resources, there is now a new way to exploit this using GET requests.

The best mitigation is:

This only applies to your site if:

  • The site has the Drupal 8 core RESTful Web Services (rest) module enabled.
  • OR

  • The site has another web services module enabled, like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7, or custom code that allows entity updates via non-form sources.

What to do if your site may be compromised

Take a look at our existing documentation, ”Your Drupal site got hacked, now what”.
We’ll continue to update the SA if novel types of exploit appear.

Feb 19 2019
Feb 19
Performance and scale for all levels of digital commerce


Drupal Commerce is a fantastic open source ecommerce platform, but there is a common misconception that it is lacking when it comes to performance and scalability. This is not true! Drupal Commerce is extremely fast and is more than capable of scaling from small business all the way to enterprise level ecommerce. We have proof and it’s right here for you to view.

Download the Drupal 8 Commerce Performance Benchmarks Report (PDF)

About the report

Shawn McCabe, Acro Media’s CTO, put Drupal Commerce to the test to see how it performed on a number of different AWS configurations, ranging from single server setups all the way up to multi-server configurations.

He ran simulated traffic through Drupal Commerce, mimicking actual traffic as close as possible, testing concurrent users, site speed, transactions per second, and a number of other useful technical metrics.

The smallest server configuration tested was capable of handling 130 concurrent users flawlessly, with a throughput of 13.59 transactions per second. On the other hand, the largest configuration could handle 52,000 concurrent users with a throughput of 1,305.85 transactions per second.

The report goes further and includes how the tests were set up, their limitations and methodology, all of the server configurations details and, of course, the test results. This testing puts the performance and scalability question to rest, backed by hard data that anyone can reproduce. Drupal Commerce is a viable option for ecommerce that businesses of any size can use and grow with in the future.

Feb 12 2019
Feb 12

We built a fast serializer in PHP with an overall performance gain of 55% over JMS for our use-case, and it’s awesome. We open sourced it and here it is: Liip Serializer. Let's look more at how it works, and how we made it so much faster!

For Serialization (From PHP objects to JSON, and Deserialization, the other way around), we have been using JMS Serializer for a long time in one of our big Symfony PHP projects, we are still using it for parts of it. We were and still are very happy with the features of JMS Serializer , and would highly recommend it for a majority of use cases.

Some of the functionality we would find difficult to cope without:

  • Different JSON output based on version. So that we can have “this field is here until version 3” etc.
  • Different Serializer groups so we can output different JSON based on whether this is a “detail view” or a “list view”.

The way that JMS Serializer works is that it has “visitors” and a lot of method calls, this in PHP in general cases is fine. But when you have big and complicated JSON documents, it has a huge performance impact. This is a bottleneck in our application we had for years before we built our own solution.

To find the bottleneck blackfire helped us a lot. This is a screenshot from blackfire when we were using JMS serializer, here you can see that we called visitProperty over 60 000 times!!

Our solution removed this and made our application a LOT faster with an overall performance gain of 55%, 390 ms => 175 ms and the CPU and I/O wait both down by ~50%.

Memory gain: 21%, 6.5 MB => 5.15 MB

Let’s look at how we did this!

GOing fast outside of PHP

Having tried a lot of PHP serializer libraries we started giving up, and started to think that it’s simply a bottleneck we have to live with. Then Michael Weibel (Liiper, working in the same team at the time) came with the brilliant idea of using GoLang to solve the problem. And we did. And it was fast!

We were using php-to-go and Liip/sheriff.

How this worked:

  • Use php-to-go to parse the JMS annotations and generate go-structs (basically models, but in go) for all of our PHP models.
  • Use sheriff for serialization.
  • Use goridge to interface with our existing PHP application.

This was A LOT faster than PHP with JMS serializer, and we were very happy with the speed. Integration between PHP and the GO binary was a bit cumbersome however. But looking at this, we thought that it was a bit of an unfair comparison to compare generated go code with the highly dynamic JMS code. We decided to try the approach we did with GO with plain PHP as well. Enter our serializer in PHP.

Generating PHP code to serialize - Liip Serializer

What Liip Serializer does is that it generates code based on PHP models that you specify, parsing the JMS annotations with a parser we built for this purpose.

The generated code uses no objects, and minimal function calls. For our largest model tree, it’s close to 250k lines of code. It is some of the ugliest PHP code I’ve been near in years! Luckily we don’t need to look at it, we just use it.

What it does is that for every version and every group it generates one file for serialization and one for deserialization. Each file contains one single generated function, Serialize or Deserialize.

Then when serializing/deserializing, it uses those generated functions, patching together which filename it should use based on which groups and version we have specified. This way we got rid of all the visitors and method calls that JMS serializer did to handle each of these complex use cases - Enter advanced serialization in PHP, the fast way.

If you use the JMS event system or handlers they won't be supported by the generated code. We managed to handle all our use cases with accessor methods or virtual properties.

One challenge was to make the generated code expose exactly the same behaviour as JMS serializer. Some of the edge cases are neither documented nor explicitly handled in code, like when your models have version annotation and you serialize without a version. We covered all our cases, except for having to do a custom annotation to pick the right property when there are several candidates. (It would have been better design for JMS serializer too, if it would allow for an explicit selection in that case.)

In a majority of cases you will not need to do this, but sometimes when your JSON data starts looking as complicated as ours, you will be very happy there’s an option to go faster.

Feel free to play around! We open sourced our solutions under Liip/Serializer on Github.

These are the developers, besides me, in the Lego team who contributed to this project, with code, architecture decisions and code reviews: David Buchmann, Martin Janser, Emanuele Panzeri, Rae Knowler, Tobias Schultze, and Christian Riesen. Thanks everyone! This was a lot of fun to do with you all, as working in this team always is.

You can read more about the Serializer on the repository on GitHub: Liip/Serializer

And the parser we built to be able to serialize here: Liip/Metadata-Parser

Note: The Serializer and the Parser are Open Sourced as-is. We are definitely missing documentation, and if you have trouble using it, or would like something specific documented, please open an issue on the GitHub issue tracker and we would happily document it better. We are in the process of adding Symfony bundles for the serializer and the parser, and putting the Serializer on packagist, and making it easier to use. Further ideas and contributions are of course always very welcome.

Flash image from: https://www.flickr.com/photos/questlog/16347909278

Feb 06 2019
Feb 06

Mass.gov dev team releases open source project

Moshe Weitzman

The Mass.gov development team is proud to release a new open source project, Drupal Test Traits (DTT). DTT enables you to run PHPUnit tests against your Drupal web site, without wiping your database after each test class. That is, you test with your usual content-filled database, not an empty one. We hope lots of Drupal sites will use DTT and contribute back their improvements. Thanks to PreviousNext and Phase2 for being early adopters.

Mass.gov is a large, content-centric site. Most of our tests click around and assert that content is laid out properly, the corresponding icons are showing, etc. In order to best verify this, we need the Mass.gov database; testing on an empty site won’t suffice. The traditional tool for testing a site using an existing database is Behat. So we used Behat for over a year and found it getting more and more awkward. Behat is great for facilitating conversations between business managers and developers. Those are useful conversations, but many organizations are like ours — we don’t write product specs in Gherkin. In fact, we don’t do anything in Gherkin beside Behat.

Meanwhile, the test framework inside Drupal core improved a lot in the last couple of years (mea culpa). Before Drupal Test Traits, this framework was impossible to use without wiping the site’s database after each test. DTT lets you keep your database and still test using the features of Drupal’s BrowserTestBase and friends. See DrupalTrait::setUp() for details (the bootstrap is inspired by Drush, a different open source project that I maintain).

Zakim Bridge at Night, North End Boston. Photo by David Fox.
  • Our test cases extend ExistingSiteBase, a convenience class from DTT that imports all the test traits. We will eventually create our own base class and import the traits there.
  • Notice calls to $this->createNode(). This convenience method wraps Drupal’s method of the same name. DTT deletes each created node during tearDown().
  • Note how we call Vocabulary::load(). This is an important point — the full Drupal and Mink APIs are available during a test. The abstraction of Behat is happily removed. Writing test classes more resembles writing module code.
  • See the DTT repo for details on how to install and run tests
  • Typically, one does not run tests against a live web site. Tests can fail and leave sites in a “dirty” state so it’s helpful to occasionally refresh to a pristine database.

If you have questions or comments about DTT, please comment below or submit issues/PRs in our repository.

More from Moshe: Our modern development environment at Mass.gov

Interested in a career in civic tech? Find job openings at Digital Services.
Follow us on Twitter | Collaborate with us on GitHub | Visit our site

Jan 30 2019
Jan 30

Why not just use the .gitignore file?

Kaleem ClarksonPhoto by Tim Wright on Unsplash

As many of you know, I am a huge Pantheon hosting fanboy and can still remember the days during the beta launch of being blown away that I have three different environments out of the box, with dev, test and live. Another great service they added recently is that all sites receive SSL certificates automatically and all you have to do is redirect all traffic to use HTTPS. In Drupal 8 they suggest doing this in your settings.php file.

After adding the redirect code everything works great until you fire up your local environment (I am currently using Lando) and you are getting a blank screen. After further investigation, you notice it’s the redirect to HTTPS that is causing the issue. My first thought was to make sure my settings.local.php file was correctly being used but for the life of me, I could not get that file to override the redirect code in my settings.php file. If you are reading this and have a better idea on to how to accomplish this then let me know in the comments :)

My next thought was to simply add the settings.php file to my .gitignore file but when I went to my production website I was prompted to reinstall my Drupal site. When adding a file to .gitignore the repo pretends it doesn’t exist so therefore Drupal was telling me to reinstall. Whoooops, my production site kind of needs this file hahahah. So I thought to myself,

After attending Google University for 10 minutes, I stumbled upon a medium post by Ian Gloude regarding the git update-index command. In their article “Git skip-worktree and how I used to hate config files,” there is a great explanation of the concept, but for me the lightbulb really went off when reading the Git documentation hint, “see also git-add[1] for a more user-friendly way to do some of the most common operations on the index.” Basically git update-index tells Git what to watch in your repo.

Now that we understand what git update-index does, the real magic happens with the options that you can add to the command. In this case, the option that Ian Gloude suggested is the --skip-worktreeoption. The Git documentation explains that the skip worktree bit tells the git index to assume the file is unchanged from this point on regardless if there is an actual change. So what does this mean for us? It means you can change your file on your local environment while the original file on your production server remains unchanged.

Here is the command I use prior to uncommenting out the pantheon redirect code.

git update-index --skip-worktree /sites/default/settings.php

When I need to make some changes to the production settings.php file I can tell Git to watch the file again with this command.

git update-index —-no-skip-worktree web/sites/default/settings.php

Anyway, I hope this helps you keep your local and production environments running smoothly while maintaining your settings differently.

Jan 28 2019
Jan 28

Begin with the end in mind—defining our goals

Our collaboration with South Dakota State University’s (SDSU) outreach arm, SDSU Extension, began by defining the user experience and branding issues that the previous site had. The visual design was in need of an update, the team wanted to make information easier for people to find, and mobile users were forced to view the desktop version of the site.

With these issues defined, we put together a series of goals that fell into two major groups—user experience and branding. For the user experience goals, we defined a user-centered approach to ensure that the work we were doing was going to help people using the site engage more with the site and more easily find what they were looking for. For the branding goals, we wanted an improved, modern look and feel that felt like a part of the larger South Dakota State University brand.

Creating a palette to work from (e.g. creating Style Tiles)

Every design project at Four Kitchens starts with a visual alignment in the form of style tiles, a design deliverable showing colors, fonts, and elements that helps create a common visual language for the project.

These are presented to everyone using InVision Freehand so that as we discuss the options we can add notes directly on the style tiles. For SDSU Extension we had two rounds of style tiles, landing quickly on one that we all agreed was the right direction.

Figuring out what we’ll need (e.g. wire-framing all the things)

Design systems are all the rage in the industry and with good reason. They allow projects to move more quickly by having a library of reusable parts that are ready to go. So at this point in the process for SDSU Extension, it was time to define what those parts needed to be.

We did this by reviewing the current site and discovery document to suss out what was going to be important for the new site. As a group—Four Kitchens and SDSU Extension—had discussions to detail what sorts of things would be vital and what would be nice-to-haves.

From there we worked up a series of wireframes that showed both a component library—a page with every possible thing on it, like cards, quotes, and video callouts—and a few samples of how the new pages could be assembled from these parts.

This process worked out the kinks for trickier components, like the many-level deep navigation on mobile while minimizing effort. The cycle of posting, review, and implementing feedback was quick leading us to a final collection of wireframes.

Making it come to life (e.g. comps)

As soon as wireframes were approved we moved into the next step—breathing life into them. We took the visual language that was defined in the style tile and applied it to the wireframes. The designs included all of the components at small, medium, and large screen sizes.

These components were then quickly assembled into mock pages to show what they would look like when the site was done. Having a wealth of work already done in the form of style tiles and wireframes, we hit on the right direction quickly. Once the first few comps were finalized there was a flood of comps as we built them out faster and faster using previously approved components.

A great collaboration

Working with SDSU Extension on this project was marvelous and we’re happy that it is live and shared with the rest of the world.

Jan 22 2019
Jan 22

This article was previously posted on Medium (Nov 2018). 27 Attendees representing 18 Drupal events from around the world. It’s been almost one month since I wrote the blog post, “DrupalCamp Organizers Unite: Is it Time for Camp Organizers to Become an Official Working Group” and a ton of things have transpired that will catapult us into 2019 with some great momentum. With the support of the many Drupal evangelists, over 50 Drupal event organizers from around the world signed up to attend our first official / unofficial video call.

Then on Friday, November 8, a few hours leading up to the video call, The Drupal Governance Taskforce 2018 Proposal was released. This proposal was put together by the Governance Taskforce in an effort establish a community directive that helps create the next generation of Drupalers. One of the recommendations in this proposal was to provide in-person events, more support, and to establish a Drupal community events working group. The timing of the proposal was perfect for our call. It was really great to see that us organizers were not the only ones who acknowledged that our community events are crucial to Drupal adoption.

Are you a Drupal Event Organizer? Well, join us at our next meeting on Tuesday, January 8, 2019, at 12 pm (EST). Register Here

When the time came to start the call I was a little nervous that not very many people would attend and then all of a sudden the chimes started going off and faces appeared on the screen. After 5 minutes we had 25 people on the call. It was inspirational to be a part of something big. It felt like we were the United Nations :).

Countries Represented
Canada, Mumbai, Netherlands, Switzerland, United Kingdom, United States.

Drupal Events Represented
BADCamp(2), Drupal Association(2), Drupal North, Drupal Camp Asheville, DrupalCamp Atlanta, Drupal Camp Chattanooga, DrupalCamp Colorado, DrupalCorn(2), Drupaldelphia, Drupal Mountain Camp, Drupal Camp Mumbai, DrupalCamp New Jersey, Florida Drupal Camp (2),Frontend United, GovCon, MidCamp(2), NED Camp(4),Victoria BC Meetup.

Major Points from the November 9th Meeting

  1. The next meeting will be held on Tuesday, January 8, 2019, at 12 pm (EST). Register Here
  2. Comment on Governance Taskforce Proposal Issue 
    To help Dries Buytaert, prioritize the recommendation of creating a Community Events Working Group, we need as many people as possible to comment on this issue. Please view the issue and indicate why you believe this working group is critical to the success of Drupal. Comment now!
  3. DrupalCamp Website Starter Kit 
    Out of all of the discussions, the common pain point is that the website takes up too much of our limited resources. The idea of an event starter kit, instead of a distribution, was really intriguing to us all. We also discussed all of the events donating funding to hire a professional project manager to scope out what a starter kit would look like.
  4. Drupal.org Events Website 
    Many of us use the great Drupical to let us know what events are happening. But if you don’t know about that website there is nowhere on Drupal.org that is easily accessible that promotes Drupal events. The idea that was brought to the table was to design a new section of the community page that is a space specifically for promoting and producing Drupal events.
  5. A Centralized Drupal Event Statistics Hub
    Another website related item that was brought up was the idea of centralized data hub that event organizers could submit crucial data of events (attendance, budget, programing etc.) so that Drupal.org could display the data and allow for data manipulation. For example, it would be great to know how many people attended Drupal events in one year. This data would be extremely powerful as it could help organizers to compare events, drive corporate sponsorships and adoption, and get more people involved with Drupal.
  6. DrupalTV — A website with all Drupal Videos
    The topic around Drupal video content came up and one of the biggest issues was that videos are all over the place and are not organized. To solve this problem, the idea of a centralized website (DrupalTV) where videos were tagged by topic, presenter, module, etc.. would allow for content to be easily found. This idea was started before our meeting and you can see a proof of concept here.

I was very happy to be a part of this first meeting and I hope that Drupal leadership also sees the work we do as critical and will make us an official working group. There were a lot of great conversations that took place so I am sure that I have missed something. Feel free to comment and let me know and I will update the post.

Are you a Drupal Event Organizer? Well, join us at our next meeting on Tuesday, January 8, 2019, at 12 pm (EST). Register Here

You can also join the Drupal Event Organizers Slack community. You can also register for any of our meetings to be added to our emailing list.

Jan 22 2019
Jan 22

This article was previously posted on Medium (Nov 2018).  You Can’t Put a Price Tag on Visibility, Creditability, and Collegiality. Organizing a DrupalCamp takes a lot of commitment from volunteers, so when someone gets motivated to help organize these events, the financial risks can be quite alarming and sometimes overwhelming. But forget all that mess, you are a Drupal enthusiast and have drummed up the courage to volunteer with the organization of your local DrupalCamp. During your first meeting, you find out that there are no free college or community spaces in the area and the estimated price tag is $25,000. Holy Batman that is a lot of money!

Naturally, you start thinking about how we are going to cover that price tag, so you immediately ask, “how many people usually attend?” Well unless you are one of the big 5, (BADCampNYCCampDrupal GovConMidCamp or FloridaCamp) we average between 100 and 200 people. Then you ask, “how much can we charge?” You are then told that we cannot charge more than $50 because camps are supposed to be affordable for the local community and that has been the culture of most DrupalCamps.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

If Drupal is the Enterprise solution why are all of our camps priced and sponsored like we are still hobbyist in 2002?

Why Don’t We Treat DrupalCamps Like It’s the Enterprise Solution?

Drupal is the Enterprise solution. Drupal has forgotten about the hobbyist and is only concerned about large-scale projects. Drupal developers and companies make more per hour than Wordpress developers. These are all things I have heard from people within the community. So if any of these statements are valid, why are all the camps priced like it is 2002 and we are all sitting around in a circle singing Kumbaya? In 2016 for DrupalCamp Atlanta, we couldn’t make the numbers work, so we decided to raise the price of the camp from $45 to $65 (early bird) and $85 (regular rate). This was a long drawn out and heated debate that took nearly all of our 2 hours allotted for our google hangout. At the end of the day, one of our board members who is also a Diamond sponsor said,

“when you compare how other technology conferences are priced and what they are offering for sessions, DrupalCamps are severely under-priced for the value they provide to the community.

If a camp roughly costs $25,000 and you can only charge 150 people $50, how in the world are DrupalCamps produced? The simple answer, sponsors, sponsors, and more sponsors. Most camps solely rely on the sponsors to cover the costs. One camp, in particular, BADCamp has roughly 2,000 attendees and the registration is FREE. That’s right, the camp is completely free and did I forget to mention that it’s in San Francisco? Based on the BADCamp model and due to the fact the diamond sponsorship for DrupalCon Nashville was $50,000, getting 10 companies to sponsor your camp at $2,500 will be no sweat. Oh and don’t forget Drupal is the enterprise solution, right?

With all of your newfound confidence in obtaining sponsorships, you start contacting some of the larger Drupal shops in your area and after a week nothing. You reach out again maybe by phone this time and actually speak to someone but they are not committing because they want some more information as to why they should sponsor the camp such as, what other perks can you throw in for the sponsorship, are we guaranteed presentation slots, and do you provide the participant list. Of course, the worst response is the dreaded no, we cannot sponsor your conference because we have already met our sponsorship budget for the year.

At this point, you feel defeated and confused as to why organizations are not chomping at the bit to fork over $2,500 to be the sponsor. Yep, that’s right, twenty-five hundred, not $25,000 to be the highest level, sponsor. Mind you many Drupal shops charge anywhere between $150 — $250 an hour. So that means donating 10–17 hours of your organizations time to support a Drupal event in your local community. Yes, you understand that there are a lot of DrupalCamps contacting the same companies for sponsorship so you ask yourself, what has changed from years past?

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

What Do Companies Expect to Gain From DrupalCamp Sponsorships?

At DrupalCon Nashville, I got an awesome opportunity to participate in a session around organizing DrupalCamps. It was really interesting to hear about how other organizers produce their camp and what were some of the biggest pain points.

During this session, we were talking about a centralized sponsorship program for all DrupalCamps (that I personally disagree with and will save that discussion for another blog post) and an individual asked the question,

“why should my company sponsor DrupalCamp Atlanta? There is nothing there for me that makes it worth it. We don’t pick up clients, you don’t distribute the participant list, so why should we sponsor the camp?”

Needless to say, they caught me completely off guard, so I paused then replied,

“DrupalCamp Atlanta has between 150–200 people, most of them from other Drupal shops, so what is it that you are expecting to get out of the sponsorship that would make it worth it to you? Why do you sponsor any DrupalCamps?”

Have Drupal Companies Outgrown the Need to Sponsor DrupalCamps?

On the plane ride back to the ATL it got me thinking, why does an organization sponsor DrupalCamps? What is the return on their investment? I started reminiscing of the very first DrupalCamp that I attended in 2008 and all the rage at that time (and still is), was inbound marketing and how using a content strategy and or conference presentations can establish your company as thought leaders in the field, therefore, clients will find your information useful and approach you when its time to hire for services. Maybe this is why so many camps received a ton of presentation submissions and why it was easy to find sponsors, but that was over 10 years ago now and some of those same companies have now been established as leaders in the field. Could it be, that established companies no longer need the visibility of DrupalCamps?

What happens to DrupalCamps when companies no longer need the visibility or credibility from the Drupal community?

The Drupal community thrives when Drupal shops become bigger and take on those huge projects because it results in contributions back to the code, therefore, making our project more competitive. But an unintended consequence of these Drupal shops becoming larger is that there is a lot more pressure on them to raise funding thus they need to spend more resources on obtaining clients outside of the Drupal community. Acquia, the company built by the founder of Drupal, Dries Buytaert, have made it clear that they are pulling back on their local camp sponsorships and have even created their own conference called Acquia Engage that showcases their enterprise clients. Now from a business perspective, I totally understand why they would create this event as it provides a much higher return on their investment but it results in competing with other camps (ahem, this year’s DrupalCamp Atlanta), but more importantly the sponsorship dollars all of us depend on are now being redirected to other initiatives.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

Why Should Established Companies Sponsor a DrupalCamp?

The reality of the situation is that sponsoring these DrupalCamps are most likely not going to land your next big client that pays your company a $500,000 contract. So what are true reasons to sponsor a DrupalCamp:

  • Visibility
    When sponsoring these DrupalCamps most of us organizers do a pretty good job of tweeting thanks to the company and if the organization has presenters we usually promote the sessions as well. In addition, most camps print logos on the website, merchandise, and name after parties. Yes, its only a little bit but the internet is forever and the more you are mentioned the better off you are. But you are from a well established Drupal shop so you don’t need any more visibility.
  • Credibility 
    Even the companies who are have been established need their staff to be credible. There will always be some amount of turnover and when that happens your clients still want to know if this person is talented. And if your company is new, being associated with Drupal in your local community does provide your company a sense of credibility.
  • Collegiality 
    I saved the best for last. Collegiality is highly overlooked when looking at sponsoring camps. Most companies have a referral program for new hires and when the time comes for you to hire, people tend to refer their friends and their professional acquaintances. There is no better place to meet and interact with other Drupalist than a DrupalCamp. What about employee engagement? In a recent focus group I participated in with a Drupal shop, many of the staff wanted more opportunities for professional development. These local camps are affordable and can allow staff to attend multiple events in a year when you have small budgets.

I must end by saying, that there are so many great Drupal companies that I have had the pleasure to work with and if it were not for the Acquia’s of the world Drupal wouldn’t exist. I understand that CEO’s are responsible for their employees and their families so I don’t want to underestimate the pressures that come with making payroll and having a client pipeline. The purpose of this post was to explain how it feels as a volunteer who is doing something for the community and the frustrations that sometimes come with it.

If you are interested in sponsoring a DrupalCamp check out Drupical and sponsor a camp today! All of us organizers need your help!!

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

If you are also interested in contributing to the Atlanta Drupal Users Group (ADUG) Medium Blog publication, please feel free to reach out to us at [email protected]

Jan 20 2019
Jan 20

This article was previously posted on Medium (Oct 2018). Community, community and more community. One of the common themes we hear when it comes to evaluating Drupal against other content management systems (CMS), is that the community is made up of over 100,000 highly skilled and passionate developers who contribute code. And in many of these application evaluations, it’s the community, not the software that leads to Drupal winning the bid. We have also heard Dries Buytaert speak about the importance of the community at various DrupalCons and he is quoted on Drupal.org’s getting involved page:

“It’s really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base.” — Dries Buytaert

My First Encounter with the Drupal Community

With this emphasis on community, I tried to think back to how and when I first interacted with the community. Like so many others, my first introduction to Drupal was at a local Meetup. I remember going to this office building in Atlanta and the room was packed with people, plenty of pizza, soda and, of course, laptops. It was a nice relaxed atmosphere where we introduced ourselves and got a chance to know each other a little bit. Then the lights dimmed, the projector turned on and the presentations kicked off, highlighting some new content strategy or a new module that can help layout your content. After that first meetup, I felt energized because until that point, I had never spoken with someone in person about Drupal and it was the first time that I was introduced to Drupal professionals and companies.

DrupalCamps Play An Integral Role in Fostering Community

After attending a few meetups, I joined the email list and I received an email announcing DrupalCamp Atlanta was going to be held at Georgia Tech and the call for proposals was now open for session submissions.

I purchased a ticket for a mere $30 and added it to my Google calendar. On the day of the event, I remember walking in the front door and being blown away by the professionalism of the conference as there were sponsor booths, giveaways, and four concurrent sessions throughout the day. But it wasn’t until I was inside the auditorium during the opening session and saw the 200 or so people pile in that made me realize this Drupal community thing I heard about was for real. Over the next couple of years, I decided that I would attend other camps instead of DrupalCon because the camps were more affordable and less intimidating. My first camp outside of Atlanta was Design4Drupal in Boston, DrupalCamp Charlotte, DrupalCamp Florida and BADCamp were all camps I went to before attending a DrupalCon. All of these camps were top notch but what I really loved is that each camp had their own identity and culture. It’s exactly what I think a community should be and for the very first time, I felt that I was a part of the Drupal community.

Why Establish the DrupalCamp Organizers Council?

As provided in my previous examples, one of the advantages of Drupal comes from the great community and DrupalCamps are an important aspect in fostering this community. Running any event can be challenging, but to pull off a respectable DrupalCamp you have consider so many things such as the website, credit card processing, food, accepting and rejecting sessions, finding a keynote speaker, the afterparty, pre-conference trainings, oh and did I mention the website? You get my drift, it's a lot of work. Many of these tasks just roll off my tongue from past experience so ask yourself;

  • Where can I share my knowledge with other people who organize camps?
  • What if there was some way that all of us DrupalCamp organizers could come together and implement services that make organizing camps easier?
  • How could we provide camp organizers with resources to produce great camps?

During the #AskDries session at DrupalCon Nashville (listen for yourself), Midwest DrupalCamp Organizer Avi Schwab asked Dries the following question;

“... giving the limited funding the Drupal Association has, where should we go in trying to support our smaller local community events?” — Avi Schwab

Dries then responded with:

“That’s a great question. I actually think its a great idea what they (WordCamp) do. Because these camps are a lot of work. ...I think having some sort of central service or lack of a better term, that helps local camp organizers, I think is a fantastic idea, because we could do a lot of things, like have a camp website out of the box, ... we could have all sorts of best practices out of the box .” — Dries Buytaert

DrupalCamp Slack Community was the first time that I was provided a link to a spreadsheet that had the camp history dating back to 2006 and people were adding their target camp dates even if they were just in the planning stages. As a camp organizer I felt connected, I felt empowered to make better decisions and most of all I could just ask everyone, hey, how are you doing this?

Are you interested in attending the first online DrupalCamp Organizers meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

Earlier this year I volunteered for the Drupal Diversity and Inclusion Initiative (DDI) and was inspired when I heard Tara King on the DrupalEasy podcast, talk about how she just created the ddi-contrib channel on the Drupal slack and started hosting meetings. All jazzed up and motivated by that podcast, I reached out to over 20 different camp organizers from various countries and asked them if they would be interested in being on something like this? And if not, would they feel represented if this council existed?

Here are some quotes from Camp Organizers:

“I think a DrupalCamp Organizers Council is a great idea. I would be interested in being a part of such a working group. Just now I’m restraining myself from pouring ideas forth, so I definitely think I’m interested in being a part.”

“I am interested in seeing something that gathers resources from the vast experiences of current/past organizers and provides support to camps.”

“I definitely would appreciate having such a council and taking part. I’ve now helped organize DrupalCamp four times, and this was the first year we were looped into the slack channels for the organizers.”

“I really like the idea — what do we need to do to get this started?”

What are the Next Steps?

Based on the positive feedback and the spike in interest from other camp organizers I have decided to take the plunge and establish our first meeting of DrupalCamp Organizers on Friday, November 9th at 4:00pm (EST). This will be an online Zoom video call to encourage people to use their cameras so we can actually get to know one another.

The agenda is simple:

  • Introductions from all callers, and one thing they would like to see from the council.
  • Brainstorm the list of items the council should be advocating for.
  • Identify procedures for electing people to the Council: ways to nominate, eligibility criteria, Drupal event organizer experience required etc.
  • Outline of a quick strategic plan.
Jan 18 2019
Jan 18

drupal seo kickstart sources

Drupal is phenomenal for SEO.

When you use Drupal 8 for your content management system, you have a powerful tool to rock search engine optimization.

Working with Drupal websites for the past 12 years, I've experienced firsthand just how quickly search engines respond to a well-optimized Drupal website. I’ve seen customers triple their traffic in weeks after upgrading from another platform.

I’ve seen competitive advantages from site-wide optimizations like RDF or AMP that put my clients on the cutting edge of SEO because they use Drupal. The benefits are a faster website, higher rankings, and more traffic.

One of the main reasons Drupal is the content management system of choice for complex enterprise websites is the fact that it has been built from square one with the functionality and flexibility needed to optimize every node view, and snippet of code for search engines.

Drupal has brought many new additions for ease-of-use, functionality, and robustness. It is the superior method for creating and marketing your website to the world. Yet, for all its improvements, the most recent release still feels like Drupal. Faster, cleaner, more refined, and certainly more up-to-date, but still Drupal.

With the introduction of Drupal 8, I saw a need for helping marketers using Drupal make the most of the features available to optimize their website. With that in mind, I wrote Drupal 8 SEO. Written for marketers, Drupal 8 SEO provides the step-by-step details you need to rock Drupal 8 SEO. If you follow the steps in the book, the rewards will be great: increased Google ranking, higher website traffic, more customers and greater revenue. In fact, we based our own Drupal SEO Kickstart service on this book.

Drupal 8 SEO is over 200 pages of detailed instructions for making the most of Drupal 8’s core features and optional modules to optimize your website. While there is much to share, I have chosen six tips you can use to get started on the road to rocking Drupal 8 SEO.

1.     Download the Drupal SEO Checklist Module

I may be biased because I’m the author, but I believe the most important thing you can do is download the Drupal SEO Checklist module at Drupal.org. Robert Shea of IBM says that “Drupal SEO Checklist is the most powerful Drupal module that ‘does nothing.’ ” Essentially, this module just tells you what to do.

Following the Drupal SEO Checklist, you can implement the best modules and tasks that are needed to optimize your website. By giving you a complete list of best practices, it makes on-page Drupal SEO hassle-free. When you have completed the to-do list, you will have a fully optimized website.

The module’s tasks are segmented by functional needs like Title Tags, Paths, Content and more. Next to each task is a link to download the module and a link to the proper admin screen of your website so that you can configure the settings perfectly. Drupal SEO Checklist also keeps track of what has already been done by placing a date and time stamp next to each item.

The SEO Checklist Module tells you what to do, but it doesn’t tell you how to do it. For that, check out my book, Drupal 8 SEO. This book has been written to explain how to implement the suggestions in the SEO Checklist. You can even turn on Drupal 8 SEO Checklist Book page numbers so that you can quickly find the corresponding page in the book.

2.     Clean up your URLs

To make Drupal 8 optimization as effective as it can be, you need to ensure your URLs are clean, your site shows the right content, and link value is maintained even when your content changes.

Drupal 8 installs clean URLs by default and it can’t be turned off, but you can do even more with the Redirect module. In Drupal 8, using the Redirect module allows you to redirect from old URLs to new URLs. This is great when you’ve moved a piece of content to another section of your site or inadvertently changed the URL.

The Redirect module creates 301 redirects from old URLs to new URLs on your website. This aids SEO by making sure that any URL that ranks in Google will still resolve when a visitor arrives. This module automates what once was an arduous and ongoing SEO chore – fixing broken links. Now you can turn on this module and forget about it.Have you ever moved content, put the wrong URL on printed advertising, or migrated content from another website? Then you know the problems this can create. With the Redirect module you can also create your own manual redirects.

Another great module for SEO is the Pathauto module. Using the Pathauto module, Drupal 8 automatically generates URLs for your content that are great for SEO. This means that you don’t need to manually create every single content URL on your website.
 

3.     Implement meta tags

Meta tags are an important step to making Drupal 8 as effective as it can be. Meta tags are snippets of text that are used to tell Google, other search engines and social media sites about the content on each page of your website. This helps your SEO by communicating clearly what you think each page on your website is about and how you want it described on their sites. If you don’t do this, you will have to rely on the search engines to make up their own minds about your content. While they’re pretty good at this, it’s important enough that you don’t want to leave it to chance.

  • The Metatag module allows you to automatically provide title tags and structured metadata to each page of your website. This module places both the HTML title tag and meta tags in the header of a web page. This means less code and faster rendering of your web pages which also helps with your SEO.
     
  • The Alternate Hreflang Module automatically adds hreflang tags to all or your website pages. Search engines reference the alternative hreflang tag to serve the correct language or regional URL in the search results. This is very important for multilingual websites.
     

4.     Communicate directly with search engines

drupal 8 seo kickstart by volacciSearch engines want to help you help them crawl and index your website. In order to do this, they provide tools and reports to help you communicate with them and better understand what’s going on with your website. The marketers who do this well will receive better search results and get a lot of traffic.

  • The XML Sitemap module creates an XML sitemap of your content that you can submit to the search engines. An XML sitemap is a specially formatted summary of each piece of content on your website. The module creates a properly formatted XML sitemap that can be submitted to Google, other search engines and other sites. Having an XML sitemap helps your SEO by giving Google a list of all your pages that you wish them to crawl. While Google can crawl your site without an XML sitemap, the larger and more complex your site becomes, the higher the chance that their crawler will get confused and miss pages or even whole sections of the site.
     
  • Cron is a system that maintains and cleans up your Drupal site. It does things like check for updates, index content, and rebuild XML sitemaps. Now your XML sitemap will stay up to date with all the new content that you add to your website.
     
  • The Google Analytics module adds the Google Analytics code snippet to your website and allows you to control how and when it is used. Google Analytics is an incredibly important tool for any web marketer. It allows you to find valuable insights into your visitors including demographics, behavior on your site, where they found you online, what keywords they used to find you and more. However, Google Analytics isn’t perfect. For example, it tracks all visitors by default—even Admins. The Google Analytics module can fix that by only showing the Google Analytics code snipped when a non-admin is using the site. This keeps your data clean and your reports more useful.
     

5.     Download the best Drupal 8 modules for SEO

No one thing is so powerful that Google is going to suddenly fall in love with your website and boost you in the SERPs (Search Engine Results Pages). Rather, all the tools work together to produce an outcome that is significantly better than the parts alone ever could. The Drupal modules I’ve mentioned above are just a few of the very best. I’ve listed others in the book and in the Drupal SEO Checklist including:

  • While Drupal 8 now includes RDF (Resource Description Framework) in its core, the RDF UI module goes a step further by allowing site builders to integrate Schema.org seamlessly during or after the site building process on Drupal 8. This is important because, as Schema.org describes it, “On-page markup helps search engines understand the information on web pages and provide richer search results.”
     
  • The Linkit Module provides an easy interface for creating links in your WYSIWYG content editor by using an autocomplete field. It makes sure that all the links that you add to your content are well-formed, up to date and automatically use the proper path. Properly formed and placed links are a powerful strategy for any SEO campaign.
     
  • The D8 Editor Advanced Link Module helps your SEO by placing additional text information about each link on your website.
     

6.     Speed up and secure your website

Two important attributes of your website are security and speed. Google rewards websites that are secure (using https with a valid SSL certificate) and quick to render. All the great SEO in the world won’t make your site great if you get hacked. There are bad people on the internet who want to break your website, infest your visitors, steal your data, and/or blackmail you. From the Panama Papers fiasco (yes, Drupal was involved) to your garden-variety script kiddie, you’ve got to protect yourself and your Drupal website.

Speed became a ranking factor for Google searches in April of 2010. This means that, all else being equal, the faster site will rank higher. Therefore, it makes great sense to ensure that your site is as fast as you can reasonably make it within your budget.

Drupal 8 has responsive web design as its default methodology. That’s good because Google specifically states that they prefer this method for serving mobile devices. In this setup, the server sends the same HTML code to all devices and CSS is used to change the way the page looks for each mobile device. It allows a single URL for the same content and that’s great for sharing and for offering up pages to all visitors. One way to speed up your website and be mobile-responsive is by downloading and implementing the Google AMP module.

Learn More with Drupal 8 SEO

Search engine optimization is a game of inches. A title tag that’s missing a keyword, a body that doesn’t talk about the topic, metadata that isn’t quite right. Together, that’s enough to kick you off the front page of Google. Using just the tips above will help you down the path toward a rockin’ Drupal website. Of course, there is much more to learn. If you want to optimize your website yourself, you can find all the details in my book, Drupal 8 SEO.

If you don’t have the time to optimize your own Drupal website, sign up for our Drupal SEO Kickstart program -- we'll get these items (and a lot more) installed and optimized in short order. Volacci can implement the best of Drupal SEO whether you are creating a new website, you are migrating from one platform to another, or you just need to fix what you have.

Jan 17 2019
Jan 17

When we say DrupalCon, the upcoming DrupalCon Seattle 2019 event is probably what first comes to mind. But while we have been selecting sessions, setting up BoFs, and letting you know about the additions to our Con, we at the Drupal Association have also been looking ahead to DrupalCons of the future. We are excited to share those with you now.

In the past, we used to announce the next DrupalCon location during the closing session of the previous Con. This was a lot of fun, but created some logistical problems for the events team, and made it difficult to do all the work we need to do to secure our next con locations. It is a multi-year process to secure a venue for DrupalCon, so we've made some changes that help us coordinate with venues, hotels, and partners without relying on a veil of secrecy.

You first saw this change during the DrupalCon Nashville Closing Session, where we announced both 2019 (Seattle) and 2020 (Minneapolis).

We're taking these changes a step further by looking far into the future to announce the North American DrupalCons for 2021, 2022, 2023 and 2024. We're thrilled to announce the selected cities, as well as share the process that went into making these selections.

Where DrupalCon is going

Together with each of our partner cities, we're excited to announce the upcoming locations for DrupalCon North America:

  • DrupalCon Boston North America 2021 Online (April 12-16)
  • DrupalCon Portland 2022 (Oregon, April 25-29)
  • DrupalCon Pittsburgh 2023 (June 5-9)
  • DrupalCon Portland 2024 (Oregon, May 6-10)

Want to understand the process that goes into city selection? The search for each location starts four or more years before the event, and you can read on for the inside scoop into how this plan came together. Wondering why all the selected cities are in the USA? We encourage you to read our prior blog about why the sustainable choice for North American locations is in the United States for the foreseeable future.

How we got here 

Planning for the future

Historically, DrupalCon locations have been contracted a couple of years before they happened, in a city where we were excited to host the community, that we revealed in a fun fashion at our Closing Session the prior year.

However, announcing the new event only a year in advance—and selecting new cities for every event—created some logistical problems; conference center venues large enough to host DrupalCon are often booked four or more years in advance. This has meant that cities we would love to visit have often simply been booked during the dates that would work with our community needs, or are too expensive because we couldn't make multi-year commitments - which took a lot of options off the table.

In benchmarking ourselves with comparable conferences (in size, audience, and program), it became clear that many established organizations were booking multiple years in advance. This is in part due to the availability of desirable cities, but also that securing locations in the future equates to more competitive pricing.

As the Drupal Association matures and starts leading change in the community and in the open source world, we determined it was best to look farther into the future for our largest annual conference.

Creating a location pattern that the community can count on

We took a serious look at data from past attendance, the locations we're trying to reach, and where we see the most traction from the community.

In analyzing data from DrupalCons dating back to DrupalCon Austin 2014, we were able to deduce some high-level insights about our attendees:

  • 88% of attendees at DrupalCon North America come from the United States
  • In hosting a DrupalCon in a coastal city in the USA, attendance from the regional community local to those cities can be 13-17% higher than the regional attendance we see in other cities (not counting those who travel greater distances).
  • Conversely, when hosting a Con in the center of the country, attendance decreases significantly from the coastal audiences and does not significantly increase from the hosted-area region.

With the majority of our conference attendees in mind, we set out to host our conference in coastal cities, where, by ‘showing up’ our community has proven they want to go. This led us to primarily work on sourcing East Coast and West Coast cities for the upcoming years.

With our upcoming DrupalCon Seattle 2019 on the West Coast, and DrupalCon Minneapolis 2020 in the middle of the USA, we aimed to host DrupalCon 2021 on the East Coast, and from there, jump between the coasts for the foreseeable future.

The benefits of repeating cities

As we did with timing and location, we also stepped back to ask ourselves, why do we move this conference every year? The logical answer is that it makes the conference more accessible to new audiences in different areas. But our past attendee data doesn't support this conclusion. So we asked ourselves again: If it isn't bringing in large numbers of new first-time attendees, why do we search for a new city every year?

We had heard anecdotally that it was because ‘Drupalers like to go on vacation in new cities’ and that ‘it helps grow the community in a new city,’ but these answers aren't well supported by the data, so we decided to re-evaluate our strategy.

When we release our RFP to the world, we work internally with the Drupal Association Board to determine our Selection Criteria. A lot of this hasn’t changed because the Con hasn’t changed drastically in a few years. The top 5 things that we evaluated in each city’s bid were:

  • Large/versatile venue - Could the venue fit our 150+ sessions, 3,000 people for lunch, and the breadth of programming offered at our Cons?
  • Popular tourist area - Do people want to go there? Is there a wealth of activities for them post-sessions each day?
  • Strong business community - Do we already have partners in the city? Is it a place our sponsors have expressed as a city where they’d like to do business?
  • Tech-focused city - Is the city supportive of tech and open source? Are there businesses and organizations that may participate in our event because we are in their city?
  • Large and strong Drupal community - Does this city have a community that has hosted a successful camp in the past? Is there a solid community that regularly meets and would help support the planning of a Con?

It had been a few years since we selected new DrupalCon cities, so reviewing and updating the criteria seemed prudent. We added and changed the following criteria:

  • CHANGE: In the venue criteria, we included the ability to change the program around, since as the community grows and changes, we want to be able to flex our program.
  • ADD: Welcoming to all attendees. We wanted to make sure that topics such as legislative actions, political climates, and inclusiveness of the cities were taken into account to ensure that we were placing our Con in a city where all members of our community would feel welcome.
  • CHANGE: When DrupalCons were mostly managed by the community, the need for a large and strong community was imperative to the success of a Con. Since the Drupal Association has taken on the bulk of planning, pricing, and executing of the Con, the need for the community to be of a certain size is no longer a qualifying factor. In fact, by changing the focus, we could look at cities that didn’t have large community groups at the time, but maybe a Con could inspire one.

When we examined our search criteria and started matching it up with real cities that we could reach out to, the list became short. With that reality, it became apparent that we would need to begin repeating cities. We seized the opportunity to proactively address that reality.

In speaking with tech event leaders from other communities and organizations, it was helpful to get a fuller understanding regarding the benefits of repeating a city location:

  • Time: Securing multiple years can save an organization time, money and peace of mind. By doing this, you eliminate the need to do site visits and RFP gathering again the following year.
  • Staff Capacity: By hosting an event somewhere you’ve already been, the staff does not need to learn a new floor plan, crew, process, regulations, etc. It is estimated that in eliminating these normal challenges of a new venue, that the staff capacity can be reduced by 25%, freeing them up to focus on the event itself.
  • Negotiation: Planners can gather information on the facility once and focus on strategic negotiating, which translates to consistent concessions and commissions with minimal increases in rates/pricing annually.
  • Cost Savings: Event budgets can be determined early, giving the planner more time to focus on the important things like planning for the success of the event. And, if you have done all of this well in the beginning, you will have the peace of mind to know that you are prepared for surprises that inevitably come along.
  • Relationships: Multiyear contracts require a partnership. Planners, venues, and hotel partners can create a strategic plan to build the event and their services. In working with a crew for more than one year, improvements can be made and the crew is better prepared to serve the attendees the next time around.

Getting from ideas to contracts

We released our RFP on August 13, 2018, on the Drupal Association blog. It was also sent to multiple cities that met our criteria. Within our RFP, we shared our tight timeline, with the goal of signing contracts for 2021, 2022, 2023, and 2024 by the end of 2018. Below is a glimpse into the work that transpired between launch date and sign date.

  • September 4, 2018. Is the date that we requested cities submit their detailed bids. Per our RFP, we had multiple questions about space needs, catering, AV, diversity and inclusion, internet, hotels, and more.
  • September 5-11. Partnering with our fantastic production partner, Groundswell Marketing, we reviewed the proposals to see if any questions arose initially about the information provided. Most proposals were 30+ pages of information with pricing grids, proposed hotel blocks, and ‘why our city’ info. We ask each city for some hard numbers on regular items like a gallon of coffee or the hourly rate of an AV technician. This helps us immediately get a picture of a Con cost.
  • September 11 - September 17. For cities we hadn’t been to before, the next step was to interview the city via a Zoom call to better understand how they were a good fit for our conference. Questions like ‘how would attendees be made to feel welcome in your city?’ and ‘How easy and affordable is it to get from the airport to the Convention Center?’ are asked in our initial determination.
  • September 18 - 21. Once we determined cities that met our criteria, we dug a bit deeper into each city’s numbers. We laid out the entire Con on their floor plans to determine if we could fit and how. We inquired about real quotes for line items like our AV and our internet. We costed out catering estimates and space rental.
  • September 24 - October 26. With our list in hand, we did our due diligence visiting possible future Con locations. In these meetings we reviewed the space and discussed how the attendee experience would feel. We met representatives from various departments of the Convention Center’s team to negotiate pricing and discuss pain points. We also did a whirlwind tour of the city to get a feel of what attendees would see/do after the Con each day.
  • October 29 - November 14. We reviewed all of this information with the Drupal Association leadership team and collaboratively determined the priority of cities based on our search criteria. Going further, we then included data points on pricing, incentives, conference dates, etc, to come to a final recommendation for each year.
  • November 15 - December 3. Built a working budget with concrete numbers for each preferred city to get an accurate future picture of finances. This involved getting future pricing on catering, network, hotel rates, etc. Worked back and forth with the city to negotiate down pricing.
  • December 5. Presented recommendation to the Drupal Association Board for buy-in and support.
  • December 6 - 27. Requested contracts from our preferred venues and hotels. Each city has one Convention Center, and at least 5 hotels, so in asking for these hotels, we had about 20 contracts to review. By looping in our legal team and our insurance group, we were able to further negotiate terms that make committing to future years smart, sustainable, and safe.
  • December 28. Signed the last contract and sent it off to the cities. Signing before the end of the year met a contracting deadline that gave us a lot of financial benefits.
  • End of December. CELEBRATED the end of this intense and action-packed process, and the future of sustainable and secured DrupalCon programming.

Serving our community

We aim toward growing adoption, one of the Drupal Association’s main goals. In planning ahead and setting ourselves up for a sustainable and fiscally responsible future conference plan, we can allocate our resources better to focus on creating a successful event that drives to this goal. By making these decisions now, we work to strengthen the foundation of the Association in order to continually work to serve our incredible and growing open source community.

We appreciate the questions and interest that community members have had in this process and were happy to do a deep dive to show you the planning, strategy, and work involved in selecting a city for a future DrupalCon. We invite you to share your thoughts and comments below, and we look forward to seeing you at a Con in the future.

Jan 08 2019
Jan 08

Creating an 'Add to Calendar' Widget in Drupal

A simple request: we need an 'Add to Calendar' widget to add our events to Google Calendar, iCal, and Outlook. Simple (once I had completed it!).

There's a module for that. There is, it's called, obviously, addtocalendar. It works very well, if you:

If you don't want to use an external service for something as simple as adding an event to a calendar, then it looks like you'll need a custom solution. Their smallest plan only allows 2 events per month.

The PatternLab Part

Here's the custom solution I came up with (in the future, I'll look at creating a module for this with a settings/UI page for site builders). Note, it's a PatternLab implementation; if you don't use PatternLab and just want to work directly in your Drupal theme, it would be even easier.

Here's the code for the 'Add to Calendar' pattern in PatternLab (some classes and things are removed to make it easier to read):

{% set classes = [ "add-to-calendar" ] %} 

{% set ical_link = 'data:text/calendar;charset=utf8,BEGIN:VCALENDAR%0AVERSION:2.0%0ABEGIN:VEVENT%0ADTSTART:' ~ atc_start_date|date("Ymd\\THi00\\Z") ~ '%0ADTEND:' ~ atc_end_date|date("Ymd\\THi00\\Z") ~ '%0ASUMMARY:' ~ atc_title ~ '%0ADESCRIPTION:' ~ atc_details|striptags ~ '%0ALOCATION:' ~ atc_location|replace({'
': ' ', '
': ' ', '

': ' ', '

': ''}) ~ '%0AEND:VEVENT%0AEND:VCALENDAR' %} {% set google_link = 'https://www.google.com/calendar/r/eventedit?text=' ~ atc_title ~ '&amp;dates=' ~ atc_start_date|date("Ymd\\THi00\\Z") ~ '/' ~ atc_end_date|date("Ymd\\THi00\\Z") ~ '&amp;details=' ~ atc_details|striptags ~ '&amp;location=' ~ atc_location|replace({'
': ' ', '
': ' ', '

': ' ', '

': ''}) %} {{>

What does the above code do?

  • Creates a Google Calendar variable and creates an iCal variable. Outlook will also use iCal.
  • Uses these variables as links to add the event to their respective calendars.

Within the variables, we have some more variables (start date, end date, etc), which we should probably wrap in conditional statements so that their clauses don't print unless they are present in Drupal (some fields might be optional on your event content type, such as end time).

These variables are:

  • atc_start_date: Start Date and time
  • atc_end_date: End Date and time
  • atc_title: the name of the event
  • atc_details: description for the event
  • atc_location: place of event

In our Event pattern in PatternLab, we then have a variable called 'add_to_calendar' so that events have the option to have this widget or not. In event.twig, we simply print:

 {% if add_to_calendar %} {% include '@site-components/add-to-calendar/add-to-calendar.twig' %} {% endif %} 

The Drupal Part

In Drupal we create a boolean field on our event content type field_event_add_to_calendar, if this is ticked, we will display the Add to Calendar widget.

Here's the code from node--event--full.html.twig

{# Set the Add to Calendar Variables #} 

{% if node.field_add_to_calendar.value %} 
  {% set add_to_calendar = true %}
{% endif %} 

{% if node.field_event_date.value %} 
  {% set atc_start_date = node.field_event_date.value %} 
{% endif %} 

{% if node.field_event_date.end_value %} 
  {% set atc_end_date = node.field_event_date.end_value %} 
{% endif %} 

{% if node.title.value %} 
  {% set atc_title = node.title.value %} 
{% endif %} 

{% if node.field_event_intro.value %} 
  {% set atc_details = node.field_event_intro.value %} 
{% endif %} 

{% if node.field_event_location.value %} 
  {% set atc_location = node.field_event_location.value %} 
{% endif %} 

... 

{% include "@content/event/event.twig" %} 

To explain:

If the 'Add to Calendar' boolean is on, we set the add to calendar variable as true. This in turn tells patternlab to render the Add to Calendar component. We then check if each field we might use has a value in it - such as a start date and end date. If so, we map the values from each of those fields to variables in our Add to Calendar component (such as atc_start, atc_title, etc)

Now, when you view a node, you will see your Add to Calendar widget on any nodes that the editors choose to put it. You can see a sample of the Add to Calendar widget in my PatternLab.

Simple, once I figured it out.

Got an improvement for this? The comments are open.

Jan 07 2019
Jan 07
What we can learn from day one of legal online cannabis sales in Canada


On October 17, 2018, Canada took a progressive step forward as the sale of recreational cannabis became legal for the entire country. It was the end of a prohibition, sparking a wave of new business opportunity. It’s hard to find official numbers for Canada as a whole, but it’s estimated that there were about 212,000 first-day sales across the country worth approximately $28 million! We thought it would be a good opportunity to show some of the benefits of open source vs. SaaS solutions for online cannabis.

First off, It’s hard to say exactly how many transactions occurred online for Canada as a whole. It’s up to each province and territory to decide how they want sales to proceed and stats are quite limited at this point. We do, however, have solid information for a couple smaller provinces that we can start with. Then we can expand with speculation after that.

What we know

Cannabis Yukon

Cannabis Yukon, the Yukon government run retail outlet, had a combined online and in-store sales totalling about $59,900 (source). About 25% of that number, roughly $15,000, was transacted online. The online retail outlet uses the open source platform Drupal.

PEI Cannabis

PEI Cannabis, the Prince Edward Island government run retail outlet, had a combined online and in-store sales totalling about $152,000 (source). About 7% of that number, roughly $21,000, was transacted online. The online retail outlet uses the SaaS platform Shopify. It’s interesting to note that Shopify also runs the provincial online pot shops for Ontario, British Columbia and Newfoundland.

Functionality is the same

All ecommerce cannabis outlets in Canada, government or private, are going to have the same features. They need to block access to minors, they need to sell products based on weight and they need to restrict the maximum amount of cannabis an individual can purchase at one time. All other functionality required is standard ecommerce. Functionality-wise, Cannabis Yukon and PEI Cannabis do the same thing. Whether it’s open source or SaaS, there isn’t an edge either way there.

Where open source has the advantage

Where it gets interesting, and where the Yukon Government is in a great position to succeed, is commerce architecture and service fees. These are a couple of big reasons why open source is really catching fire in the ecommerce marketplace.

Commerce architecture

Yukon Cannabis is built on the Drupal platform. It’s open source software meaning there are no service fees to use and anyone who uses it can customize and innovate the software however they like. Development can be done in-house or with any 3rd party development agency familiar with the underlying code, mainly PHP.

An advantage to using a platform like Drupal is that it can integrate and talk to other services your operation may use for accounting, marketing, inventory, customer management, etc. Integrations and automation eliminate swivel chair processes that restrict business growth.

PEI Cannabis, on the other hand, is somewhat vendor locked using the Shopify platform. Shopify does have a rich ecosystem of integrations, but if there’s ever a need to develop a new integration, PEI Cannabis is restricted to dealing with only Shopify or their small group of partners. That usually means high cost.

Service fees

When a sale is made using a SaaS platform, a certain percentage of the sale is lost to taxes and additional platform specific transaction fees. In the case of Shopify Plus, the enterprise fee structure is $2,000 per month + 0.25% per transaction, capping at a maximum of $42,000 per month (source). You can optionally use ‘Shopify Payments’ instead which carries a transaction fee of 1.6% + 30 cents per transaction. This would be a better way to go only if you don’t require any other payment gateways, but in our experience that isn’t the case. Finally, in addition to Shopify’s fees, the platform has an extension library to extend the functionality to your store. Most of these extensions carry their own monthly fee and there’s a very good chance you would need some of them.

With SaaS ecommerce platforms like Shopify, year after year the cost of ownership increases. At minimum, the yearly fees paid to Shopify amount to $24,000 and can rise as high as $480,000. That doesn’t include any additional extensions that you use or any payment gateway fees. PEI Cannabis must pay these fees (and so do the governments of BC, Ontario and Newfoundland who also use Shopify).

Open source ecommerce platforms, on the other hand, don’t necessarily have any of these additional fees. Aside from the standard payment gateway fees and hosting fees, Yukon Cannabis pays no additional monthly or yearly licensing fee to use their ecommerce platform. Whether they sell $15,000 or $15 million, the investment that they’ve made into the development of their website should pay for itself quite quickly, potentially within a year.

Furthermore, provincial government cannabis retailers are essentially public companies. A large portion of the profit made is to be distributed at the provincial and federal levels to support various public services and initiatives. By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

Service fee breakdown

Here’s a rough breakdown of potential monthly and annual platform service fees based on some of the numbers we know. We know the combined (online and in-store) sales from day one were elevated due to the hype of legalization, and we know that BC sales dropped by 70% on day two. For our fee breakdown, we’ll take the 70% reduced amount from the combined total numbers we know and use that to calculate a 30 day monthly sales estimate. We’ll use the combined total because most ecommerce platforms also support an official in-store point of sale component. This is all speculation of course, but it still shows realistic ecommerce sales numbers and how service fees accumulate based on them.

While the numbers shown below may appear to be quite large at first, Statistics Canada, the national statistics government agency, predicted back in September that legal cannabis sales for the first 3 months will be between $816 million and $1 billion nationwide. If that ends up being true, the numbers below would actually be grossly underestimated!

Est. Monthly Sales
Based on 30% of day one total x 30 days (XX/100 x 30) x 30 Open source
Annual and Monthly Fee: 0% Shopify Plus
Monthly including transaction fee
(calculator) Shopify Plus
Annual 
(monthly x 12)Yukon Cannabis
30 day est: $539,100
Day one: $59,900$0$2,994.31$35,931.72PEI Cannabis
30 day est: $1,368,000
Day one: $152,000$0$4523.13$54,277.56Nova Scotia
30 day est: $5,940,000
Day one: $660,000$0$12,955.69$155,468.28Alberta
30 day est: $6,870,000
Day one: $730,000$0$14,670.97$176,051.64All of Canada *
30 day est: $252,000,000
Day one: $28,000,000$0$40,000 (cap)  $480,000 (cap)

* The government agency Statistics Canada predicts that legal cannabis sales in Canada will be between $816 million and $1 billion (source).

Where SaaS has the advantage

The biggest advantage that SaaS such as Shopify has over open source is the speed at which you can get your product to market and the simplicity of use.

If you’re just starting out and need to get an ecommerce site up and running quick, these services are turn-key and can get your product to market fast. The website management interface is clean and easy to use, and most people can do what they need to do with little to no training.

There is a reason why companies like Shopify are quite dominant and it’s largely because of the simplicity. While we strongly believe that you shouldn’t choose your platform based on features, many people are willing to pay extra to be able to do it all themselves.

Takeaways

Watching a new industry unfold in Canada has been fun. It’s interesting to see that both open source and SaaS has found its way into the legal cannabis marketplace. Clearly both open source and SaaS work for this industry, it’s more about what you’re willing to pay and what ecommerce ecosystem you think is best for your business and its future growth.

If you’re thinking about online cannabis retail (or any other online retail for that matter), Acro Media has the expertise and processes in place to help guide you to online commerce success. Try our Digital Commerce Assessment Tool to uncover problematic areas within your digital commerce operations.

Complete Your Digital Commerce Assessment

Jan 06 2019
Jan 06

2018 was a big year for Webform CiviCRM module. I wanted to take a moment to highlight some of the new features that were added in 2018 (with some examples/screenshots) and take a look at what's to come in 2019!

Webform CiviCRM Integration - what is this?

Webform CiviCRM is a Drupal module that in a nutshell exposes CiviCRM APIs (with which you can create CiviCRM contacts, contributions, memberships, participant registrations, activities - just about any CiviCRM Entity programmatically) to the powerful Drupal Webform module - a very popular (over 450,000 Drupal sites are using it) and highly configurable drag and drop form builder. Webform CiviCRM itself is a popular module - over 3,000 CiviCRM projects are using it. That's more users/sites than the Mosaico Extension has! Webform CiviCRM was invented by Coleman Watts (of the CiviCRM Core Team) and is supported by the CiviCRM community:  https://www.drupal.org/project/webform_civicrm

2018 - highlights

is:pr is:closed updated:>2018-01-01 -> 88 closed! Some highlights include:
  • enhancements to recurring contributions via Webform CiviCRM (thanks to Biodynamics Association (USA) for co-funding this) - you can now configure your webform such that you can pay any amount (Event, Membership) in instalments as well as start a regular recurring open-ended Donation. An example of this would be swim club fees -> a full season is 10 months and costs $3,000 for the entire year. You can now configure your webform such that parents can sign up their child(ren) for Memberships/Events -> and select to pay all at once or in e.g. 10 instalments of $300/month.
  • Stripe support (thanks to contributions by Matthew Wire from MJW Consulting) - Matt has been doing a lot of work on the Stripe Extension and we've been supportive of changes he has PR-ed to Webform Civicrm module.  This means that Webform CiviCRM is now compatible with all major in-line Payment Processors: Stripe, iATS Payments and PayPal Pro.
  • being able to configure financial types (thanks to PEMAC (Canada) for funding this) - it is now possible to e.g. charge the correct Sales Tax [which is defined per Financial Type] based on a member's Province/location.

  • Membership Application
  • added line item support (thanks to Wilderness Committee (Canada) for funding this) - it is now possible to add up to 5 additional lineItems for one Contribution. So you can now do things like: make a donation, purchase a calendar, pay for postage - all on the same webform - and in combination with the financial type improvements - you can control the financial types for every line item, ensuring that (in our example) - the donation becomes eligible for Charitable Tax Receipting but the calendar purchase and the postage do not. 
  • numerous improvements re: cases, activities, memberships (thanks to people at Compucorp and Fuzion, and many others)
  • many other improvements - I apologize for missing anything/anyone!
  • Coleman and I ran a 2h sold-out Workshop on Webform CiviCRM at CiviCamp Calgary 2018. We covered lots of features and in-hindsight wished we had recorded it. Next time! Amongst many other items we covered how the Registration form for CiviCamp Calgary 2018 was built (allowing multiple participants to be signed up for multiple events and also including a Partner discount code field).

  • CiviCamp Calgary Registration

Also filed under 2018 highlights: Jacob Rockowitz officially released his Drupal 8 version of Drupal webform module - it includes wicked new features that make webforms more portable than ever and new fields like signature fields and my favourite: automated country flags for phone numbers (see screenshot further down).

Looking ahead at 2019

D8WFC

How can user organizations Contribute?

D8WFC Buff

Filed under

Jan 05 2019
Jan 05

The Drupal Community Working Group is pleased to announce that nominations for the 2019 Aaron Winborn Award are now open. This annual award recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It will include a scholarship and stipend to attend DrupalCon and recognition in a plenary session at the event.

Nominations are open to not only well-known Drupal contributors, but also people who have made a big impact in their local or regional community. If you know of someone who has made a big difference to any number of people in our community, we want to hear about it. The winner of the award will receive a $1200 USD DrupalCon travel stipend as well as a ticket to DrupalCon. 

This award was created in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig's Disease) came to an end on March 24, 2015. Based on a suggestion by Hans Riemenschneider, the Community Working Group, with the support of the Drupal Association, launched the Aaron Winborn Award.

Nominations are open until March 1, 2019. A committee consisting of the Community Working Group members and past award winners will select a winner from the nominations. Current members of the CWG and previous winners are exempt from winning the award.

Previous winners of the award are:

2015: Cathy Theys
2016: Gábor Hojtsy
2017: Nikki Stevens
2018: Kevin Thull

If you know someone amazing who should benefit from this award you can make your nomination here.
 

Jan 03 2019
Jan 03

Context

EK application has a module that store personal documents for user. When user account is deleted, those documents may be transferred to another account.

To achieve that, we need to alter the user account cancel form when building the form, validating and submitting it.

Let's review the 3 steps.

BUILD

The form before altering it looks like this

cancel user account before hook

We need to add a field to select another user account to which the document of the canceled account will be moved to.

To achieve that we Implements hook_form_alter() in MyModule.module:


function MyModule_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {    
  if ($form_id == 'user_multiple_cancel_confirm') {
        $form['move_uid_documents'] = [
      '#type' => 'textfield',
      '#title' => t('Move uer documents'),
      '#autocomplete_route_name' => 'MyModule.user_autocomplete',
      '#description' => t('Select to whom to transfer personal documents'),
    ];
    $form['#validate'][] = 'MyModule_form_user_delete_validate';
    $form['#submit'][] = 'MyModule_form_user_delete_submit';
    
    return $form;
      
  }
}

What we can notice here is:

  • We alter selected form defined by form ID. In this case : "user_multiple_cancel_confirm";
  • We create the required field by returning $form['move_uid_documents'] ;
  • We add 2 new actions for validation, $form['#validate'][], and submit, $form['#submit'][],  for the next steps.

After altering the form will look like this:

cancel user account after hook

We have a new field to select user. In our case, we also have an autocomplete function that helps selecting existing user. However, we need to ensure that the value entered in the field is really an existing user. This is the part handled by the validation.

 

VALIDATE

The validation is defined in MyModule_form_alter by adding validate callback named MyModule_form_user_delete_validate. Therefore, we need to create the function with thah particular name in MyModule.module.


function MyModule_form_user_delete_validate(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {   
  if ($form['#form_id'] == 'user_multiple_cancel_confirm') {
        if ($form_state->getValue('move_uid_documents') <> '') {
            
            $query = "SELECT uid FROM {users_field_data} WHERE name = :n";
            $data = db_query($query, [':n' => $form_state->getValue('move_uid_documents')])
                    ->fetchField();
            if ($data) {
                $form_state->setValue('move_uid_documents', $data);
            } else {
                $form_state->setErrorByName('move_uid_documents', t('Unknown user to move documents'));
            }
            
 
        }
    
     return $form;
      
  }

Here the function will check against user_field_data table that the id is valid.

If not an error message will be displayed:

cancel user account validation error

However, if valid, we store the value to be used in the next step which is the submission.

SUBMISSION

As for validation, the submission is defined in MyModule_form_alter by adding validate callback named MyModule_form_user_delete_submit.


function MyModule_form_user_delete_submit(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {
    
  if ($form['#form_id'] == 'user_multiple_cancel_confirm') {
    if($form_state->getValue('move_uid_documents')){
        foreach($form_state->getValue('accounts') as $key => $id) {               
        \Drupal::database()->update('MyModule_table')
           ->fields(['uid' => $form_state->getValue('move_uid_documents'), 'folder' => t('Moved from user @u', ['@u' => $id])])
           ->condition('uid', $id)->execute();
       }
    }
     \Drupal::messenger()->addStatus(t('Documents moved to user @u', ['@u' => $form_state->getValue('move_uid_documents')]));
     return $form;
      
  }
}

In the function above, we pick the id of each user account that is canceled and change to new user id in the document table.

The function also display a message to confirm actions: both cancellation and the submit hook have been executed.

cancel user submit alert

Please feel free to comment or suggest improvements.

Thank you.

Dec 28 2018
Dec 28

Themes improperly check renderable arrays when determining visibility

Kaleem ClarksonPhoto by Hello I'm Nik on Unsplash

One of the many great advantages of being a part of an open source project is that there are so many smart people out there are willing to contribute their time for the betterment of the project. This ability to crowdsource bugs and feature requests that rarely stumps the community is what makes Drupal such a powerful application.

While rare, sometimes the community finds a bug that is very difficult to solve. Let me introduce you to [#953034] Themes improperly check renderable arrays when determining visibility.

I was first introduced to this bug while trying to add a view block in the left sidebar. When the view was empty I expected the block and the sidebar to not be displayed. As you can see below, while the block was empty the sidebar was still being rendered.

The sidebar is Still being displayed.

I then googled and stumbled upon another issued, Empty view causes region to be displayed and it was exactly what I was looking for, but I noticed it was marked as a duplicate issue and linked to [#953034] Themes improperly check renderable arrays when determining visibility. This bug was reported to Drupal 7 core on October 26, 2010. The issue has over 310 comments and 230 followers.

You can really tell the severity and complexity of an issue when you see some of the brightest Drupal contributors have been making suggestions and striking out. They include but are not limited to:
bleen, chx, Cottser, Crell, DamienMcKenna, EclipseGc, Fabianx, Jeff Burnz, jenlampton, joachim, joelpittet, JohnAlbin, lauriii, markcarver, mdrummond, moshe weitzman, mpotter, samuel.mortenson, tim.plunkett, webchick, Wim Leers, xjm.

While I am not a backend developer, I felt like I could still help by highlighting a major issue that maybe someone either inside or outside the community could help find a solution.

Please remember to read the complete issue before commenting as so many people have suggested solutions to fix but have ran into a roadblock.

Dec 20 2018
Dec 20

To Zach Sines and Taylor Wright, It’s not goodbye, it’s see you later.

Kaleem Clarkson2018 DrupalCamp Atlanta Group Picture

Thanks to all of the presenters and participants who attended 2018 DrupalCamp Atlanta (DCATL). We are excited to provide you with a little holiday gift. The Session Videos are now live. View here

I would also like to thank the awesome DCATL team that I had the pleasure to work with:

  • Sarah Golden — Acquia
  • Nikki Smith — Sevaa
  • Zach Sines — Manhattan Associates
  • Taylor Wright

As with any event, this year’s DCATL had some interesting twists and turns that we were able to overcome. The biggest and most noticeable one, of course, was the construction that was happening at the hotel. Two weeks before the event, I met with the hotel event staff to discuss our setup. On my way into the hotel, everything looked as I expected and it was business as usual. When I entered the lobby I noticed they were putting up a temporary wall that blocks off the hotel bar. During our discussion, I was informed there was going to be some construction going on during our camp but was ensured that the event space wouldn’t be impacted.

The DCATL team arrived at the hotel to load in and everyone was mortified when we saw the front of the building. No more than 10 minutes after we arrived, I received a message from one of the trainers asking, “are we still having the conference?” We immediately started thinking about how we can alleviate the situation, so we took a picture of the building and sent an email out to everyone stating that the interior of the building was okay and that we were still going to have an awesome conference.

It wasn’t all doom and gloom. 10 days before the camp, we were still short on the financials and were kind of sweating it out (although we had reserve funds to cover the costs) thinking of ways that we could reduce costs without getting rid of too much programming. I received a phone call from an employee at Turner, asking if they could be a Diamond Sponsor and would also like to sponsor the after party. WOW! I couldn’t believe we were getting bailed out in the last minute, phew!

After the camp, I got a chance to have lunch with a mentor of mine and we talked about where are the next generation of Drupalers going to come from and what purpose camps serve today vs ten years ago. So based on our discussion here are my top two goals I would like to propose to the DCATL organizing team.

Increase the Number of Case Studies with co-presentations from Drupal shops and their Clients.

Another topic we discussed was how Acquia Engage has taken a different approach by showcasing their clients and providing opportunities for Drupal shops to schedule meet and greets talk with their clients. During the opening session at DCATL I asked the audience, “raise your hand if you have invited a client to attend or co-present at DrupalCamp Atlanta.” Out of all the attendees maybe 2 raised their hands.

Increase the Number of Student Attendees

When looking at some of my Drupal colleague's user profiles so many of us over 10 years. This means we are getting old folks :) But more importantly, where are the next generation of Drupalers going to come from. The state of Georgia has 114 colleges and 326,609 students. I know it takes a lot of energy but we have to figure out a way to use our camp as a pipeline for nurturing the next generation of Drupalist.

For the past 5.5 years, I have had the pleasure to work with Zach Sines and Taylor Wright as board members of the Atlanta Drupal Users Group (ADUG). Both Zach and Taylor were key stakeholders in the restructuring of the organization. Zach took on the writing of the bylaws that states how people are elected, what are the rules for participating, what are the roles and responsibilities of each officer and so on. Taylor has a ton of finance experience so he took on the responsibility of cleaning up our financials and paying all of our bills. These two have been by my side, even after heated discussions and have been what I like to call my nice translators. Sometimes I have the tendency to be too blunt and they were always there to translate my bluntness into that beautiful southern hospitality.

Zach in the Green on the Left. Taylor in the Green on the Right

Earlier this year, both Zach and Taylor informed all of us that 2018 will be their last year serving on the board. Not to get too mushy but I am going to miss them both a lot, I mean a ton. Not just for their expertise but hearing their voices on our monthly calls and some of their hilarious stories. But what is great about Drupal is that you build some lasting relationships and now I consider these two my friends. Thank you for all the work you have put into running these events, and I know this is not goodbye its soo you soon.

With our current vacancies, the Atlanta Drupal User Group (ADUG) is currently looking for new board members to join our team. While the serving on a board can sound intimidating we are really just a bunch of Drupalers who want to give back to the community. All of our meetings are held on a video call. If you are interested or know some who would be a great fit, please feel free to contact us.

Dec 11 2018
Dec 11

When it comes to ecommerce, a fast site can make a big difference in overall sales. I recently went through an exercise to tune a Drupal 7 Commerce site for high traffic on a Black Friday sales promotion. In previous years, the site would die in the beginning of the promotion, which really put a damper on the sale! I really enjoyed this exercise, finding all the issues in Commerce and Drupal that caused the site to perform sub-optimally.

FYI, We also have a Drupal 8 Commerce Performance Tuning guide here.

Scenario

Check Out Our High Five Drupal Web Series

In our baseline, for this specific site the response time was 25 seconds and we were able to handle only about 1000 orders an hour. With a very heavy percentage of 500s, timeouts and general unresponsiveness. CPU and memory utilization on web and database servers was very high.

Fast-forward to the end of all the tuning and we were able to handle 12K-15K orders an hour! The load generator couldn’t generate any more load, or the internet bandwidth on the load generators would get saturated, or something external to the Drupal environment became the limiter. At this point, we stopped trying to tune things. Horizontal capacity by adding additional webheads was linear. If we had added more webheads, they could handle the traffic. The database server wasn’t deadlocking. Its CPU and memory was very stable. CPU on the web servers would peak out at ~80% utilization, then more capacity would get added by spinning up a new server. The entire time, response time hovered around 500-600ms.

Enough about the scenario. Let’s dive into things.

Getting Started

The first step in tuning a site for a high volume of users and orders is to build a script that will create synthetic users and populate and submit the form(s) to add item(s) to the cart, register new users, input the shipping address and any other payment details. There’s a couple options to do this. JMeter is very popular. I’ve used it in the past with pretty decent success. In my most recent scenario, I used locust.io because it was recommended as a good tool. I hadn’t used it before and gave it a try. It worked well. And there are other load testing tools available too.

acro.blog-performance-tuning-4

OK, now you are generating load on the site. Now start tuning the site. I used New Relic's APM monitoring to flag transactions and PHP methods that were red flags. Transactions that take a long time or happen with great frequency are all good candidates for red flags. If you don’t have access to New Relic, another option is Blackfire. Regardless what you use for identifying slow transactions, use something.

Make sure that there’s nothing crazy going on. In my case, there was a really bad performing query that was called in the theme’s template.php and it was getting loaded on every single page call. Even when it wasn’t needed. Tuning that query gave use an instant speed-up in performance.

After that, we starting digging into things. There are several core and contrib patches I’ll mention and explain why and when you should consider applying them on your site.

In your specific commerce site, things might be different. You might have different payment gateways or external integration points. But the process of identifying pain points it the same. Run a 30-60 minute load test and find long running PHP functions. Then fix them so it doesn’t take as long.

As a first step, install the Memcache (or Redis) module and set it up for locking. Without that one step, you’ll almost immediately run into deadlocks on the DB for the semaphore table. This is a critical first step. From my experience, deadlocks are the number one issue when running a site under load. And deadlocks on the semaphore table is probably the most common scenario. Do yourself a favor. Install Memcache and avoid the problem entirely.

Then see if you can disable form caching on checkout and user registration. This helped save a TON of traffic against the database for forms that really don’t need to be cached. More about that later in specific findings.

One last thing before diving into some findings...

SHOW ENGINE INNODB STATUS

...will become your favorite friend. Use it to find deadlocks on your MySQL server.

Specific Findings

The following section describes specific problems and links to issues and patches related to the problems.
  • Do not attempt field storage write when field content did not change
    Commerce and Rules run and reprocess an order a lot. And then blindly save the results. If nothing has changed, why re-save everything again? So don’t. Apply this patch and see fewer deadlocks on order saves.
  • field_sql_storage_field_storage_load does use an unnecessary sort in the DB leading to a filesort
    Many times it makes sense to use your database to process the query. Until it doesn’t make sense. This is a case it leads to a filesort in MySQL (which you can discover using EXPLAIN in MySQL) and locking of tables and deadlocks. It is not that hard to do the sort in PHP. So do it.
  • Do not make entries in "cache_form" when viewing forms that use #ajax['callback'] (Drupal 7 port)
    This is a huge win, if you can pull it off. For transient form processing like login and checkout, disabling form cache is a huge relief to the DB. You might need to put the entire cart checkout onto a single page. No cart wizard. But the gains are pretty amazing.
  • If you are using captcha or anything with ajax on it on the login page, then you’ll need to make sure you are running the latest versions of Captcha and Recaptcha. See issues #2449209 and #2219993. Also, side note: if using the timing feature of recaptcha, the page this form falls on will not be cacheable and tends to bust page cache for important pages (like homepages that have a newsletter sign up form).
  • form_get_cache called when no_cache enabled
    You’ve done all that work to cut down on what is stored in cache. Great. But Drupal still wants to retrieve from cache. Let’s fix that. Cut down more DB calls.
  • commerce_payment_pane_checkout_form uses form_state values instead of input
    If your webshop is like most webshops, it is there to generate revenue. If you disable form caching on checkout, without this patch the values in your payment (including the ones for receiving payment) aren’t captured. Oops. Let’s fix that too.
  • Variable set stampede for js and css during asset building
    If you are using any auto scaling system and building out new servers when the site is under heavy load, you might already be using Advagg. But if you aren’t and are still using Drupal core’s asset system, spinning up a new system or two will cause some issues. Deadlocks galore when generating the CSS and JS aggregates. So either install Advagg or this patch.
  • Reduce database load by adding order_number during load
    Commerce and Rules really like to reprocess orders. An easy win is to reduce the number of one-off resaves and assign the order number after the first load.
  • Never use aggregation in maintenance mode
    While the site is under heavy load, the database sometimes becomes unreachable. Drupal treats this as maintenance mode. And tries to aggregate the JS/CSS and talk to the database. But the database isn’t reachable. It is a little ridiculous to aggregate JS/CSS on the maintenance page. And even more to try to talk to the database. So cut out that nonsense.
  • drupal_goto short circuits and doesn't set things to cache
    If you have any PHP classes you are using during the checkout, Drupal’s classloader auto loads them into memory. It then keeps track of where the files exist on the disk and this makes the next load of those classes just that much faster. Well, drupal_goto kills all this caching. And drupal_goto gets called when navigating through checkout.

Recap

acro.blog-performance-tuning-5

Wow! That was a long list of performance enhancements. Here’s a quick recap though. Identify critical flow of your application. Generate load on that flow. Use a profiler to find pain points in that process. Then start picking things off, looking on drupal.org for existing issues, filing bugs, applying patches. Many of the identified issues discussed here will apply to your site. Others won’t apply and you’ll have different issues.

Surprisingly, or maybe not surprisingly, the biggest wins in our discovery process were the low hanging fruit, not the complex changes. That query in the template.php was killing the site. After that, switching to use Memcache for the semaphore table and eliminating form cache for orders also cut down on a lot of chatter with the database.

I hope you too can tune that Drupal 7 Commerce site to be able to handle thousands of orders an hour. The potential exists in the platform, it is just a matter of giving performance bottlenecks a little attention and fine tuning for your particular use case. Of course, if you need a little help we'd be happy to assist. A little bit of time spent can have you reaping the rewards from then on.

Contact Acro Media Today!

Dec 11 2018
Dec 11

Here are some performance tuning tips and instructions for setting up a very performant Drupal 8 Commerce site using Varnish, Redis, Nginx and MySQL. I’ve got this setup running nicely for at least 13,000 concurrent users and it should scale well past that.

FYI, We also have a Drupal 7 Commerce Performance Tuning guide here.

Varnish

Config

You’ll need some specific config for Drupal as well as some extra config to work nicely with BigPipe caching. These are standard for Varnish and Drupal and not specific to Commerce.

Drupal

acro.blog-performance-tuning-1You’ll want to setup the Purge and Varnish Purge modules to handle tag based cache invalidation, nothing here is unique to Commerce, so you can follow the standard instructions. You will, however, want to make sure your pages actually are cached, as often modules or small misconfigurations can make a page not cacheable. To work nicely with Varnish, you want the entire page to be cacheable so your webserver doesn’t even get hit. An underused module that I find very helpful is Renderviz, which will show you a 3D breakdown of what cache tags are attached to what parts and can help you identify problem parts. I run

renderviz(‘max-age’, ‘0’) to show me anything that can’t be cached. Usually the parts you find can be corrected and made cacheable.

For example: In a recent set of performance testing I was doing, I found a newsletter signup that appeared on the bottom of every page had an overly aggressive honeypot setting, which rendered the page uncacheable. Changing the settings to only apply to necessary forms, as well as correcting a language selector, turned tons of uncached pages into cacheable pages. Now these pages return <10ms and put zero load on my web servers or database.

Demo Drupal Commerce today! View our demo site.

Web Servers

PHP

Use the most modern version of PHP you can, preferably the latest stable. Never ever ever use PHP 5 which is terrible, terrible, terrible. Otherwise, make sure you have sufficient memory and allowed threads, and that will cover most of your PHP tuning. This is almost certainly the most resource heavy part of your Drupal stack, but it is also easy to scan horizontally, pretty much indefinitely. Also, the more you can make use of Varnish, the less this will get used.

Nginx/Apache

Most of this is just making sure you can handle the number of connections. You may need to up the file limit...

ulimit -n

...of your web user to allow for more than 1024 connections per nginx instance.

Database

acro.blog-performance-tuning-2

A Commerce site is usually more write-heavy than your standard site, as your users create lots of "content" (aka carts and orders). This will usually change your MySQL config a bit, although the majority of your queries will still be reads. A pretty simple way to tune your site is to run...

mysqltuner

...against it after getting some real traffic data for at least a couple days, or simulating high traffic. It’s recommendations will get you a pretty good setup.

There is one other VERY important thing you need to do, you need to change your transaction isolation level from READ-REPEATABLE to READ-COMMITTED. READ-REPEATABLE is much too aggressive at table locking to work with most Drupal sites, especially anything write heavy. You will suffer from constant deadlocks even at fairly low traffic levels without this. Frankly, I think this should be a flag in the status page, but my patch hasn’t gotten any traction.

Cache Server

Nothing special here, but you are going to want use a separate caching option. It could be Memcache, Redis or even just a separate MySQL database. Redis is nice and fast, but the biggest gain is just splitting your cache away from the rest of your db so you can scale them easier.

Patches

There are a few specific patches that will be a great help to your performance.

_list cache tag invalidation

See: https://www.drupal.org/project/drupal/issues/2966607

Every entity type has an entity_type_list cache tag, which gets invalidated any time an entity of that type is added or changed and that those lists will need to get rebuild. This happens a LOT, but is a relatively simple query.

update cachetags set invalidation=invalidation+1 where tag=’my_entity_list’

This is an update, which is a blocking query, nothing else can edit this row while this query is running, which wouldn’t be so bad except...

acro.blog-performance-tuning-3This query often gets run as a part of larger tasks, in our case, such as when placing an order. A big task like this is run in a transaction, which basically means we save up all the queries and run them at once so they can be rolled back if something goes wrong. This means though, that this row stays locked for the whole duration of the transaction, not just the short time it takes this little query to run. If this invalidation happens near the start of the transaction, it can take a query that would take 0.002 seconds and make it take 0.500 seconds, for example. Now, if we have more than 2 of these happening a second, we start to back up and build a queue of these queries, which just keeps getting longer and longer until we just start returning timeouts. Since this query is part of the bigger order transaction, it stops the whole order from being processed and can bring your checkout flow to a halt. 

Thankfully, the above listed patch allows these cache invalidations to be deferred so as to not block large transactions. I think the update query for invalidating cache tags is still a bottleneck as you could eventually reach it without these long transactions, but at this point that problem is more hypothetical than something you will practically encounter.

Add index to profiles

See: https://www.drupal.org/project/profile/issues/3017788

As you start getting more and more customers and orders, you will get more profiles. Loading them, especially for anonymous users, will really start to slow down and become a bottleneck. The listed patch simply adds an index to prevent that. Please note, this is a patch for the Profile module, not Commerce itself.

Make language switcher block cacheable

See: https://www.drupal.org/project/drupal/issues/2232375

This issue is unfortunately on hold pending some large core changes, but once it does land, this will allow the language switcher block to be used without worry of it blocking full page caching.

Conclusion

You should be able to scale well above 10,000 concurrent users with these tips. If you encounter any other bottlenecks or bugs, I’d love to hear about them. If you want help with some performance improvements from Acro Media and yours truly, feel free to contact us.

Contact Acro Media Today!

Dec 11 2018
Dec 11

This article demonstrates six different methods of changing content and functionality in Drupal. Each method requires a different skill set and level of expertise, from non-technical inexperienced users to advanced Drupal developers. For each method, we describe the components, skills, knowledge, and limitations involved. The goal is to highlight Drupal’s flexibility as a Content Management […]

The post The Flexibility of Drupal 8 appeared first on php[architect].

Dec 10 2018
Dec 10

Zivtech is happy to be offering a series of public Drupal 8 trainings at our office in downtown Philadelphia in January 2019. 

Whether you consider yourself a beginner or expert Drupal developer, our training workshops have everything you need to take your Drupal skills to the next level. 

Our experience

The Zivtech team has many years of combined expertise in training and community involvement. We have traveled all over the world conducting training sessions for a diverse range of clients including, the United States Department of Justice, the Government of Canada, CERN, Howard Hughes Medical Institute, Harvard University and more. 

We pride ourselves in educating others about open source, and attendees will leave our trainings with the knowledge to build custom Drupal sites, solve technical issues, make design changes, and perform security updates all on their own. We also offer private, onsite trainings that are tailored to your organization's specific needs. 

Our public Drupal trainings for January 2019 include:

Interested in learning more about our upcoming trainings? Click here. You can also reach out to us regarding multi-training and nonprofit discounts, or personalized trainings. 

We hope to see you in January!
 

Dec 08 2018
Dec 08

Sometimes we need to build a rather complex search form with many options. We want to have total control under output, so we will override the default template by own because standard Drupal templates do not allow to the use the complex formatting. However, we can easily override the template with our custom theme or module.
All we need to know the ID of the form and the appropriate name of the template. For this, you can check using the following code: dump($form['#id']); and dump($form['#theme']); inside hook_form_alter() or hook_form_FORM_ID_alter().

In my example, we have: views-exposed-form-class-schedule-block-1 and views_exposed_form__class_schedule__block_1 , you should replace both with your values.

Dec 05 2018
Dec 05

The Values & Principles Committee has formed and has started its work. It has started by looking at Principle 8.

Principle 8: Every person is welcome; every behavior is not

The Drupal community is a diverse group of people from a wide variety of backgrounds. Supporting diversity, equity, and inclusion is important not just because it is the right thing to do but because it is essential to the health and success of the project. The people who work on the Drupal project should reflect the diversity of people who use and work with the software.  In order to do this, our community needs to build and support local communities and Drupal events in all corners of the world. Prioritizing accessibility and internationalization is an important part of this commitment.

The expectation of the entire Drupal community is to be present and to promote dignity and respect for all community members. People in our community should take responsibility for their words and actions and the impact they have on others.

Our community is, by default, accepting with one exception: we will not accept intolerance. Every person is welcome, but every behavior is not. Our community promotes behaviors and decisions that support diversity, equity, and inclusion and reduce hatred, oppression, and violence. We believe that safety is an important component of dignity and respect, and we encourage behaviors that keep our community members safe. Our Code of Conduct is designed to help communicate these expectations and to help people understand where they can turn for support when needed.

Why are we doing this?

As Dries said, when announcing the first iteration of the Drupal Values & Principles, the Drupal project has had a set of Values & Principles for a very long time. Historically, they were mostly communicated by word of mouth and this meant that some in our community were more aware of them than others.

Writing down the Values & Principles was a great first step. What we need to do now is continually refine the common understanding of these Values & Principles across our whole community and ensure that they are built-in to everything we do.

How will we work?

The Values & Principles are held very closely to the heart of the members of our community and we absolutely recognise that any work on them must be inclusive, clear, structured and accountable.

We are, therefore, going to be open about the work we are doing. While there are members of a committee that will focus on this task, it is not the committee’s job to make decisions “behind closed doors”. Instead, the committee is responsible for enabling the whole community to refine and communicate our common Values & Principles.

We will record actions and progress in the Drupal Governance Project so that all in our community will be able to have the necessary input.

How will we communicate?

We will continue to post updates on the Drupal Community Blog and, as already mentioned, you will always be able to see and, most importantly, participate in issues in the Governance Project. We even have a board on ContribKanban!

Who is on the committee?

Hussain Abbas (hussainweb) works as an Engineering Manager at Axelerant. He started writing programs in 1997 for school competitions and never stopped. His work focus is helping people architect solutions using Drupal and enforcing best practices. He also participates in the local developer community meetup for PHP in general and Drupal in particular. He often speaks at these events and camps in other cities.

Alex Burrows (aburrows), from UK, is the Technical Director of Digidrop and has over 10 years working in Drupal, as well as an avid contributor and a member of the Drupal Community Working Group. As well as this he is a DrupalCamp London Director and Organizer and the author of Drupal 8 Blueprints book.

Jordana Fung (jordana) is a freelance, full-stack Drupal developer from Suriname, a culturally diverse country where the main language is Dutch. She has been steadily increasing her participation in the Drupal community over the past few years and currently has a role on the Drupal Community Working Group. She loves to spend her time learning new things, meeting new people and sharing knowledge and ideas.

Suchi Garg (gargsuchi), living in Melbourne Australia is a Tech Lead at Salsa Digital. She has been a part of the Drupal community for more than 12 years as a site builder, developer, contributor, mentor, speaker and trainer. She had been a part of the Indian community before moving to Australia and is now an active Drupal community down under.

John Kennedy (johnkennedy), lives in Boston, works as a Product Manager for AWS. Over 10 years in Drupal as a site-builder, developer, speaker and on the business side. Co-organiser of Drupal Camp London 2012-2015. PM for Acquia Lightning and the Drupal 8 Module Acceleration Program.

Rachel Lawson (rachel_norfolk), UK and the Community Liaison at the Drupal Association will finally be providing logistical support to the committee and helping wherever she can. Having been in the Drupal community for 11 years as a site builder, a contributor and a mentor, she has had opportunity to experience how the community understands its collective Values & Principles.

In order to be as transparent and forthcoming as possible we wanted to address the fact that there are currently 2 CWG members on the committee. The initial call for people to join the Values & Principles committee happened at the same time as the Community Working Group was calling for new members and, as luck would have it, Alex Burrows applied for both.

In October 2018 a current member of the CWG, Jordana Fung joined the Values & Principles committee and at same time he was being vetted for potential membership to the CWG, Alex joined the Values & Principles committee as well. After the vetting process, Alex officially became a member of the CWG in November. So as it stands now, there are 2 CWG members on the V&P committee.

There are a few possible options going forward, some are:

  • Both CWG members continue for now (whilst the V&P committee is in the very early formation stages) and then possibly:
    • One member drops off
    • They act as a team and only one member (whichever is available) participates in meetings
  • The CWG decides which member is on the VP committee
    • We may need to add another member to the VP committee to take the place of the member that will no longer attend.

So, what’s next?

We have started by compiling a summary of feedback from the community so far that relates to the project’s Values & Principles from such places as the Whitney Hess Interviews, community-led conversations around governance and some anonymized feedback from the Governance Taskforce. We will be adding this summary to an issue in the project.

Call to action

We recognize, though, that what we really want to understand is how you understand what we already have written in Principle 8. THis is how we intend to do that…

The members of the committee have each written stories from their own memories of the Drupal community that demonstrate Principle 8 in action.

We invite you all to write your own stories, from your memories of the Drupal community, other tech communities or indeed any other aspect of life, that demonstrate Principle 8 to you. You should add your story to this issue we have created:

Add my story about Principle 8

One thing we do ask, though, is that you only add your own stories (as many as you like!) and NOT comment or question others’ stories. All stories are valid.

By the end of the year, we hope to have a rich set of stories that show how we, as a global community, interpret Principle 8 and we can then look to see if any changes need to be made to the words or, maybe, it is more a case of linking the Principle to the stories or providing other statements supporting Principle 8.

Nov 27 2018
Nov 27

If you’re evaluating CMS platforms for an upcoming project, Drupal should be one platform that you consider. It was built for generating content and also has robust ecommerce abilities through the Drupal Commerce module. If you only need to publish content, it’s great for that. If you only need ecommerce, it’s great for that, too. The fact that it does both very well is a winning combination that will always be available to you, now or down the road. This post takes a look under the hood of Drupal to show you why you might want to take a first, or second, look at the Drupal CMS.

Drupal for Content

As mentioned in the introduction, Drupal was built for content creation and it is very good at that. But, if you’re unfamiliar with Drupal, you probably wouldn’t understand WHY it works so well for this. Here are some of the things that really separate Drupal from other platforms.

Content Types

At the core of Drupal content creation is something called a Content Type. A content type is a collection of fields that are used to generate a certain type of content, such as a general page, landing page, blog post, press release, etc. It’s one of the first pieces of a new Drupal site to be configured.

Demo Drupal Commerce today! View our demo site.Configuring content types is mostly done through Drupal’s admin user interface (UI). Through the interface, you add fields. If you think of any website form that you’ve seen in the past, the form is made up of fields for you to enter in your information. This is the same for Drupal, but you’re actually creating the fields that are used to generate content. For example, a blog post typically contains a title (text field), body (textarea field), header image (image field), publish date (date field), author and category (reference fields). For the blog content type, all of these fields would be added as well as any other that you need. The field options available a many. If you don’t see a field that you need, chances are someone has already created it and you just need to install a module that adds it in.

After all of the fields have been added, you then configure how the fields are displayed to your content creators and to the end user viewing the content. I won’t get into details here, but many fields have options for how that content gets rendered on the page. Using an image field as an example, you can choose to render the image as the original image, or as a processed image (like a thumbnail), or as the url path to the image on the server. Each option has its uses once you start theming the site.

Regions and Blocks

Keeping with the blog post example, when viewing a blog post you typically see other elements on the pages such as a subscribe form, list of recent posts, and call to actions. It doesn’t make sense to manually add these things to every single blog post, so instead we place this content in something called a Block and assign the block to a Region.

Regions are added to your page templates and are there for you to place blocks into. When adding a block into a region, each block can be configured independently of one another so that you can assign blocks to specific pages, content types, access levels (i.e. anonymous vs. logged in users), etc. A block can be many different things, but one type of block is similar to a content type in that you can add fields that are used to make up the block.

Views

A View is a powerful tool within Drupal for creating dynamic content based on other content. Views allow you to take existing content, manipulate it, and display it in another way. They can be used to create both pages and blocks.

Again, using the blog as an example, if you look at a page that is listing all of your blog posts at one time, this is most likely a view. The view is taking content generated using the blog content type, manipulating each post so that you’re only seeing specific information such as a date, title and introduction, and then adding a ‘Read More’ link after the introduction. Not only is the view manipulating each post like this, it’s also displaying the 10 most recent posts and showing you a ‘Load More’ button afterwards to load the next 10 posts.

This is a pretty simple example, but as you can see it’s quite powerful. You can use as much or as little of the content information as you need and it gives you fine-grained control to use and re-use your content in new ways. 

Metatags

Any serious content platform needs to include a robust set of metatag options. The built in metatag module for Drupal is excellent in this regard. You can set default options for every content type and override those defaults for individual pieces of content if needed. You can choose if your content should be crawled by search bots or not, how your post would appear on social media if shared, and more.

Workflows

This might not apply to you if you’re the only one creating content for your website, but, if you have a team of content creators, workflows let you assign specific permissions to your teammates. For example, you can allow your writers to draft content, your editors to approve the content, and finally a publisher can publish the content. Instead of explaining it all here, here’s a separate article and video that shows you how it works.

Modules

Anything that adds new functionality to the base Drupal platform is called a module. A module can be small (such as adding a new field type) or big (such as adding ecommerce functionality). You can separately Google “best modules for Drupal” and see a whole bunch of popular modules, but one of our favorites that I want to mention for content creation is the “Paragraphs” module. This module lets you create reusable sections of content that can be used within your content types and product pages. So, instead of just a body of text you can add cta straps, rich media, image galleries, forms, etc., all within your content. We use it on our own site to quickly make unique page layouts for our content.

Theming

Drupal’s theming engine enables your designers and front end developers to implement anything they can dream up. You have broad control over the look and feel of your site so that everything is consistent, but you can also create totally unique pieces of content or individual pages that may break away from your normal styleguide.

Say you have a new product lineup that you’re launching. You’re store branding is one thing, but this product has its own unique branding and personality that you want to convey. Well, you can give your designers full control over how the product should appear on your website and your front end developers can make it happen using the granular template override system.

Drupal for Commerce

The Commerce module for Drupal turns your Drupal site into a fully fledged ecommerce platform that is 100% capable of running any size of ecommerce site you throw at it. And remember, this is adding functionality to Drupal, so you still maintain the ability to do all of the content side of things mentioned above. 

In fact, not only can you still generate other content, but all of the things that make content creation great on Drupal also apply to the ecommerce side of your site. Your product pages are totally fieldable and themable, just like the content. You can assign blocks to your project pages. You can use views to set up your catalog and create blogs that filter out featured products or related products. Everything is fully customizable. 

There are also many modules available specifically for Commerce that give you even more functionality and integrations, and this is actually where ecommerce on Drupal becomes a “big deal”. Drupal Commerce is API first, which means that it was made to be able to connect to other services. So while you might run your ecommerce store on Drupal Commerce, you will most likely also use other software for your business accounting, marketing and customer relations, to name a few. Drupal Commerce can integrate with these services and share information in order to automate tasks.

We have a whole article that drills down on this topic and explains why ecommerce platforms like Drupal Commerce can be a great fit for your business. I would recommend reading it here.

Content and Commerce

We’ve really only scratched the surface on what Drupal can do from both a content and commerce perspective. I hope you’re beginning to see the whole picture. 

The truth is that most ecommerce platforms don’t do both content and commerce well. You can definitely find many great content creation platforms out there, but can they also do ecommerce? Likewise, there are a ton of ecommerce platforms that will sell your products, but how well can you create other content and do you have the flexibility to customize one or all product pages in the way that works best for your products. And, can you integrate that platform with other services?

These are all important questions to ask even if you don’t think you need a robust content platform or an ecommerce component now. If you think you might need it in the future, planning ahead could save you a headache later. While there are a lot of options out there and I encourage you to explore them, Drupal should be high on your list of possible options.

Try A Demo

It’s one thing to say Drupal is great at all of these things, but why not give it a try. We’ve actually created a complete Drupal demo that showcases both content and commerce together. Click the link below to check it out and see what you think. If you’re interested in exploring how Drupal can fit with your business, feel free to Contact Us. We’d be happy to have that discussion with you.

Demo Drupal Commerce today! View our demo site.

Nov 27 2018
Nov 27

Our team loves exploring and using hot trends in development, one of which is decoupled Drupal architecture. Our previous post was devoted to using decoupled Drupal with JSON.API, and our today’s story hero will be “the Great Gatsby”. Does it sound like the famous book hero? No, Gatsby.JS is a new and hot JavaScript tool, but it promises to be equally famous and deserve a hundred books! In this post, we will discuss its principle of work and the benefits of using decoupled Drupal 8 and Gatsby.JS. And, of course, you always can rely on our Drupal experts in implementing it all.

Gatsby.JS: what it is and how it works

Gatsby.JS is defined a static site generator, but it is approaching a front-end framework in its capacities. Gatsby is built on very hot front-end tools, some of which are:

  • React.JS — the amazingly popular JavaScript library for building complex interfaces
  • GraphQL — the super efficient query language
  • Webpack — the great JavaScript module bundler 

Gatsby.JS is meant for building blazing fast static sites. It fetches the data to them from absolutely any sources and generates static content using GraphQL. Right now, there are 500+ source plugins to establish the connection between particular data sources and Gatsby. The sources include YouTube, Twitter, Hubspot, Shopify, Trello, Vimeo, Google Sheets, content management systems like Drupal, WordPress, and so on. 

Gatsby uses source plugins and GraphQL

 

Decoupled Drupal 8 and Gatsby.JS: the great duet and its benefits

One of the hottest and most beneficial combinations for today is Gatsby and Drupal 8. According to the the decoupled, or headless Drupal architecture, Drupal serves as the backend only, while Gatsby.JS handles the presentation layer. 

Drupal 8 and Gatsby.JS are both open-source, have a large and active community and a huge ecosystem of add-on modules or plugins. And Drupal 8 has built-in web services to make integration a breeze. 

What makes this combination so beneficial? The simplicity and speed of a static site combines perfectly with the power and flexibility of the backend provided by the Drupal 8 CMS. Here are at least some of the features that we get in the end:

  • Unmatched speed. Gatsby.JS pre-fetches all pages of the website instead of querying the database every time on demand, which makes navigation enjoyable and amazingly fast. Gatsby is a static PWA (progressive web app) generator. It efficiently fetches only the critical HTML, CSS, and JS files. 
  • Easy setup. No cumbersome deploy and setup processes will be needed with Gatsby. It builds your site as static files that can be quickly deployed anywhere.
  • Great personalization features. Drupal-and-Gatsby combinations can feature awesome user personalization and authentication capabilities.
  • Awesome content editing. Usually, static site generators need writing content in Markdown, which could be cumbersome for content editors. But the problem is solved with Drupal 8 as a backend! Drupal 8 content creation features are a joy for any content editor. 

One of examples of using decoupled Drupal 8 and Gatsby.JS is the demo site Umami Food Magazine. The site is built on headless Drupal distribution Contenta CMS with Gatsby.JS. 

Umami Food Magazine uses Gatsby 2Umami Food Magazine uses Gatsby

If this looks appetizing enough, contact our Drupal team right now to combine decoupled Drupal 8 with Gatsby.JS for you! Or continue reading about some implementation details. 

Some specifics of using Drupal 8 and Gatsby.JS

In the decoupled setup, both Drupal 8 and Gatsby sites need to be prepared to work together. They will be connected by means of the special Gatsby’s source plugin for Drupal that fetches data, including images, from Drupal 8 websites with JSON API installed. 

So it is necessary to install and enable the JSON API and JSON API extras contributed Drupal modules, as well as enable the core Serialization module on our Drupal website.

Enable JSON API module

Our next destination is Configuration — Web Services — JSON API Overwrites.

Configure JSON API

In Settings, we need to make sure the path prefix for JSON API is /jsonapi. This is what the Gatsby site will need to know.

Configure JSON API

In People — Roles — Permissions we give access to the JSON API list of resources to users with all roles, including anonymous.

Permissions for JSON API

Our Drupal site is ready for Gatsby integration, and we now need to prepare our Gatsby site. It begins with installing Gatsby’s CLI:

npm install --global gatsby-cli

Then we follow all the site creation steps in the “Get started” documentation. Gatsby also offers pre-configured starters for site creation.

Gatsby starters

Then we run Gatsby with the command, after which the Gatsby site should become available at localhost:8000:

gatsby develop

The above mentioned source plugin for Drupal then needs to be installed on the Gatsby site. Next, we add the piece of code from the plugin’s documentation to the gatsby-config.js file. The URL should changed to the one of our Drupal site.

plugins: [
 {
 resolve: `gatsby-source-drupal`,
 options: {
 baseUrl: `https://our-site-name.com/`,
 apiBase: `api`, // optional, defaults to `jsonapi`
 },
 },
]

We then configure our Gatsby site to fetch exactly the content we need from Drupal. We need to create the appropriate pages in /src/pages on the Gatsby site and add the code for React import to the JS file. 

And we configure GraphQL at localhost:8000/___graphql to query the Drupal site exactly how we want. 

It all crowns up with the last command to publish our Gatsby site with the Drupal data:

gatsby build

This is just a very brief description of getting Drupal 8 work with Gatsby. Our experts are ready to do the setup exactly in accordance with your wishes.

Enjoy the combination of decoupled Drupal 8 and Gatsby.JS!

If you are interested in using decoupled Drupal 8 and Gatsby.JS, either on an existing project or on a new one, contact our Drupal developers. Our Drupal 8 team has great experience in third-party integration. We will advise you the best decoupled setup and, of course, smoothly implement it. Let’s enjoy the latest and greatest technologies!

Nov 23 2018
Nov 23
Flags of all the Countries that were represented
Nov 22 2018
Nov 22

On my search for an easy to integrate library bringing animating snowflakes to a website - ideally without the need of JS - I've found myself on the wonderful CSSnowflakes library - a lightweight pure CSS solution, only needing you to insert a few lines HTML and the CSS file to your site. Here's a demo page.

To make it even easier to use, without the need of touching Twig templates and theme CSS files, I've wrapped this up in a small Drupal module today: https://www.drupal.org/project/snowflakes

This module is plug & play and ships with two configuration settings currently: one to generally en/disable the snowflakes, and another one to hide it on admin pages.

Nov 21 2018
Nov 21

The Drupal Community Working Group is happy to announce the addition of Alex Burrows (aburrows). Based in Surrey, United Kingdom, Alex has been contributing to the Drupal project and community for more than a decade. He is one of the lead organizers of Drupalcamp London, and a frequent speaker at other Drupal events. Alex also serves as a volunteer police constable in his local community.

The CWG would also like to announce that both Josef Dabernig (dasjo) and Manjit Singh (Manjit.Singh) have agreed to serve as Subject Matter Experts (SMEs) to the CWG. SMEs are not full members of the group, but can be called upon on an as-needed basis for issues that might require specific knowledge or expertise. SMEs are subject to the same Code of Ethics as full members of the CWG.

Adam Hill and Emma Karayannis are also officially stepping down as members of the CWG. We would like to thank both Adam and Emma for their invaluable contributions to the group and for their ongoing contributions to the Drupal community.

The CWG continues to seek new members and SMEs as it seeks to increase the diversity of its membership. It is our hope that by expanding our membership, the CWG will be able to better serve the community in a more proactive manner. If you think you or someone you know might be a good fit for the CWG and are interested in learning more, please reach out to us via email at [email protected].

In other news, the CWG recently proposed a set of changes to its charter to address feedback and concerns raised by the community over the last year and a half. We are accepting feedback from the community through November 23 before finalizing the proposal.

The CWG is responsible for promoting and upholding the Drupal Code of Conduct and maintaining a friendly and welcoming community for the Drupal project. To learn more about the group and what we’ve been up to over the last year, check out our recently-published annual report.

Nov 20 2018
Nov 20

A while ago we introduced a Live Component Guide to our corporate website that gives our designers and content creators and quick way to lay out content on new and existing pages. It’s worked out great so far and has generated quite a bit of interest. A couple months old now, that initial blog post explaining why we did it and how it works has had over 400 views and the recorded demonstration on YouTube has been watched for more than 1500 minutes. Not bad considering it’s a very Drupal specific, niche post.

While I was working on our corporate site components, others at Acro Media were working away on adding similar components to our internal Drupal 8 framework. Our corporate website is currently running on Drupal 7, and so, in some of the feedback that we received, people naturally wanted to see an example of the Live Component Guide in Drupal 8. After all, that’s the latest version of the Drupal platform that all new Drupal sites are being built using it.

I’m happy to announce now that those components have made their way into Acro Media’s Drupal Commerce demo site, Urban Hipster! Want to see it? I know you do. Check out the video demonstration below or go straight to the Urban Hipster’s Live Component Guide and take look for yourself.

[embedded content]

Demo Drupal Commerce today! View our demo site.

Nov 15 2018
Nov 15

A couple of days ago, the PHP Framework Interoperability Group (PHP-FIG) approved the PSR-18 "HTTP Client" standard. This standard was the last missing piece to build applications that need to send HTTP requests to a server in an HTTP client agnostic way.

First, PSR-7 "HTTP message interfaces" defined how HTTP requests and responses are represented. For server applications that need to handle incoming requests and send a response, this was generally enough. The application bootstrap creates the request instance with a PSR-7 implementation and passes it into the application, which in turn can return any instance of a PSR-7 response. Middleware and other libraries can be reused as long as they rely on the PSR-7 interfaces.

However, sometimes an application needs to send a request to another server. Be that a backend that uses HTTP to communicate like ElasticSearch, or some third party service like Twitter, Instagram or weather. Public third party services often provide common client libraries. Since PSR-17 "HTTP Factories", this code does not need to bind itself to a specific implementation of PSR-7 but can use the factory to create requests.

Even with the request factory, libraries still had to depend on a concrete HTTP client implementation like Guzzle to actually send the request. (They can also do things themselves very low-level with curl calls, but this basically means implementing an own HTTP client.) Using a specific implementation of an HTTP client is not ideal. It becomes a problem when your application uses a client as well, or you start combining more than one client and they use different clients - or even more when needing different major versions of the same client. For example, Guzzle had to change its namespace from Guzzle to GuzzleHttp when switching from version 3 to 4 to allow both versions to be installed in parallel.

Libraries should not care about the implementation of the HTTP client, as long as they are able to send requests and receive responses. A group of people around Márk Sági-Kazár started defining an interface for the HTTP client, branded HTTPlug. Various libraries like Mailgun, Geocoder or Payum adopted their HTTP request handling to HTTPlug. Tobias Nyholm, Mark and myself proposed the HTTPlug interface to the PHP-FIG and it has been adopted as PSR-18 "HTTP Client" in October 2018. The interfaces are compatible from a consumer perspective. HTTPlug 2 implements PSR-18, while staying compatible to HTTPlug 1 for consumers. Consumers can upgrade from HTTPlug 1 to 2 seamlessly and then start transforming their code to the PSR interfaces. Eventually, HTTPlug should become obsolete and be replaced by the PSR-18 interfaces and HTTP clients directly implementing those interfaces.

PSR-18 defines a very small interface for sending an HTTP request and receiving the response. It also defines how the HTTP client implementation has to behave in regard to error handling and exceptions, redirections and similar things, so that consumers can rely on a reproducable behaviour. Bootstrapping the client with the necessary set up parameters is done in the application, and then inject the client to the consumer:

use Psr\Http\Client\ClientInterface;
use Psr\Http\Client\ClientExceptionInterface;
use Psr\Http\Message\RequestFactoryInterface;

class WebConsumer
{
    /**
     * @var ClientInterface
     */
    private $httpClient;

    /**
     * @var RequestFactoryInterface
     */
    private $httpRequestFactory;

    public function __construct(
        ClientInterface $httpClient,
        RequestFactoryInterface $httpRequestFactory
    ) {
        $this->httpClient = $httpClient;
        $this->httpRequestFactory = $httpRequestFactory;
    }

    public function fetchInfo()
    {
        $request = $this->httpRequestFactory->createRequest('GET', 'https://www.liip.ch/');
        try {
            $response = $this->httpClient->sendRequest($request);
        } catch (ClientExceptionInterface $e) {
            throw new DomainException($e);
        }

        $response->...
    }
}

The dependencies of this class in the "use" statements are only the PSR interfaces, no need for specific implementations anymore.
Already, there is a release of php-http/guzzle-adapter that makes Guzzle available as PSR-18 client.

Outlook

PSR-18 does not cover asynchronous requests. Sending requests asynchronous allows to send several HTTP requests in parallel or to continue with other work, then wait for the result. This can be more efficient and helps to reduce response times. Asynchronous requests return a "promise" that can be checked if the response has been received or waited on, to block until the response has arrived. The main reason PSR-18 does not cover asynchronous requests is that there is no PSR for promises. It would be wrong for a HTTP PSR to define the much broader concept of promises.

If you want to send asynchronous requests, you can use the HTTPlug Promise component together with the HTTPlug HttpAsyncClient. The guzzle adapter mentioned above also provides this interface. When a PSR for promises has been ratified, we hope to do an additional PSR for asynchronous HTTP requests.

Nov 14 2018
Nov 14
Make your dev life easy by using "apachectl" command to restart, stop, or start the apache server on mac from the terminal.
Nov 09 2018
Nov 09

Last week, the Children’s Hospital of Philadelphia (CHOP) Vaccine Makers Project (VMP) won a PR News Digital Award in the category “Redesign/Relaunch of Site.” The awards gala honors the year’s best and brightest campaigns across a variety of media. 

PR News Award on a table.

Our CEO, Alex, and our Director of Client Engagement, Aaron, along with members of the Vaccine Makers team attended the event at the Yale Club in New York City.

Screenshot of a Tweet posted by the PR News. Source

The Vaccine Makers Project (VMP) is a subset of CHOP’s Vaccine Education Center (VEC). It’s a public education portal for students and teachers that features resources such as lesson plans, downloadable worksheets, and videos. 

The Vaccine Makers team first approached us in need of a site that aligned with the branding of CHOP’s existing site. They also wanted a better strategy for site organization and resource classification. Our team collaborated with theirs to build a new site that’s easy to navigate for all users. You can learn more about the project here.

Screenshot of a Tweet from Vaccine Makers team. Source

We’d like to thank CHOP and the Vaccine Makers team for giving us the opportunity to work on this project. We’d also like to thank PR News for recognizing our work and hosting such a wonderful event. 

Finally, we’d like to congratulate our incredible team for their endless effort and dedication to this project. 
 

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web