Drupal Planet

Subscribe to Drupal Planet feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 5 hours 50 sec ago

Kanopi Studios: Top 5 Things to Look For in a Website Support Agency

February 22, 2019 - 23:06

Whether you’ve just recently built a new site, or you are in charge of maintaining an existing one, it’s critical to leverage the most you can out that site on an ongoing basis. As the internet grows and audience needs change, your site needs to be maintained and adapted over time. Sites can also be expensive to upgrade if not properly cared for (think of not performing regular maintenance on your car for several years until finally it breaks in an expensive way).

And yet, most organizations don’t have the money to redo a site more than once every three or four years. Sometimes they often don’t have the money to hire someone inhouse to maintain the site beyond content updates. Who takes care of your security updates, or changes to modules and plugins so that your site doesn’t break?

That’s where quality website support and maintenance comes in. A good support agency can make your site last a long time past its creation date and keep it fresh until it’s time for the next rebuild and redesign.

Here’s are the top five things to look for when hiring for outside website support:

  1. Make sure they have a dedicated support team or department. Don’t go with an agency that simply pulls people off of regular design or development build projects to do support tickets on the side. Your site won’t get the same attention or care, since they consider support more of a side gig rather than an important part of their business model. Make sure the agency has a dedicated team that is committed to and organized around supporting sites.
  2. Look for transparency in billing. Make sure you understand the billing options. Most companies will offer different levels of packages, each with a set number of hours. If you have a site with a lot of traffic and ecommerce for selling items to customers, you’re going to want immediate service if something goes wrong vs. a site that’s more informational and can wait a few hours before a fix is implemented. Understand the levels of service you’re getting and the differences in costs for the timeliness of the response. Also ask what happens with any unused hours paid for in advance: do they rollover to the next month, or are they “use it or lose it?”
  3. Ask if you can talk to a human if needed. All agencies use (or should use) a ticketing system in order to track support requests. Ticketing systems allow for transparency, accountability, and clarity on what is being addressed and when. While these systems are tremendous for tracking the progress of an issue as it gets fixed, using them exclusively can be frustrating if something is hard to explain via text. Ask the agency if you’re allowed to hop on a call with one of their support staff, or the Project Manager, for advice and guidance. Often you can save time and increase clarity to simply have a conversation with a human. Plus it’s nice to establish a relationship with the person in charge of keeping your site running smoothly.
  4. Check that there’s a diverse range of talent within the team. Most developers can do module, plug in and security updates. But can they do any front-end work? What if the theme breaks, or you need a new page design? You might need more than code updates. Go for a more diverse and creative team that has experience with feature development as well as creative enhancements to cover all the range of items you might need.
  5. Determine how important it is if they work in your time zone. Talented designers and developers are all over the globe, but it can be tough to get fast responses from people in time zones very far off from yours. What happens if you need something right away, but it’s the middle of the night for them? If you’re in Hawaii, for example, you may not want to have an east coast agency handle your support. Ask the agency what their hours are, and try to get serviced in as close to your time zone as possible.

Following these tips will help give you confidence that you are asking the right questions and finding the right support services to fit your organization.

If you’re interested in learning more about Kanopi’s support offerings, contact us. We have dedicated support teams for both Drupal and WordPress, with a diverse staff who can cover anything you need. We also do it very well. Our hours are 9:00 am to 5:00 pm your local time in North America . . . and that counts for Hawaii!

The post Top 5 Things to Look For in a Website Support Agency appeared first on Kanopi Studios.

Tandem's Drupal Blog: Test Headless Websites with Lando and Talkback

February 22, 2019 - 22:34
February 24, 2019 Run end to end javascript tests on a decoupled frontend Building on Geoff's posts about setting up Lando, Contenta, and Nuxt, and subsequently fetching resources, today we're going to take a look at ensuring this process works and continues to work for the rest of the development project by writing some automated test...

Lucius Digital: 18 Cool Drupal Modules for site builders and developers | February 2019

February 22, 2019 - 22:20
It is good to keep abreast of available open source 'contrib' Drupal modules. 'There's a module for that', applies to many use cases within Drupal; it's a sin to build something that already exists.

Agiledrop.com Blog: Top 6 SEO Modules for Drupal 8

February 22, 2019 - 18:22

In this post, I take a look at some of the best Drupal 8 SEO modules that can get anyone started with Drupal and its SEO.

READ MORE

Promet Source: 3 Things You Need to Know about Drupal 9

February 22, 2019 - 04:40
“But I don’t want to think about Drupal 9 yet!” Adulting sometimes means doing things we don’t want to do, like thinking about CMS version upgrades.  We can help. For now, here’s what you need to know about Drupal 9.   1. Drupal 9 is targeted for a June 2020 release.   Eighteen months following the release of Drupal 9, in November of 2021, Drupal 7 and 8 will both hit EOL status. This means that you will have a little more than a year to move your site from Drupal 7 or 8, following the June 2020 release date of Drupal 9. 

Kanopi Studios: Drupal 9 is Coming, Part 3: Making the switch to Drupal 8

February 22, 2019 - 03:50

This is Part 2 of a three part series about choices you can make with the news of Drupal 9’s release. Part 1 is an overview. Part 2 is what to do if you choose to stay on Drupal 7. Part 3 is what to do it you choose to upgrade to Drupal 8. 

If you’re following along in our series about the release of Drupal 9, you understand that there are options for upgrading, each with its pros and cons. At Kanopi, we know it’s not a one size fits all decision. We want to provide you with as much information as possible to help you decide what’s right for your site.

To recap, we shared an overview of all the options in part one, and a deep dive for our clients who plan to stick with Drupal 7 in part two. Here in part three, we share a bit of wisdom for those who are considering moving to Drupal 8.

At Kanopi we support more than 100 Drupal 7 sites. Many of them are well optimized and built to last, which can make it difficult to pull the trigger on a rebuild.  

When we talk to our Drupal 7 clients about migrating to Drupal 8, we typically hear one of three things:

  1. We don’t have the budget.
  2. We don’t have the capacity.
  3. The site looks and works perfectly fine.

Below, I’ll dig a bit deeper into each of these objections.

Budget

An average website lasts 3-5 years. However, many stakeholders aren’t aware that they need to budget for a new site that often, so they are caught off guard when the time comes. There are a few ways to bridge this gap:

Build the business case. A business case compares the challenges of sticking with your current site with the new opportunity and ROI that could be gained by making a change.

To get started, we recommend a site audit and creative strategy session to help identify what’s not working and what might be needed to get back on target. You should also take a look at your organic search performance (SEO), accessibility, speed, and overall usability. All of these factors can reveal where your site may be missing the mark and help to justify an upgrade.

When building your case, make sure that you think through the total cost of ownership for your site so that you can reserve enough budget to get the work done right. For example, if you spent $25,000 on your website in 2013, then made incremental updates over the last five years at $10,000 per year, the cost of your site is $75,000. If you want to preserve all features in your rebuild, you should ask for at least $75,000. While you’re at it, it’s a good idea to ask for 25 percent more than the amount it would take to preserve existing features. The redesign process will inevitably generate new ideas and site improvements that will require additional budget to implement. In this example, we would recommend asking for $100,000 and justifying the cost with a breakdown that takes your total cost of ownership into account.

Here’s another example: if you built your Drupal 7 site in house and worked on it for 24 months using a resource who makes $75,000 per year, the site cost your organization $75,000. Knowing this can help you build a rationale that hiring an agency to build your Drupal 8 site at $75-100,000 within six months is a great deal since the work will have similar costs and take far less time to complete.

Demonstrating where and how a new website could show direct ROI can make all the difference when convincing stakeholders to approve the budget for an updated site.

Consider the costs of doing nothing. It’s also helpful to think bigger than the cost of an upgrade and consider the costs of not improving your website. Lost customers, damaged reputation and missed opportunities can be hard to quantify, but should be considered.

For example, if your website’s contact form currently gets completed an average of 10 times a month and 10 percent of those who complete the form convert to a sale, that means each deal is worth $10,000. What if, through a smart redesign and upgrade, you were able to increase form completions to 15 per month and add content and features that support the sales team, resulting in 20 percent sales conversions?

As you can see, there are many ways to frame your case to support budget requests. Use the approach that will work best to help your stakeholders understand the value of your website project and it’s potential to make a meaningful impact on your organization’s bottom line. Once they see the value, the budget will come much more easily.

Capacity

Today’s working world moves at lightning speed. Most of us end up doing far more than what’s included in our job descriptions, and those full plates can make a website rebuild feel impossible to tackle.

If your stakeholders are concerned about your team’s capacity to handle a rebuild, talk to them about approaching the work in smaller phases. Many of our clients tackle rebuilds one phase at a time, often signing on for smaller, more digestible bites that make up a larger endeavor. This can help make the process feel more approachable and easier for stakeholders to wrap their heads around. Try getting started with a bit of user research. Then tackle design. You can continue from there in small steps until the work is complete.  

Alternatively, this is where an agency like Kanopi Studios comes in. Rebuilding your site on Drupal 8 or WordPress is a lot of work, but an experienced agency can take much of that work off your plate by making the process as smooth and straightforward as possible and keeping the project’s momentum at full swing. That keeps your team concentrating on their day to day work while the rebuild happens simultaneously.

The site looks and works fine

The most common objection we hear from our clients is that their stakeholders don’t see a need to change or understand the point of doing things differently through a rebuild.  

Maybe you already have a beautiful website that is driving strong results. If so, that’s wonderful! However, as time goes on, you’ll find you need to mix things up a bit to keep up with the pace of change and stay competitive. Trends shift, customer behavior changes, and Google likes to keep us guessing with their algorithm updates. Change is constant in all things, and even more so online.

Most websites have room for improvement, even if they are doing well. To ensure your site stays current, keeping your CMS up to date should be part of your roadmap. If you’re planning to make any updates this year, consider upgrading to Drupal 8 as part of your solution.

Remember, the safety zone may feel warm and comforting, but it will never give you the insight and growth that exploring the unknown can provide. Who knows what wonderful things could be in your future?

Need help?

We can help you strategize and build your case for an upgrade to Drupal 8, 9, or even WordPress. When in doubt, get in touch! We can work out the best approach together.

The post Drupal 9 is Coming, Part 3: Making the switch to Drupal 8 appeared first on Kanopi Studios.

Lullabot: A Security Checklist for Drupal 8 Sites with Private Data

February 22, 2019 - 02:10

Drupal has a great reputation as a CMS with excellent security standards and a 30+ member security team to back it up. For some Drupal sites, we must do more than just keep up-to-date with each and every security release. A Drupal site with private and confidential data brings with it some unique risks. Not only do you want to keep your site accessible to you and the site’s users, but you also cannot afford to have private data stolen. This article provides a checklist to ensure the sensitive data on your site is secure.

Dries Buytaert: Optimizing site performance by "lazy loading" images

February 21, 2019 - 15:48

Recently, I've been spending some time making performance improvements to my site. In my previous blog post on this topic, I described my progress optimizing the JavaScript and CSS usage on my site, and concluded that image optimization was the next step.

Last summer I published a blog post about my vacation in Acadia National Park. Included in that post are 13 photos with a combined size of about 4 MB.

When I benchmarked that post with https://webpagetest.org, it showed that it took 7.275 seconds (blue vertical line) to render the page.

The graph shows that the browser downloaded all 13 images to render the page. Why would a browser download all images if most of them are below the fold and not shown until a user starts scrolling? It makes very little sense.

As you can see from the graph, downloading all 13 images take a very long time (purple horizontal bars). No matter how much you optimize your CSS and JavaScript, this particular blog post would have remained slow until you optimize how images are loaded.

"Lazy loading" images is one solution to this problem. Lazy loading means that the images aren't loaded until the user scrolls and the images come into the browser's viewport.

You might have seen lazy loading in action on websites like Facebook, Pinterest or Medium. It usually goes like this:

  • You visit a page as you normally would, scrolling through the content.
  • Instead of the actual image, you see a blurry placeholder image.
  • Then, the placeholder image gets swapped out with the final image as quickly as possible.

To support lazy loading images on my blog I do three things:

  1. Automatically generate lightweight yet useful placeholder images.
  2. Embed the placeholder images directly in the HTML to speed up performance.
  3. Replace the placeholder images with the real images when they become visible.
Generating lightweight placeholder images

To generate lightweight placeholder images, I implemented a technique used by Facebook: create a tiny image that is a downscaled version of the original image, strip out the image's metadata to optimize its size, and let the browser scale the image back up.

To create lightweight placeholder images, I resized the original images to be 5 pixels wide. Because I have about 10,000 images on my blog, my Drupal-based site automates this for me, but here is how you create one from the command line using ImageMagick's convert tool:

$ convert -resize 5x -strip original.jpg placeholder.jpg
  • -resize 5x resizes the image to be 5 pixels wide while maintaining its aspect ratio.
  • -strip removes all comments and redundant headers in the image. This helps make the image's file size as small as possible.

The resulting placeholder images are tiny — often shy of 400 bytes.

The original image that we need to generate a placeholder for. The generated placeholder, scaled up by a browser from a tiny image that is 5 pixels wide. The size of this placeholder image is only 395 bytes.

Here is another example to illustrate how the colors in the placeholders nicely match the original image:

Even though the placeholder image should only be shown for a fraction of a second, making them relevant is a nice touch as they suggest what is coming. It's also an important touch, as users are very impatient with load times on the web.

Embedding placeholder images directly in HTML

One not-so-well-known feature of the element is that you can embed an image directly into the HTML document using the data URL scheme:

Data URLs are composed of four parts: the data: prefix, a media type indicating the type of data (image/jpg), an optional base64 token to indicate that the data is base64 encoded, and the base64 encoded image data itself.

data:[][;base64],

To base64 encode an image from the command line, use:

$ base64 placeholder.jpg

To base64 encode an image in PHP, use:

$data =  base64_encode(file_get_contents('placeholder.jpg'));

What is the advantage of embedding a base64 encoded image using a data URL? It eliminates HTTP requests as the browser doesn't have to set up new HTTP connections to download the images. Fewer HTTP requests usually means faster page load times.

Replacing placeholder images with real images

Next, I used JavaScript's IntersectionObserver to replace the placeholder image with the actual image when it comes into the browser's viewport. I followed Jeremy Wagner's approach shared on Google Web Fundamentals Guide on lazy loading images — with some adjustments.

It starts with the following HTML markup:

The three relevant pieces are:

  1. The class="lazy" attribute, which is what you'll select the element with in JavaScript.
  2. The src attribute, which references the placeholder image that will appear when the page first loads. Instead of linking to placeholder.jpg I embed the image data using the data URL technique explained above.
  3. The data-src attribute, which contains the URL to the original image that will replace the placeholder when it comes in focus.

Next, we use JavaScript's IntersectionObserver to replace the placeholder images with the actual images:

document.addEventListener('DOMContentLoaded', function() {
  var lazyImages = [].slice.call(document.querySelectorAll('img.lazy'));

  if ('IntersectionObserver' in window) {
    let lazyImageObserver = new IntersectionObserver(
      function(entries, observer) {
        entries.forEach(function(entry) {
          if (entry.isIntersecting) {
            let lazyImage = entry.target;
            lazyImage.src = lazyImage.dataset.src;
            lazyImageObserver.unobserve(lazyImage);
          }
        });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  }
  else {
    // For browsers that don't support IntersectionObserver yet,
    // load all the images now:
    lazyImages.forEach(function(lazyImage) {
      lazyImage.src = lazyImage.dataset.src;
    });
  }
});

This JavaScript code queries the DOM for all elements with the lazy class. The IntersectionObserver is used to replace the placeholder image with the original image when the img.lazy elements enter the viewport. When IntersectionObserver is not supported, the images are replaced on the DOMContentLoaded event.

By default, the IntersectionObserver's callback is triggered the moment a single pixel of the image enters the browser's viewport. However, using the rootMargin property, you can trigger the image swap before the image enters the viewport. This reduces or eliminates the visual or perceived lag time when swapping a placeholder image for the actual image.

I implemented that on my site as follows:

const config = {
    // If the image gets within 250px of the browser's viewport, 
    // start the download:
    rootMargin: '250px 0px',
  };

let lazyImageObserver = new IntersectionObserver(..., config);
Lazy loading images drastically improves performance

After making these changes to my site, I did a new https://webpagetest.org benchmark run:

You can clearly see that the page became a lot faster to render:

  • The document is complete after 0.35 seconds (blue vertical line) instead of the original 7.275 seconds.
  • No images are loaded before the document is complete, compared to 13 images being loaded before.
  • After the document is complete, one image (purple horizontal bar) is downloaded. This is triggered by the JavaScript code as the result of one image being above the fold.

Lazy loading images improves web page performance by reducing the number of HTTP requests, and consequently reduces the amount of data that needs to be downloaded to render the initial page.

Is base64 encoding images bad for SEO?

Faster sites have a SEO advantage as page speed is a ranking factor for search engines. But, lazy loading might also be bad for SEO, as search engines have to be able to discover the original images.

To find out, I headed to Google Search Console. Google Search Console has a "URL inspection" feature that allows you to look at a webpage through the eyes of Googlebot.

I tested it out with my Acadia National Park blog post. As you can see in the screenshot, the first photo in the blog post was not loaded. Googlebot doesn't seem to support data URLs for images.

Is IntersectionObserver bad for SEO?

The fact that Googlebot doesn't appear to support data URLs does not have to be a problem. The real question is whether Googlebot will scroll the page, execute the JavaScript, replace the placeholders with the actual images, and index those. If it does, it doesn't matter that Googlebot doesn't understand data URLs.

To find out, I decided to conduct an experiment. Yesterday, I published a blog post about Matt Mullenweg and me visiting a museum together. The images in that blog post are lazy loaded and can only be discovered by Google if its crawler executes the JavaScript and scrolls the page. If those images show up in Google's index, we know there is no SEO impact.

I'm not sure how long it takes for Google to make new posts and images available in its index, but I'll keep an eye out for it.

If the images don't show up in Google's index, lazy loading might impact your SEO. My solution would be to selectively disable lazy loading for the most important images only. (Note: even if Google finds the images, there is no guarantee that it will decide to index them — short blog posts and images are often excluded from Google's index.)

Conclusions

Lazy loading images improves web page performance by reducing the number of HTTP requests to render a page.

Ideally, over time, more browsers will support lazy loading images natively, and some of the SEO challenges will no longer be an issue. Until then, it's not hard to implement good lazy loading yourself. For my own site, it took about 40 lines of JavaScript code and 20 lines of additional PHP/Drupal code.

I hope that by sharing my experience, more people are encouraged to run their own sites and to optimize their sites' performance.

Drupal Mountain Camp: Drupal Mountain Camp Program updates

February 21, 2019 - 04:08
Drupal Mountain Camp Program updates admin Wed, 02/20/2019 - 22:08

Hi everyone,

we are excited to share a few program updates on Drupal Mountain Camp as the team behind the scenes is working hard preparing the last bits before the conference in just 2 weeks.

We are extremely grateful for all the quality session submissions people have submitted. The full schedule over 4 days includes 9 workshops, 2 keynotes, 4 featured sessions and 42 regular sessions in 3 different tracks. 

Besides the already promoted keynotes, we would like to highlight the following featured sessions:

Thanks to the collaboration with the Drupal Recording Initiative by Kevin Thull, we'll be able to provide video recordings for you after the conference.

Contribution is a key topic for Drupal Mountain Camp. Make sure to sign-up for one of the 7 different initiatives or propose your own using our contribution sign-up sheet.

We also updated our social events page so you can start preparing for some fun in the snowy Swiss mountains.

So far, more than 95 tickets have been sold. Regular tickets are available for CHF 120 until 1st of March, afterwards we sell tickets for CHF 140.

We are looking forward seeing you at Drupal Mountain Camp in Davos, 7-10 of March 2019.

Josef / dasjo on behalf of the Drupal Mountain Camp team.

Jeff Geerling's Blog: How I upgrade Drupal 8 Sites with exported config and Composer

February 21, 2019 - 03:03

Over the years, as Drupal has evolved, the upgrade process has become a bit more involved; as with most web applications, Drupal's increasing complexity extends to deployment, and whether you end up running Drupal on a VPS, a bare metal server, in Docker containers, or in a Kubernetes cluster, you should formalize an update process to make sure upgrades are as close to non-events as possible.

Gone are the days (at least for most sites) where you could just download a 'tarball' (.tar.gz) from Drupal.org, expand it, then upload it via SFTP to a server and run Drupal's update.php. That workflow (and even a workflow like drush up of old) might still work for some sites, but it is fragile and prone to cause issues whether you notice them or not. Plus if you're using Drush to do this, it's no longer supported in modern versions of Drush!

So without further ado, here is the process I've settled on for all the Drupal 8 sites I currently manage (note that I've converted all my non-Composer Drupal codebases to Composer at this point):

Security advisories: Drupal core - Highly critical - Remote Code Execution - SA-CORE-2019-003

February 21, 2019 - 02:18
Project: Drupal coreDate: 2019-February-20Security risk: Highly critical 20∕25 AC:None/A:None/CI:All/II:All/E:Theoretical/TD:UncommonVulnerability: Remote Code ExecutionCVE IDs: CVE-2019-6340Description: 

Some field types do not properly sanitize data from non-form sources. This can lead to arbitrary PHP code execution in some cases.

A site is only affected by this if one of the following conditions is met:

  • The site has the Drupal 8 core RESTful Web Services (rest) module enabled and allows PATCH or POST requests, or
  • the site has another web services module enabled (like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7).
Solution: 

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

To immediately mitigate the vulnerability, you can disable all web services modules, or configure your web server(s) to not allow PUT/PATCH/POST requests to web services resources. Note that web services resources may be available on multiple paths depending on the configuration of your server(s). For Drupal 7, resources are for example typically available via paths (clean URLs) and via arguments to the "q" query argument. For Drupal 8, paths may still function when prefixed with index.php/.

Reported By: Fixed By: 

Agiledrop.com Blog: Interview with Amber Matz: How will Drupal's greatest challenge shape its future?

February 20, 2019 - 17:40

This week we talked with Amber Matz, Production Manager and Trainer at Drupalize.me. In addition to these two important roles, Amber is actively involved in a number of projects in the Drupalverse, the current most notable one likely being the program team for the Builder Track at DrupalCon Seattle. Have a read if you’d like to find out more about her journey with Drupal and her insights on its future.

READ MORE

Sooper Drupal Themes: Sooperthemes Terms of Service and Pricing Update

February 20, 2019 - 16:23

With growth comes changes and today we're introducing changes to our legal terms and pricing. The basic susbcription remains the same at $78 USD per year and the Professional subscription was bumped from $249 to $360 USD per year. The Enterprise subscription now starts at $3000 with a $1000 USD set-up fee which is needed for the one-time job of collecting brand logos and brand names and setting up our scripts to produce the white-labeled/re-branded products automatically. The Enterprise subscription will now be charged per month rather than per year.

New terms of service: https://www.sooperthemes.com/legal/terms
Services catalog:  https://www.sooperthemes.com/legal/services-catalog

Drupal is becoming more valuable but more expensive

3 years after Drupal 8's release the results are in: Drupal is still relevant but Drupal 8 is more expensive to implement and Drupal's adoption curve has tapered off. I don't think this is necessarily bad. Drupal's leadership made a decision to make Drupal the best Enterprise-grade CMS, not the best everyman's CMS. The result is that Drupal's steep learning curve became steeper yet, and costs of training and hiring Drupal developers increased accordingly. Our price bump is not merely a reaction to a decrease in the volume of Drupal websites in need of our solutions, it is also part of our learning process. 

Sooperthemes is growing but it is not growing enough

Since our Drupal 8 launch last year business at Sooperthemes is better than ever. But with our growing popularity comes a big increase in workload from the customer support forum, customer success tasks, and managing simple tasks like account administration, taxes, sales questions. It adds up to a lot of work. Currently our prices are too low for the increase in customers to pay for new staff to take on the additional workload. We have been investing a lot of effort in training interns but the time has come to move to a more sustainable solution.

Without changes Sooperthemes is not ready for the future. This price increase in the Professional subscription is one part of our strategy for sustainable growth.

Another change is getting better at charging big clients more than small clients. We want to keep our products accessible to the entire Drupal community. While we love our enterprise clients. we don't want to develop an amazing product just for the Drupal elite who can afford hundreds or thousands of dollars per month per site. Therefore we're introducing new licensing terms to charge users based on the scale of their usage of our flagship product Glazed Builder.

We updated our terms for us to be able to charge websites fairly not just by the number of domain (site) licenses, but also by the number of users who are using our Glazed Builder product. Some examples to illustrate why I think this is fair.

  1. Freelance Music teacher's website with 1 domain license: $78 USD per year including updates and support.
  2. An Drupal agency with currently 10 clients on our products: $360 USD per year.
  3. A fast-moving consumer goods enterprise with 40 enterprise domain licenses: ~3000 USD per month.
  4. If Tesla.com would use our products for their marketing content, job portal, community forum, online stores, online tools, in 37 languages: $78 USD per year, or 6 dollars and 50 cents per month.

I think the last example illustrates why it makes sense to introduce this new lever to help Sooperthemes grow sustainably.  To learn how exactly our new licensing term works make sure to read our services catalog.  

Provide More Value To Enterprise Clients

In order for Sooperthemes to be successful in the future we will need to work on signing on more Enterprise clients. We're going to work on adding more features that are important to enterprise clients. Starting today we offer better support options and dedicated support developers to cases in the Enterprise tier. If you want to share ideas on what you think should differentiate the Enterprise subscription tier from the other tiers don't hesitate to send me an email here: https://www.sooperthemes.com/contact

I would be especially interested in hearing what it would take for your business to purchase an enterprise subscription.

Photo by Benjamin Voros on Unsplash

Dries Buytaert: Two internet entrepreneurs walk into an old publishing house

February 20, 2019 - 15:55

A month ago, Matt Mullenweg, co-founder of WordPress and founder of Automattic, visited me in Antwerp, Belgium. While I currently live in Boston, I was born and raised in Antwerp, and also started Drupal there.

We spent the morning together walking around Antwerp and visited the Plantin Moretus Museum.

The museum is the old house of Christophe Plantin, where he lived and worked around 1575. At the time, Plantin had the largest printing shop in the world, with 56 employees and 16 printing presses. These presses printed 1,250 sheets per day.

Today, the museum hosts the two oldest printing presses in the world. In addition, the museum has original lead types of fonts such as Garamond and hundreds of ancient manuscripts that tell the story of how writing evolved into the art of printing.

The old house, printing business, presses and lead types are the earliest witnesses of a landmark moment in history: the invention of printing, and by extension, the democratization of publishing, long before our digital age. It was nice to visit that together with Matt as a break from our day-to-day focus on web publishing.

OpenSense Labs: The Magic of Zurb Foundation

February 20, 2019 - 13:10
The Magic of Zurb Foundation Vasundhra Wed, 02/20/2019 - 11:40

You don’t want people to treat your website as an outcast. You don’t want to be the ugly duckling in this sharp, serious and extremely competitive world. 

Correct?

Thus, owning a professional looking website becomes an important platform for all sorts of business. It doesn’t really matter whether you are planning to make money or not, treating your website just like your employees is a must.

Why?

Well, because it creates an impression of your business, a place where people come to see who you are and what you want. Whether it is a big e-commerce site or a one-pager - a good website would always bring values to you and your company.  


As important as the website is for you, the themes contributes highly to the user experience and functionality of a particular site.

Your theme is the overall look, feel and styling of your website and the very first thing which the audience witnesses. And nothing can beat Drupal in this area.  

Beginning with the Zurb Foundation 

So here is Zurb foundation for you.

Zurb Foundation is the prototype theme that is used to prototype in the browser. It allows you to rapidly create a website or application while leveraging mobile and responsive technology that is well tested. 

The front end framework is the collection of HTML, CSS, and Javascript containing design patterns. These design patterns help the user in persevering time by helping them to dodge boring, boilerplate codes. The sites that are built on this foundation works great when there are multiple screens which include laptops, mobile phone, PC, iPad. The reason is that Zurb foundation has a responsive framework that uses CSS media queries and a mobile-first approach. 


Different versions of Zurb 
 


Zurb Foundation 3

If the primary goal for your website is rapid prototyping then Zurb foundation 3 is for you.  This theme is developed in Sass, which is a powerful CSS pre-processor that helps you to write, clean and organize CSS which can be maintained easily over time. 

One of the biggest advantages of using Zurb Foundation 3 was the shift of development of the framework to Sass and compass rather than pure CSS. 

Sass grants the user with variables, functions and powerful mixin that speeds up the development of framework as well as made the code more coincide. 


Zurb Foundation 4 

This version of Zurb foundation brought many new functionalities and changes in its framework. Started from being a mobile-friendly theme, Zurb foundation 4 supported some complex layouts, grids, and media queries. 

This version brought about flexible and powerful built-in tools with the advantage of it being accessible to different screen size (new, simpler syntax that better reflects how the grid works)

Apart from this, Zurb foundation 4 is all about semantics.  Users were granted with the power of removing and writing all the presentational classes from the markup with built-in sass mixins and extensions. 

Zurb Foundation 4 also presented the users with some splendid plugins that worked well with AJAX. 


Zurb Foundation 5

Fast, strong and a better foundation, Zurb foundation 5 is great for designers and developers that are using it in their workflow. The foundation specifically focused on smart coding that introduced the users with better coding practices. And if it is a team then this would give them an idea to start from a common point. The advantage: It helped them to put together all interactions and workflow in a shorter period of time. 

Zurb Foundation 6

Foundation of site 6 has been designed to give the users with production efficiency in their project. It includes a wide range of modular and flexible components that are not only lightweight but easy to maintain as well. 

Foundation 6 is also half the size of foundation 5, in other words, there was a reduction of 50 % code. All these codes have come with ARIA attributes and roles alongside instructions. 

The base style in foundation 6 act as a coded framework, which makes the work of the user even more easy and flexible. Simpler CSS styles allow the user to easily modify them and fit it according to their needs. 


Zurb Foundation or Bootstrap?

If talking about Zurb and its different version, bootstrap tends to make its way between all this. 

How?

Well, because Bootstrap and Zurb are the major participants when it comes to web designing methods.  Often designers and developers seem to get lost in the mist while battling and choosing between one. 

  Zurb Foundation Bootstrap Community The community here is smaller as compared to bootstrap but it is growing with decent technical support.  The community here is smaller as compared to bootstrap but it is growing with decent technical support.  CSS Preprocessor Foundation supports SASS Bootstrap also supports SASS but it is a less camp. Customization Minimalist approach to its pre-built UI components giving room to the designers to create new things. Bootstrap consist of basic GUI customizer which most of the time doesn’t allow the users to create something new.  Browser Support Supports Chrome, Mozilla Firefox, Safari, opera, android  Supports Chrome, Mozilla Firefox, Safari, opera, android, and IE8 Grid System Foundation was the first one to go mobile friendly and adapt to the grid system. Bootstrap has ample of time to bridge the gap in terms of features and functionalities.  Advanced Feature Elements Zurb foundation   of X-y grid, responsive tab, off-canvas etc It is customizable with a variety of designs. Releases Zurb has more releases w.r.t the development requirement. It has 6 releases and the 7th one is yet to come. Bootstrap has 4 release. The  4th  release was on August 19, 2011 Why choose Drupal for Zurb foundation?

When building a website what is the very first thing which the user sees?

Content? Functionalities? Information? Or Layout?

Selecting the theme and functionalities of a website is one of the most primary decisions that a website owner has to make and Drupal is the CMS that can help you achieve this task. It has about 1,316 themes where each theme has a variety of strengths

Out of which Zurb Foundation theme is grid-based, mobile first CSS. When used with Drupal, Zurb provides efficiency to the front end developer. It is a platform-specific method that helps you achieve various functionalities. 

  • The foundation XY grid (in timeless condition) allows the user to easily create and layout Drupal content.
  • The top bar of the foundation is combined with Drupal’s menu navigation and works well with submenus.
  • The off-campus region in the Zurb foundation are available as Drupal blocks and the menu bar that is placed in this region are automatically themed. 

Creating Sub Themes 

It is imperative that the user creates a sub-themes that allow Zurb foundation to apply on any website. 

There are two ways of creating a sub-theme:

Drush: Drush is basically a command line access to common Drupal administrative tasks and configuration. The user can change the directory with the help of Drush.  

Manually: The user can also create sub-themes manually. They can complete the task by expanding the theme folder and then replacing it with starter files. 

Contributed Drupal modules that can be used with Zurb The Zurb foundation aims to do theming without the help of any dependencies but there are many modules that help in theming better. 

Modules like panels, block class, display suite, special menu items. 

Panels: Panels module allow a site administrator to create customized layouts for one or more users. It provides an API that allows the configuration and placement of
blocks into regions. 

Block Class: Block class allows the user to add classes to any block through the block’s configuration interface. 

Display Suite: Display suite allows the users to take control over content fully using drag and drop interface. 

Menu Items: This module allows the user to create dropdown divider and all sort of headers in the navigation menu. 

Case Study on MIT Press CogNet 

MIT Press CogNet is an essential online resource for all the students and scholars that are into cognitive sciences. 

The objective of this project was to provide a completely responsive design in all devices for the users. An organization worked closely with the CogNet team. With the CogNet team, they developed a basic wireframe. custom Drupal theme based on the zurb foundation was built.

Zurb foundation theme and sass for CSS preprocessing were used to rework the already existing theme. To guarantee a seamless experience on any type of screen the developers used jQuery to construct slick navigation, scrolling, and content exploration. 

The results were eye-catching. From being a desktop-only website, MIT Press CogNet was modified into an accessible one where the users were able to view it in any device. The biggest achievement of the whole procedure was that it was done under the budget provided by the organization.  

Future of Zurb Foundation

Zurb is yet to launch another version of the architecture (ITCSS+SMACSS). 

Zurb Foundation 7 separates the view layer from the logic layer to make it easy and reliable. 

It would dramatically improve your freedom to shift between JavaScript frameworks with a super-powerful pluggable JavaScript architecture. In short, there are two major changes that would take place in Zurb Foundation 7 

The first one as mentioned would dramatically let user shift between javascript frameworks with javascript architecture. UI framework today tends to either go in one framework or have different and independent ports for different JS framework.

And yes, the second major change in the foundation is the ITCSS based architecture with the usage of SMACSS. This would make it easier to build and maintain scalable sites and themes. 

Conclusion 

Remember that themes are connected to the protagonist's internal journey. It is not just the visuals but it is also the journey of the user experience that they would have while going through your website.

At OpenSense labs, we understand how important it is to create a website that matches your goals and objectives. Ping us at hello@opensenselabs.com so that we can arrange services to make your website what you have always hoped for. 

blog banner blog image Drupal Drupal 8 Zurb Foundation Drupal theme Bootstrap Blog Type Articles Is it a good read ? On

Acro Media: Drupal 8 Commerce Performance Benchmarks

February 19, 2019 - 23:45
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.

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.

Security public service announcements: Critical Release - PSA-2019-02-19

February 19, 2019 - 21:11
Date: 2019-February-19Security risk: Highly critical 20∕25 AC:None/A:None/CI:All/II:All/E:Theoretical/TD:UncommonVulnerability: Critical ReleaseDescription: 

There will be a security release of 8.5.x and 8.6.x on February 20th 2019 between 1PM to 5PM America/New York (1800 to 2200 UTC). (To see this in your local timezone, refer to the Drupal Core Calendar) . The risk on this is currently rated at 20/25 (Highly critical) AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Uncommon.

Not all configurations are affected. Reserve time on February 20 during the release window to determine whether your sites are affected and in need of an immediate update. Mitigation information will be included in the advisory.

Contributed module security updates may also be required.

If you are running Drupal 7, no core update is required, but you may need to update contributed modules if you are using an affected module. We are unable to provide the list of those modules at this time.

Neither the Security Team nor any other party is able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.

Security release announcements will appear on the Drupal.org security advisory page.

ComputerMinds.co.uk: How to import config without losing changes

February 19, 2019 - 19:00

Drupal empowers site builders and editors to configure their sites in settings forms. Configuration management lets developers push changes up to live sites to be imported. But developers have to be considerate to ensure imports will not wipe out those changes made directly through the live sites' settings forms. At the least, they have to export the changes before making further tweaks. But admins may make further changes in the meantime too, so developers can end up frequently pulling irrelevant changes back from live, which seems unnecessary.

Here's some examples of the kind of config that I'm thinking of:

  • The site email and Google Analytics account are usually managed by site admins, not developers. So developers should not be the ones to manage those settings.
  • Marketers may like tweaking the site name or slogan. That doesn't need to affect developers.
  • Contact forms contain labels and other text which may be key to the communication between a client and their customers.
  • Permissions - sometimes it's not clear where the lines are between editors/admins/etc, so why not allow some flexibility to reassign permissions directly on live without needing to touch the codebase?

We need an approach that allows for specific settings to be considered 'unmanaged' - so an import wouldn't touch whatever they have made to be on live. The Config Ignore project claims to solve this, but we already use Config split which is more powerful, more flexible and has a better user interface. (Although Config Ignore does allow targeting parts of config rather than whole config items.)

Config split is often used to create environment-specific sets of configuration, but its design means it can be used for separating config for other purposes. In this scenario, what's needed is a split that represents settings to be protected, which can be exported immediately before any import. Then when importing, Drupal only sees the preserved version of the settings, so won't change them, regardless of what is in the main configuration files.

The split, which I've called 'Unmanaged', needs to be set up like as follows (see screenshot):

  • Use a folder (directory) which already exists and is writable. I use ../config/unmanaged, so it matches the split name and is outside the webroot.
  • Set to active. I usually set all other splits to inactive, and only make them active in an environment's settings.php, but this split exists for the sake of workflow, not environment. For example, it can actually be useful locally, so I can tweak things for development without affecting what ends up in version control.
  • Have the largest weight of any split, so that it overrides any other exported version of config it contains.
  • Use the Conditional split section, not Complete split, to pick configuration to protect.
  • Do not tick either of the checkboxes in the conditional split section.

Once the split has been created, the container needs rebuilding for it to work. Run this, which includes exporting it for the first time:

drush cache-rebuild
drush -y config-split-export unmanaged

Now that it is exported, a .htaccess file will be have been added to the directory alongside the config. Add the following line to your project's .gitignore file, adjusting the directory location as appropriate. This ensures the directory will get created on live when changes are pulled from git (containing .htaccess), but deliberately without the exported config:

config/unmanaged/*.yml

So now before running any imports, make sure to export the split:

drush -y config-split-export unmanaged
drush -y config-import

With this split and the export step in place in your workflow, you can be confident of allowing your developers and site admins to get on with their respective work, without getting in each others' way. This puts configuration splits to use for something beyond environment-specific overrides, which I think is exciting. I wonder what other useful purposes they may have?

 

Photo by Sascha Hormel from Pexels

OSTraining: PHP Notices, Warnings and Errors on Your Drupal Site

February 19, 2019 - 13:00

Websites will run into problems. Whether you're using Drupal or any other software, there will be problems at some point.

Drupal runs on PHP and when PHP has problems, it reports them to you. 

However, often these errors will appear on your site and will be visible to visitors, as in the image below:

Agaric Collective: Build and Manage Online Donations in Drupal with the Give Module

February 19, 2019 - 01:32

So often an organization's online donation system is divorced from their website. For staff, it means one more tool to use and manage. For supporters, it can result in a donation experience that is tedious or clunky. There are free software tools like CiviCRM and CommitChange which do a good job of feeling integrated into your site, despite being a separate system. However, for smaller groups these tools can be overkill. We built the Give module to provide a lightweight donation solution built right into your Drupal site.

 

Read more and discuss at agaric.coop.