Drupal News

Finalist Drupal Blog: Load testing in Drupal (part 1)

Main Drupal Feed - Sun, 06/17/2018 - 22:00

So, we are building this great community portal for all the world to see. We thought about all aspects that would make this project a huge success. We are heavily in control. And finally the day has come: our portal hits the worldwide web. And so it seems, the website is well received! A little too well received. Soon traffic rates hit the ceiling. And so does our carefully configured web server. End of this little story. We’ve become the victim of our own success.

Performance testing is all about being prepared

OK, so perhaps this tale is a little bit over dramatized. Still, in my daily work I see this kind of misery happening a lot. To be honest… we tend to step into this pitfall as well from time to time. And we shouldn’t have to.

Testing the performance of your site means that you can actually prepare for large amounts of traffic on your site. You can be predictable.

If we really wanted this site to be a success, we might have had to prepare better for that success.

This is where performance testing comes in. We simply want to know how our website is performing once it hits higher traffic rates.

What are we testing anyway?

But what do we actually test? What about busy periods? Does the caching do its job? Or have we configured things incorrectly? And when we really tighten the screw, what will happen? Will it bring down our site? What about peak times, just after our project went viral? And are we fully utilizing the server capacity?

We use a load test to closely monitor the use of the site. This way we can make statements about the performance.

But… it comes down to the same problems anyway?

Without performance testing we can look at common causes that can give rise to performance problems. Wrongly deployed caching is obvious. And perhaps you simply load too much data on a page, stressing the database. If you are an experienced Drupal developer, there is a fair chance that guess right we can and sleep peacefully again. In many cases, the real problem is something you did not think of.

Performance tests

There are many different types of performance tests. We will discuss some.

Load testing

With a load test we mainly look at the expected load on the site. So: if we build an intranet, we want to know what happens when, for example, 60% of the company simultaneously uses the intranet intensively.

Stress testing

With stress testing we look more at deviant situations. An exceptional load. In the example of our fansite: we appear in the news and therefore suddenly have a multitude of visitors. Our example is of course exaggerated. It is difficult to anticipate an unexpected and absurdly high number of visitors. But what we do want to know: where is the border?

Endurance testing

With an endurance test, we test the site measured over a longer period, to investigate whether the site will perform worse over time, for example due to the increase of logged-in users or content.

Peak testing

With peak testing we mainly look at intensity peaks. In the example of the intranet you can think of a peak in the morning when everyone arrives at the office.

Load testing: 5 steps

Because we want to know if our site can handle the desired number of visitors, and we also want to know how far we can go, we focus on load and stress testing.

The steps are the following.

1. Analysis of any existing data

Simply retrieve from existing statistics, for example visitor numbers. This helps to create realistic scenarios in our test preparation. In the analysis we can fall back on tools such as Google Analytics. But … if the site is new, we have to make statements about traffic in a different way. Often the customer can share some insights about this. And you might be building a new version of the same site so you can still say a lot about expected visits.

2. Think of some scenarios

Make sure you will test with realistic scenarios. Prepare the test well! One scenario is not enough. We want to simulate that a large number of visitors, simultaneously, click on several pages, download documents, log in, send forms, etc. Therefore, make sure you have enough CPU on your machine to perform the tests. And … determine limit values ​​for the test, to assign a score to the performance.

APDEX

The APDEX may be of help here. The APDEX is an industry standard to make statements about satisfaction with performance based on tests. Actually, we can thus determine whether the performance meets the expectations! Response times alone do not say much. We can interpret this with the APDEX. The APDEX is a score based on satisfaction surrounding the performance. A lot of tools, such as New Relic and Jmeter, therefore use the APDEX.

The APDEX calculates a score based on measurements: Satisfying, Tolerating and Frustrating. We will apply a time aspect here, for example: Satisfying: 0-1.5 seconds; Tolerating: 1.5-6 seconds; Frustrating: 6 seconds or more.

  • Satisfying results count for 100% (this is great)
  • Tolerating results count for 50% (this is ok)
  • Frustrating results do not yield a score (this is not good)

And then it is time to do some calculations.

APDEX = Satisfied + (Tolerated / 2) / Total samples 3. Pick the right tool

Determine which tooling we can use to carry out the test. And, well ok, there is a lot to be found out there. Let’s try to highlight some.

  • AB - Apache Bench - What can we say, this is very easy. It proves some low level local testing is not that hard.
  • Gatling - A paid (and great) alternative for powerful open source tooling like JMeter. Check out this extensive comparison.
  • Locust: Define user behavior with Python code.
  • Siege - Similar to AB, but more extensive, useful to perform a quick load test.
  • Blazemeter - Simple characterization: a hosted version of Jmeter. Less simple characterization: testing on steroids. Offering A LOT when it comes to testing. Test from all over the world, very large numbers, hosted Selenium, Gatling, Locust and more…
  • Jmeter - Open source, many possibilities, the old, the proven solution. Still goin’ strong.

We should point out that Blazemeter stands out as a modern, versatile cloud test platform (not only load testing!).

Some pros: - Easy / quick boarding - Drupal (D7 + D8) stable module available - Important advantages with respect to JMeter: geography is not limited to your own local environment and processing is not limited to your own machine.

Yes, a con: It is a commercial solution, it will cost you money…

4. Carry out the test

In part 2 of this series we will actually carry out a test in Siege and Jmeter.

5. Analyze

After running the test we will analyze the results. Do we learn more about problems in our application? In part 3 of this series, we will look at profiling and analyzing.

Coming up in Load testing in Drupal (part 2):
  • Performing load tests to your Drupal application in Siege and JMeter.
Coming up in Load testing in Drupal (part 3):
  • Profiling and monitoring your Drupal application with XHProf / XHGui and New Relic.

Ashday's Digital Ecosystem and Development Tips: Better Admin Interfaces with ReactJS and Drupal 8

Main Drupal Feed - Fri, 06/15/2018 - 19:00

As you may or may not have noticed, we’re having a lot of fun over here at Ashday building Drupal sites with React. Check out our own site, for example. We are really digging this new direction for front-end and you can learn more about why we did it how we approached it in other articles, but here we are going to talk about how we approached the Drupal editorial experience, because honestly - we just didn’t find a lot of great resources out there discussing how this might be done well in a decoupled experience.

Drupal blog: A plan for Drupal and Composer

Main Drupal Feed - Fri, 06/15/2018 - 15:51

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

At DrupalCon Nashville, we launched a strategic initiative to improve support for Composer in Drupal 8. To learn more, you can watch the recording of my DrupalCon Nashville keynote or read the Composer Initiative issue on Drupal.org.

While Composer isn't required when using Drupal core, many Drupal site builders use it as the preferred way of assembling websites (myself included). A growing number of contributed modules also require the use of Composer, which increases the need to make Composer easier to use with Drupal.

The first step of the Composer Initiative was to develop a plan to simplify Drupal's Composer experience. Since DrupalCon Nashville, Mixologic, Mile23, Bojanz, Webflo, and other Drupal community members have worked on this plan. I was excited to see that last week, they shared their proposal.

The first phase of the proposal is focused on a series of changes in the main Drupal core repository. The directory structure will remain the same, but it will include scripts, plugins, and embedded packages that enable the bundled Drupal product to be built from the core repository using Composer. This provides users who download Drupal from Drupal.org a clear path to manage their Drupal codebase with Composer if they choose.

I'm excited about this first step because it will establish a default, official approach for using Composer with Drupal. That makes using Composer more straightforward, less confusing, and could theoretically lower the bar for evaluators and newcomers who are familiar with other PHP frameworks. Making things easier for site builders is a very important goal; web development has become a difficult task, and removing complexity out of the process is crucial.

It's also worth noting that we are planning the Automatic Updates Initiative. We are exploring if an automated update system can be build on top of the Composer Initiative's work, and provide an abstraction layer for those that don't want to use Composer directly. I believe that could be truly game-changing for Drupal, as it would remove a great deal of complexity.

If you're interested in learning more about the Composer plan, or if you want to provide feedback on the proposal, I recommend you check out the Composer Initiative issue and comment 37 on that issue.

Implementing this plan will be a lot of work. How fast we execute these changes depends on how many people will help. There are a number of different third-party Composer related efforts, and my hope is to see many of them redirect their efforts to make Drupal's out-of-the-box Composer effort better. If you're interested in getting involved or sponsoring this work, let me know and I'd be happy to connect you with the right people!

Dries Buytaert: A plan for Drupal and Composer

Main Drupal Feed - Fri, 06/15/2018 - 14:08

At DrupalCon Nashville, we launched a strategic initiative to improve support for Composer in Drupal 8. To learn more, you can watch the recording of my DrupalCon Nashville keynote or read the Composer Initiative issue on Drupal.org.

While Composer isn't required when using Drupal core, many Drupal site builders use it as the preferred way of assembling websites (myself included). A growing number of contributed modules also require the use of Composer, which increases the need to make Composer easier to use with Drupal.

The first step of the Composer Initiative was to develop a plan to simplify Drupal's Composer experience. Since DrupalCon Nashville, Mixologic, Mile23, Bojanz, Webflo, and other Drupal community members have worked on this plan. I was excited to see that last week, they shared their proposal.

The first phase of the proposal is focused on a series of changes in the main Drupal core repository. The directory structure will remain the same, but it will include scripts, plugins, and embedded packages that enable the bundled Drupal product to be built from the core repository using Composer. This provides users who download Drupal from Drupal.org a clear path to manage their Drupal codebase with Composer if they choose.

I'm excited about this first step because it will establish a default, official approach for using Composer with Drupal. That makes using Composer more straightforward, less confusing, and could theoretically lower the bar for evaluators and newcomers who are familiar with other PHP frameworks. Making things easier for site builders is a very important goal; web development has become a difficult task, and removing complexity out of the process is crucial.

It's also worth noting that we are planning the Automatic Updates Initiative. We are exploring if an automated update system can be build on top of the Composer Initiative's work, and provide an abstraction layer for those that don't want to use Composer directly. I believe that could be truly game-changing for Drupal, as it would remove a great deal of complexity.

If you're interested in learning more about the Composer plan, or if you want to provide feedback on the proposal, I recommend you check out the Composer Initiative issue and comment 37 on that issue.

Implementing this plan will be a lot of work. How fast we execute these changes depends on how many people will help. There are a number of different third-party Composer related efforts, and my hope is to see many of them redirect their efforts to make Drupal's out-of-the-box Composer effort better. If you're interested in getting involved or sponsoring this work, let me know and I'd be happy to connect you with the right people!

Drupal Light

Drupal Themes - Fri, 06/15/2018 - 13:47

Immediate Requirement for Senior Drupal Developers (3 ) positions 

Drupal News Org - Fri, 06/15/2018 - 08:38

Candidates having 5+ years of experience in the following only may apply:

•Drupal 7/8 •Design patterns •OOPS •SQL Server •Either .NET / Java •Framework: Laravel / Symfony /Zend / CakePHP •Multisite •Selenium/ UI testing •REST /SOAP •GIT/ Similar •Angular

Job location : Hyderabad, email : hr@aheadrace.com, Phone: 040 - 66550550

website: www.aheadrace.com

Agiledrop.com Blog: AGILEDROP: Introduction to Drupal Commerce

Main Drupal Feed - Thu, 06/14/2018 - 23:17
Drupal and Commerce. These are two words that aren’t usually associated with each other. But do you know that Drupal can become a great eCommerce solution thanks to a dedicated software for it called Drupal Commerce? If you didn’t, then well, you are in for a treat. Let’s take a look at what Drupal Commerce is and how it can be used to create an eCommerce store using Drupal. Drupal Commerce at its core is a set of modules for Drupal that enable a host of eCommerce functionalities for Drupal which I’ll be highlighting further in the post. It was developed and is maintained by The Commerce… READ MORE

Lullabot: Not your grandparent’s Drupal, with Angie “Webchick” Byron

Main Drupal Feed - Thu, 06/14/2018 - 22:39
Mike and Matt talk with Angie "Webchick" Byron on what she's been up to, various Drupal initiatives, and what Drupal needs to do to succeed.

Acro Media: Web to Print with Drupal Commerce

Main Drupal Feed - Thu, 06/14/2018 - 14:45
Empower your customers to customize products.


There is a high likelihood that the tshirt on your back or in your closet started life as someone’s idea that was being uploaded to an online tool. The idea that a person could not only buy tshirts, but design them in a tool and approve the proof before payment seems almost commonplace. Why aren’t more people talking about this? Your customers are expecting more tailored experiences when buying decorated apparel, signage and personalized promotional products from the small to medium web store fronts. Getting the “Web to Print” toolset just right on Drupal is not easy.

Here’s just a few of the expectations for ordering printed materials from the web on Drupal:

  • Drupal integration: Full integration with existing Drupal website
  • Intuitive editor experience: Drag and drop toolset, uploading of files (jpg, png, tiff, pdf, eps, ai, psd), cropping and quick fixes to pictures, lots of fonts, pop-over text formatting, white labelled branding with plenty of customizations, low resolution upload warnings, and mobile friendly web to print tool.
  • Proof and checkout workflow: Print-quality PDF proof, edit before purchase, edit after purchase, CMYK color space, super large files that need processing
Getting off the bespoke product editor island

An example of a bespoke web to print tool Acro Media built with Drupal and jQuery UI.

Like many Drupal agencies, there’s rarely a problem we face that can’t be solved with in-house open source tools. Before we decry the problems, we are very proud of what we accomplished in the past given budget and available tools. With jQuery UI and html-to-pdf experience, we’ve built these kinds of tools before, to varying degrees of success. Every time we tackled a project like web-to-print, the struggle became very real. With minimal hours, the tools we knew and loved created a functional experience that was hard to maintain and very error prone.

More often than not, we had trouble with converting HTML to PDF reliably enough for high-resolution print-quality, especially with customer supplied imagery and layout. Offering fonts in a customized product builder is challenging to get right, especially when you’re creating a PDF that has to have the font attached. The RGB colorspace doesn’t translate easily to CMYK, the most common four color process for printing. And all of our experience in software revolved around pixels, not these things called picas. In this crazy world resolution could go as high as 3200 dpi on standard printers, dimensions suddenly couldn’t be determined based on pixels.

When one of our clients that had a tool we had built with existing technologies asked for some (not all) of the features mentioned in the beginning of the article, we also wanted to solve all the technical challenges that we grappled with over a year ago. As the planning stage was coming to an end, it was clear the budget wasn’t going to support such a complicated software build.

Product Customization is not the right phrase

Example screenshot of keditor in action.

We started to look for product customization tools and found nada. Then we looked for web layout tools which would maybe give Drupal a better HTML editing experience, but found a disappointing lack of online web to print solutions. We did find grapejs, innovastudio, and keditor

But, almost universally, these javascript-based libraries were focused on content and not editing products that would be printed. We needed something that had the goal of creating a printable image or PDF with a tight integration around the editor experience. We had nearly convinced ourselves there wasn’t a vertical for this concept, it seemed like nearly all product builders in the wild were powered by one-off conglomerations of toolsets.

Web to Print using Customer’s Canvas works with Drupal, right?

Finally, via a project manager, an industry phrase was discovered that opened the floodgates: web to print. After a bit of sifting through the sales pitch of all the technologies, almost all tools were found to be cumbersome and hard to integrate in an existing Drupal website, save one. Customer’s Canvas checked all the boxes and then some:

  • SAAS (so we don’t have to host customer’s images, or maintain the technology)
  • White label
  • More than fully featured
  • Completely customizable
  • Iframe-friendly. Meaning we could seamlessly plop the product customization tool into an existing or new layout.

Example of Customers Canvas running in Drupal Commerce.

To make an even longer story short, we jumped on board with Customer’s Canvas and built the first (to our knowledge) third party web to print Drupal 7 module. We might make a Tech Talk regarding the installation and feature set of the module. Until then, here’s what you can do:

  1. Download and install the module
  2. Provide some API credentials in the form of a javascript link
  3. Turn on the Drupal Commerce integration
  4. Provide some JSON configuration for a product via a field that gets added to your choice of product types.
  5. Click on Add to Cart for a Customer’s Canvas product
  6. Get redirected to a beautiful tool
  7. Click “Finish” and directed to a cart that can redirect you back to edit or download your product.
  8. As a store administrator, you can also edit the product from the order view page.

Drupal 8 and Web to Print and the Future

Currently, the module is built for Drupal 7. Upgrading to Drupal 8 Commerce 2 is definitely on our roadmap and should be a straightforward upgrade. Other things on the roadmap:

  • Better B2B features
    You can imagine a company needs signs for all of it’s franchisee partners and would want the ability to create stores of customizable signage. With Commerce on Drupal 8, that would be pretty straightforward to build.
  • More download options
    Customer’s Canvas supports lower res watermarked downloads for the customers as well as the high res PDF downloads. Currently the module displays the high resolution for all parties.
  • Better administrative interface
    If you’re using Drupal 7, the integration for this module is pretty easy, but the technical experience required for creating the JSON formatting for each product is pretty cumbersome. So it would be awesome (and very possible) to build out the most common customizations in an administration interface so you wouldn’t have to manage the JSON formatting for most situations.
  • Improve the architecture
    Possibly support Customer’s Canvas templates like entities that are referenced so that you could create a dozen or so customizable experiences and then link them up to thousands of products.
  • Webform support
    The base module assumes your experience at least starts with an entity that has fields and gets rendered. We could build a webform integration that would allow the webform to have a customer’s canvas build step. T-shirt design content anyone?
Integration can be a game changer

One of the big reasons we work with Drupal and Drupal Commerce is that anything with an API can be integrated. This opens the doors to allow the platform to do so much more than any other platform out there. If an integration needs to be made, we can do. If you need an integration made, talk to us! We're happy to help.

Evolving Web: Resizing Fields in Drupal 8 Without Losing Data

Main Drupal Feed - Thu, 06/14/2018 - 13:00

Drupal's field system is awesome and it is one of the reasons why I started using Drupal in the first place. However, there are some small limitations in it which surface from time to time. Say, you have a Text (Plain) field named field_one_liner which is 64 characters long. You created around 30 nodes and then you realized that the field size should have been 255. Now, if you try to do this from Drupal's field management UI, you will get a message saying:

There is data for this field in the database. The field settings can no longer be changed.

So, the only way you can resize it is after deleting the existing field! This doesn't make much sense because it's indeed possible to increase a field's size using SQL without saying goodbye to the data.

In this tutorial, we'll see how to increase the size of an existing Text (Plain) field in Drupal 8 without losing data using a hook_update_N().

Assumptions
  • You have intermediate / advanced knowledge of Drupal.
  • You know how to develop modules for Drupal.
  • You have basic knowledge of SQL.
Prerequisites

If you're going to try out the code provided in this example, make sure you have the following field on any node type:

  • Name: One-liner
  • Machine name: field_one_liner
  • Type: Text (Plain)
  • Length: 64

After you configure the field, create some nodes with some data on the One-liner field.

Note: Reducing the length of a field might result in data loss / truncation.

Implementing hook_update_N()

Reference: Custom Field Resize module on GitHub

hook_update_N() lets you run commands to update the database schema. You can create, update and delete database tables and columns using this hook after your module has been installed. To implement this hook, you need to have a custom module. For this example, I've implemented this hook in a custom module which I've named custom_field_resize. I usually name all my custom modules custom_ to namespace them. In the custom module, we implement the hook in a MODULE.install file, where MODULE is the machine-name of your module.

/** * Increase the length of "field_one_liner" to 255 characters. */ function custom_field_resize_update_8001() {}

To change the field size, there are four things we will do inside this hook.

Resize the Columns

We'll run a set of queries to update the relevant database columns.

$database = \Drupal::database(); $database->query("ALTER TABLE node__field_one_liner MODIFY field_one_liner_value VARCHAR(255)"); $database->query("ALTER TABLE node_revision__field_one_liner MODIFY field_one_liner_value VARCHAR(255)");

If revisions are disabled then the node_revision__field_one_liner table won't exist. So, you can remove the second query if your entity doesn't allow revisions.

Update Storage Schema

Resizing the columns with a query is not sufficient. Drupal maintains a record of what database schema is currently installed. If we don't do this then Drupal will think that the database schema needs to be updated because the column lengths in the database will not match the configuration storage.

$storage_key = 'node.field_schema_data.field_one_liner'; $storage_schema = \Drupal::keyValue('entity.storage_schema.sql'); $field_schema = $storage_schema->get($storage_key); $field_schema['node__field_one_liner']['fields']['field_one_liner_value']['length'] = 255; $field_schema['node_revision__field_one_liner']['fields']['field_one_liner_value']['length'] = 255; $storage_schema->set($storage_key, $field_schema);

The above code will update the key_value table to store the updated length of the field_one_liner in its configuration.

Update Field Configuration

We took care of the database schema data. However, there are other places where Drupal stores the configuration. Now, we will need to tell the Drupal config management system that the field length is 255.

// Update field configuration. $config = \Drupal::configFactory() ->getEditable('field.storage.node.field_one_liner'); $config->set('settings.max_length', 255); $config->save(TRUE);

Finally, Drupal also stores info about the actively installed configuration and schema. To refresh this, we will need to re-save the field storage configuration to make Drupal detect all our changes.

// Update field storage configuration. FieldStorageConfig::loadByName($entity_type, $field_name)->save();

After this, running drush updb or running update.php from the admin interface should detect your hook_update_N() and it should update your field size. If you're committing your configuration to git, you'll need to run drush config-export after running the database updates to update the config in the filesystem and then commit it.

Conclusion

Though we've talked about resizing a Text (Plain) or varchar field in this tutorial, we can resize any field type which can be safely resized using SQL. In certain rare scenarios, it might be necessary to create a temporary table with the new data-structure, copy the existing data into that table with queries and once all the data has been copied successfully, replace the existing table with the temporary table. For example, if you want to convert a Text (Plain) field to a Text (Long) field or some other type.

Maybe someday we'll have a resizing feature in Drupal where Drupal will intelligently allow us to increase a field's size from it's field UI and only deny reduction of field size where there is a possibility of data loss. But, in the meanwhile, we can use this handy trick to resize our fields. Thanks for reading! Please leave your comments / questions in the comments below and I'll get back to them as soon as I have time.

+ more awesome articles by Evolving Web

myDropWizard.com: CiviCRM secrets for Drupalers: Drupal 8 + CiviCRM June 2018 Update

Main Drupal Feed - Thu, 06/14/2018 - 05:15

We're Drupalers who only recently started digging deep into CiviCRM and we're finding some really cool things! This series of videos is meant to share those secrets with other Drupalers, in case they come across a project that could use them. :-)

In the screencast below, I'll demonstrate the new demo of Roundearth! Roundearth is our Drupal 8 + CiviCRM Distribution.

Watch the screencast to see the progress so far on the Roundearth project:

Video of Roundearth June 2018 Update

Some highlights from the video:

  • Drupal 8.5
  • CiviCRM + Bootstrap based Shoreditch theme
  • Quick demo of adding Contacts, using a Group, and sending a Bulk Mailing
  • Quick demo of a Public Event

Please leave a comment below!

PreviousNext: Patch Drupal core without things ending up in core/core or core/b

Main Drupal Feed - Thu, 06/14/2018 - 05:08

If you've ever patched Drupal core with Composer you may have noticed patched files can sometimes end up in the wrong place like core/core or core/b. Thankfully there's a quick fix to ensure the files make it into the correct location.

by Saul Willers / 14 June 2018

When using cweagans/composer-patches it's easy to include patches in your composer.json

"patches": { "drupal/core": { "Introduce a batch builder class to make the batch API easier to use": "https://www.drupal.org/files/issues/2018-03-21/2401797-111.patch" } }

However in certain situations patches will get applied incorrectly. This can happen when the patch is only adding new files (not altering existing files), like in the patch above. The result is the patched files end up in a subfolder core/core. If the patch is adding new files and editing existing files the new files will end up in core/b. This is because composer-patches cycle through the -p levels trying to apply them; 1, 0, 2, then 4.

Thankfully there is an easy fix!

"extra": { ... "patchLevel": { "drupal/core": "-p2" } }

Setting the patch level to p2 ensures any patch for core will get applied correctly.

Note that until composer-patches has a 1.6.5 release, specifically this PR, you'll need to use the dev release like:

"require": { ... "cweagans/composer-patches": "1.x-dev" }

The 2.x branch of composer-patches also includes this feature.

Big thanks to cweagans for this great tool and jhedstrom for helping to get this into the 1.x branch.

Tagged Drupal Development, Composer

Acro Media: Drupal Point of Sale 8 Released!

Main Drupal Feed - Thu, 06/14/2018 - 00:28
Official 8.0 Version Now Available


The Drupal Point of Sale provides a point of sale (POS) interface for Drupal Commerce, allowing in-person transactions via cash or card, returns, multiple registers and locations, and EOD reporting. It’s completely integrated with Drupal Commerce and uses the same products, customers, and orders between both systems. You can now bring your Drupal 8 online store and your physical store locations onto the same platform; maintaining a single data point.

The Drupal 7 version has been in the wild for a while now, but today marks the official, production ready release for Drupal 8.

Release Highlights

What features make up the new version of Drupal Point of Sale 8? There are so many that it will probably surprise you!

Omnichannel

Omnichannel is not just a buzzword, but a word that describes handling your online and offline stores with one platform, connecting your sales, stock and fulfillment centers in one digital location. Drupal Commerce has multi-store capabilities out of the box that allow you to create unique stores and share whatever product inventory, stock, promotions, and more between them. Drupal Point of Sale gives you the final tool you need to handle in-person transactions in a physical storefront location, all using your single Drupal Commerce platform. That’s pretty powerful stuff. Watch these videos (here and here) to learn more about how Drupal Commerce is true omnichannel.

Registers

Set up new registers with ease. Whether you have 1 or 1000 store locations, each store can have as many registers as you want. Because Drupal Point of Sale is a web-based solution, all you need to use a register is a web browser. A touch screen all-in-one computer, a laptop, an iPad; if it has a web browser, it can be your register. The Point of Sale is also fully open source, so there are no licensing fees and costs do not add up as you add more registers.

Customer Display


While a cashier is ringing through products, the Customer Display uses WebSocket technology to display the product, price, and current totals on a screen in real-time so the customer can follow along from the other side of the counter. Your customers can instantly verify everything you’re adding to the cart. All you need for the Customer Display is a web browser, so you can use an iPad, a TV or second monitor to display the information in real-time as the transaction progresses.

Barcode Scanning

Camera based barcode scanning
Don’t have a barcode scanner? No problem. With this release, any browser connected camera can be used to scan barcodes. Use a webcam, use your phone, use an iPad, whatever! If it has a camera, it works. This is helpful when you’re at an event or working a tradeshow and you don’t want to bring your hardware along.


Traditional barcode scanning
A traditional barcode scanner works too. Simply use the barcode scanner to scan the physical product’s barcode. The matching UPC code attached to one of your Drupal Commerce product variations will instantly add the product to your cashier’s display.

Labels

Generate and print labels complete with barcodes, directly from your Drupal Point of Sale interface. Labels are template based and can be easily customized to match any printer or label size so you can prep inventory or re-label goods as needed.

Receipts

Easily customize the header and footer of your receipts using the built in editor. Add your logo and contact information, return/exchange policy, special messaging or promotions, etc.

When issuing receipts, you can choose to print the receipt in a traditional fashion or go paperless and email it to your customer. You can do either, both, or none… whatever you want.

Returns

Whether online or in store, all of your orders are captured in Drupal Commerce and so can be returned, with or without the original receipt. A return can be an entire order or an individual product.

End of Day (EOD) Reports

When closing a register, you cashiers can declare their totals for the day. You can quickly see if you’re over or short. When finished, an ongoing daily report is collected that you can look back on. On top of this, Drupal Point of Sale is integrated with the core Drupal Commerce Reporting suite.

Hardware

Use Drupal POS 8 with anything that supports a browser and has an internet connection.

Technical Highlights

Adding to all of the user highlights above are a number of important technical improvements. It’s the underlying architecture that really makes Drupal Point of Sale shine.

Themable

Cashiers login to Drupal Point of Sale via a designed login page. Once logged in, the theme used is the default Drupal admin theme. However, like any other part of Drupal, your admin theme can be modified as much as you like. Keep it default or customize it to your brand; it’s yours to do with as you please.

Search API Enabled

The search API is a powerful search engine that lets you customize exactly what information is searchable. Using the Search API, your cashiers are sure to quickly find any product in your inventory by searching for a product’s title, SKU, UPC code (via barcode scanner), description, etc. Search API is completely customizable, so any additional unique search requirements can be easily added (brand, color, weight, etc.). The search API references the products on your site, and at any other store or multi-warehouse location to allow for you to serve customers in real-time. 

Fully Integrated with Drupal Commerce

The Drupal Point of Sale module seamlessly integrates into the existing Drupal Commerce systems and architecture. It shares products, stock, customers, orders, promotions and more. This makes Drupal Point of Sale plug-and-play while also making sure that the code base is maintainable and can take advantage of future Drupal Commerce features and improvements.

Permissions and Roles

When Drupal Point of Sale is installed, a “cashier” user role is created that limits the access users of this type have with your Drupal Commerce backend. Use Drupal’s fine grained permissions and roles system to manage your cashiers and give different permissions to employees, managers, marketers, owners, IT, etc. Any way you want it.

Custom Hardware

As mentioned above, all you need to use Drupal POS 8 is anything that supports a browser and has an internet connection. This opens the door for all kinds of custom Point of Sale hardware such as branded terminals, self-serve kiosks, tradeshow-ready hardware, and more.

We’ve been having fun prototyping various Raspberry Pi based POS hardware solutions. You can see some of them here and stay tuned for more. Drupal Point of Sale is open source, so why not open up the hardware too?

Drupal Point of Sale 8, Ready for your Drupal Commerce platform

We’re excited to finally release the production ready version of Drupal Point of Sale 8.0. There are many ecommerce-only platforms out there, but almost none of them can ALSO run in your physical store too. This is a BIG DEAL. Drupal Point of Sale gives you the last piece needed to run your entire store using Drupal Commerce allowing for centralized data and a single system for your team to learn and manage.

One admin login, one inventory list, one user list, one marketing platform, ONE. True omnichannel, without the fees.

Next Step

Commerce Kickstart
Starting a Drupal Commerce project from scratch? Use Commerce Kickstart to configure your install package (including Drupal Point of Sale).

Install with Composer
Already using Commerce for Drupal 8? Install Drupal Point of Sale with Composer.

$ composer require drupal/commerce_pos

Let Acro Media help
Acro Media is North America’s #1 Drupal Commerce provider. We build enterprise commerce using open source solutions. Unsure if Drupal Commerce and Drupal Point of Sale meet your business requirements? A teammate here at Acro Media would be happy to walk you through a replatforming evaluation exercise and provide you with the Point of Sale workbook to help you make your decision.

More from Acro Media

Lullabot: A Hierarchy of Software Quality

Main Drupal Feed - Wed, 06/13/2018 - 20:12

Our sales team often refers to our Hierarchy of Qualification when evaluating projects. This pyramid, inspired by Maslow’s hierarchy of needs, gives us the tools not just to evaluate the business needs of a project, but the human needs that are “encoded” in the project and team.

I’ve been thinking about how this applies to software development, particularly in the enterprise space. Enterprise implies that the software is maintained by large teams over long periods of time. Most developers have encountered internal enterprise software that leaves us shaking our heads, asking “how was this ever released?” Alternatively, we’ve used an internal tool that is quite good, but where the business has trouble repeating that success with new projects.

If we can describe the path towards self-actualizing software quality, we can elevate our teams from solving a series of one-off problems towards building value for our businesses and ourselves. It’s important to acknowledge that these steps are additive, meaning a team may benefit by mastering the lower rungs of the pyramid before moving on to the next.

undefined Describing software and how humans will use it

This is the base of the pyramid and undergirds everything else. Before writing a line of code, a team needs to have a good handle on who the audience is and how the software will affect them, along with the overall goals of the new project. Often, enterprise teams are given work to do by their customers or their management with the explanation: “a big internal department has told us this is a blocker, so don’t ask why and get to coding, so we aren’t late.”

This leaves project managers and developers in the dark, and unable to make reasonable guesses when requirements and technology conflict. Knowing the audience lets teams prioritize their work when time is short. Is the audience a group of editorial users? What’s their day-to-day workflow like? In that case, time may be best spent on testing and iterating the user interface, at the expense of implementing every last feature request. Is the audience another group of developers? Then perhaps the project doesn’t require a user interface initially, so developers can focus on great APIs and documentation. Not knowing the audience may lead to otherwise avoidable mistakes.

Like audience, project or product goals are another important piece of the puzzle. When goals are fuzzy, it is hard to know when a software project is done, or at least at a “1.0” release. Teams tend to leave projects at a nebulous “0.x” version, making future developers uncertain about the quality or robustness of a system. For example, perhaps a client asks to implement Apple News and Facebook Instant Articles on their website. It’s a reasonable request. Nevertheless, prematurely ending requirements gathering at “implement the feature” deprives your team of critical information.

There’s a business reason behind the request. Is the analytics team seeing declining traffic on their website, and worried the website audience is defecting to social networks? It may be good to suggest working on Facebook integration first, assuming you have some analytics data from existing Facebook posts to back it up. Or, perhaps the sales team is hearing from advertisers that they want to purchase ads against your content inside of the Apple News app. In that case, finding out some rough estimates for the additional ad revenue the sales team expects can help with qualifying estimates for the integration effort. If the estimated development budget eclipses the expected revenues, the team can investigate different implementation methods to bring costs down, or even rework the implementation as a one-off proof of concept.

Using audiences and goals to guide your development team makes it possible to discover opportunities beyond the immediate code, elevating the team from an “IT expense” to a “technical partner.”

Technical architecture and documentation

Writing the right software for today is one thing. Writing maintainable software that future developers can easily iterate on is another. Spaghetti architecture can leave you with software that works for now but is very expensive to maintain. For Drupal sites, that means avoiding god-objects (and services), writing true object-oriented code (and not procedural code that happens to live in classes), and avoiding side effects such as global and public variables. It’s important to document (preferably in code) not just what you built but why you built it, and how the architecture works to solve the original business problems. Think of it as writing a letter to your future self, or to whatever team inherits your code.

Determining the effort to put into this work is tricky, and time pressures can lead to quickly written, but poorly architected software. It’s useful to think about the expected life of the application. Look at similar applications in the company and ask about their initial and current development. For example, in our CMS projects, we often find we are replacing systems that are over a decade old. The code has gone through many teams of developers but is in a decrepit state as the architecture doesn’t follow common design patterns and the documentation is non-existent. No one wants to touch the existing application or infrastructure because experience has shown that may lead to a multi-day outage.

In cases like this, we know that following good design patterns and effectively documenting code will pay dividends later. A marketing site for an event in 3 months? You can probably take a lot of shortcuts without risk. Treat the project for what it is—a startup within an enterprise.

A culture of iterative feedback

Defining the software to write and following good architecture in its execution is important but we can do more. Now that our efforts are well documented, its time to create a proper harness for testing. Without one, it’s impossible to know if your team is meeting your quality goals. It’s easy for teams to fall into a fragile, untrustworthy process for testing. For sites, that typically means not defining and following deployment best practices or creating a QA bottleneck through infrastructure.

The typical git model of development implies not just a few branches that are merge destinations (like master and develop) but many feature branches, too. It’s not uncommon for developers to create multiple branches breaking a single ticket into smaller code components that can be independently reviewed and tested.

For developers, “waiting for a QA build” is one of the biggest motivation killers they face. For QA, trying to coordinate testing of various features onto a single QA server is complex and leaves them questioning the validity of their test plans.

Just as “smaller, chunkier” pull requests are a best practice for developers, a similar guideline helps QA analysts feel confident when certifying a feature or release.

Tugboat is one tool that lets teams implement automatic, lightweight, and disposable testing environments. When a developer opens a pull request, a complete working copy of the website is built and available for anyone with access to poke at. It’s easy to rebuild new testing environments because the setup is automated and repeatable—not manual. A process like this extends the effective QA team by including both developers (who can reproduce and take ownership of bugs “live” with QA, before code is merged), and the actual patrons of the build—project managers and business stakeholders—who will eventually need to sign off on the product.

These tools also change the culture of communication between stakeholders and implementation teams. Even with two-week sprints, there still can be an information gap stakeholders face between sprint planning and the sprint demo. Instead, getting their feedback is as frictionless as sending a link. There are fewer surprises at demos because stakeholders have already seen the constituent parts of the work that compose the whole demo.

Automated tests and quality metrics

Frictionless QA is great, but it’s still a manual process. It’s incredibly frustrating for an entire team to be going through manual QA for regression testing. Sometimes, regression tests uncover the sort of bugs that mean “rewrite the feature from scratch,” leading to failed sprints and missed demos. That’s especially likely when regression testing occurs at the end of a sprint, leaving precious little time for rework and another round of QA.

In contrast, developers love when automated tests alert them to issues. Not only does it save developers and QA time (they can work on a new ticket while waiting for a test suite to run), but it reduces the cognitive load of developing a new feature in a complex application. Instead of developers having to become the application experts, and maintain that knowledge in perpetuity, the automated tests themselves become the legal description of how the code should work.

Comprehensive test coverage, regardless of the actual tool used (like PHPUnit or Behat), also helps ensure that software quality remains constant as underlying dependencies are upgraded. For a Drupal site, teams should expect at least two significant upgrades of Drupal per year, along with an update to PHP itself. Automated testing means the initial work is as simple as “upgrade Drupal, run tests, and see what breaks,” instead of throwing a bunch of time and money at manual testing. It also means that testing of security patches is much faster, saving time between vulnerability disclosure and deployment.

Of course, there’s a cost to automated testing. Tests are still code that need to be maintained. Tests can be buggy themselves (like that time I accidentally tested for the current year in a string, which broke when 2018 rolled around). Someone has to pay for a continuous integration service or maintain custom infrastructure. Reducing these costs is a particular interest of ours, leading to templates like Drupal 8 CI and the Drupal Testing Container.

Again, knowing the expected life of the software you write helps to inform how deep into testing to go. I don’t think I’ve ever written automated tests for a microsite but for a multi-step payment form expected to endure for 5 years, they were critical.

Technical architecture, for all of its focus on “clean code,” can rapidly devolve into unresolvable conflicts within a team. After all, everyone has their idea of what “good design” looks like. While automated tools can’t tell you (yet) if you’re using the right design pattern to solve a given problem, they can tell you if your app is getting better or worse over time.

Start with enforcing basic code standards within your team. Code standards help team members to read code written by others, which is “step 0” in evaluating if a given codebase meets quality goals or not.

For example:

As a technical      architect, you       want reading the          code to feel as natural as             reading written text — so you            can focus on the meaning, and not       the individual words.

Think about how much harder it is to focus on the idea I’m trying to communicate. Even though you can understand it, you have to slow down and focus. Writing code without code standards sacrifices future comprehension at the altar of expediency. I’ve seen teams miss critical application bugs even though they were hiding in plain sight due to poor code formatting.

Luckily, while different projects may have different standards, they tend to be internally consistent. I compare it to reading different books with different fonts and layouts. You may have to context switch between them, but you would rarely have the paragraphs of the books interspersed with each other.

While code standards tend to either be “right” or “wrong,” code quality metrics are much more of an art than a science—at least, as far as interpreting and applying them to a project goes. I like to use PhpMetrics as it has a very nice user interface (and works perfectly within continuous integration tools). These reports inherently involve some subjective measure of what a failure is. Is the cyclomatic complexity of a method a fail at 15, or 50, or not at all? Sometimes, with difficult codebases, the goals come down to “not making things any worse.” Whatever your team decides, using these tools daily will help ensure that your team delivers the best product it can.

Continuous delivery

As a team addresses each new layer of the hierarchy, the lower layers become habits that don’t require day-to-day focus. The team can start to focus on solving business problems quickly, becoming an IT partner instead of an IT expense. Each person can fully participate in the business instead of the narrow field in front of them.

With all of these prerequisites in place, you will start to see a shift in how your team approaches application development. Instead of a conservative and fragile approach to development, your team will start to design and develop applications without fear. Many teams find themselves rotating between the bottom two levels of the pyramid. With careful planning and hard work, teams can work towards the upper tiers. The whole software delivery process—from ideas to releases to hotfixes to security releases—becomes a habit rather than a scramble every time.

Hero Image Photo by Ricardo Gomez Angel on Unsplash

Appnovation Technologies: Blazing Fast Drupal Workflow

Main Drupal Feed - Wed, 06/13/2018 - 18:34
Blazing Fast Drupal Workflow Why we need to improve our tools We are living exciting times as web developers. Nowadays, many great tools are available to develop and deploy Drupal websites. However, it is still hard to find your own way through the countless software and platforms available out there. Productivity depends on your tools and your workflow. Carefully picking softwa...

Electric Citizen: Electric Citizen Presents...

Main Drupal Feed - Wed, 06/13/2018 - 15:20

Twin Cities Drupal Camp 2018 just happened and Electric Citizen were able to present no less than four sessions on subjects ranging from Drupal search, configuration management, local development environments and dealing with emerging tech.

Just some of the folks who showed up for camp this year

Drupal Association blog: Meet the Drupal Association 2018 At-Large Board Member Candidates

Main Drupal Feed - Wed, 06/13/2018 - 12:24

Did you know you have a say in who is on the Drupal Association Board? Each year, the Drupal community votes in a member who serves two years on the board. It’s your chance to decide which community voice you want to represent you in discussions that set the strategic direction for the Drupal Association. Go here for more details.

Voting takes place from July 2 until July 13. Anyone who has a Drupal.org profile page and has logged in to their account in the last year is eligible to vote. This year, there are candidates from around the world. Now it’s time for you to meet them.

Meet The Candidates

We just concluded the phase where nine candidates nominated themselves from six different continents for the board seat. From now through July 2, we encourage you to check out each person’s candidate profile, where they explain which board discussion topics they are most passionate about and what perspectives they will bring to the board.

This year, we asked candidates to include a short video - a statement of candidacy - that summarizes why you should vote for them. Be sure to check them out. Videos are found in the candidate’s profile as well as here:

What To Consider

When reviewing the candidates, it is helpful to know what the board is focusing on over the next year or two, so you can decide who can best represent you.

Here are the key topics the board will focus on.

  • Strengthening Drupal Association’s sustainability. The board discusses how the Association can improve its financial health while expanding its mission work.

  • Understanding what the Project needs to move forward and determine how the Association can help meet those needs through Drupal.org and DrupalCon.

  • Growing Drupal adoption through our own channels and partner channels.

  • Developing the strategic direction for DrupalCon and Drupal.org.

There are certain duties that a candidate must be able to perform as a board member. The three legal obligations are duty of care, duty of loyalty, and duty of obedience. In addition to these legal obligations, there is a lot of practical work that the board undertakes. These generally fall under the fiduciary responsibilities and include:

  • overseeing Financial Performance

  • setting Strategy

  • setting and Reviewing Legal Policies

  • fundraising

  • managing the Executive Director

Hopefully providing this context gives you a helpful way to assess the candidates as you decide how to vote From July 2 until July 13.

We encourage you to ask the candidates questions. Use comments to leave a question on their candidate profile page.

Agiledrop.com Blog: AGILEDROP: Our blog posts from May

Main Drupal Feed - Wed, 06/13/2018 - 10:22
You have already seen what Drupal blogs were trending in the previous month, and now it is time to look at all our blog post we wrote. Here are the blog topics we covered in May.   The first blog post was How to Integrate Google Analytics with Drupal 8. It’s really important to keep track of the statistics of your websites. One tool that stands out and probably beats all others in terms of popularity when it comes to website analytics is Google Analytics. In this blog posts, we looked at how you can integrate Google Analytics with Drupal, specifically with Drupal 8.    The second was a … READ MORE

Droptica: Droptica: Effective software delivery? Remote SCRUM team

Main Drupal Feed - Wed, 06/13/2018 - 09:05
The deadline is today. A remote development team have worked for several weeks on your software. You obtain the long-awaited access to the system. You check it and you are not satisfied with the achieved results. All that was needed to avoid this problem is a team with experience in technology and working using SCRUM. What is SCRUM Wikipedia defines SCRUM as an agile framework for managing work. It is an approach used in many companies to develop software. Full definition can be found here https://en.wikipedia.org/wiki/Scrum SCRUM solves most of the problems arising during software development This is my opinion and many people agree with it. I have been developing commercial projects since 2008. I started as a programmer. Currently, I am supervising high-level projects.

Freelock : Freelock Named Top Web Developer in Seattle on Clutch & The Manifest!

Main Drupal Feed - Tue, 06/12/2018 - 19:30
Freelock Named Top Web Developer in Seattle on Clutch & The Manifest! Submitted by Don Dill on Tue, 06/12/2018 - 13:30

Here at Freelock, we are all in for web development. Truly, what could be more important for our clients in today's climate than a properly functioning and safe website? We are pleased to share that our expertise has paid off as we have been identified again an industry leader by Clutch. 

Agile Awards Business Client Drupal Planet feedback Project Management Quality Assurance Results

Pages