Subscribe to Drupal News feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 8 hours 42 min ago

Amazee Labs: Drupal HackCamp Bucharest

Tue, 06/19/2018 - 08:29
Drupal HackCamp Bucharest

Only a month has passed since DrupalCamp Transylvania, and already another Drupal Camp has come and gone in Romania. This time it was Drupal HackCamp, organised in the Romanian capital, Bucharest. It was a Drupal Camp with a very specific theme: Security.

 

Vasi Chindris Tue, 06/19/2018 - 14:29

Throughout the sessions presented at the Camp, one was able to find out what security issues Drupal had experienced in the past, how the Drupal Security team, as well as the Community in general, had dealt with them, what Drupal did to improve the security of the platforms that were developed using the CMS and what can (and should) be done to have a more secure application.

Since I first heard of it, a Camp focused on Drupal security sounded really interesting to me. This is the type of camp every Drupal developer should attend at least once in their career. Actually any web developer for that matter. As we know, security is a very important topic with regards to the web. Even for experienced developers, some things can be very tricky, as an application's security does not only depend on the code. It also depends on how the web server is configured or what kind of third-party libraries your code depends on. Additionally, it also depends on the libraries you are using in development, if they are used to pack or bundle your code, or if they end up touching your code in any other way.

One of the sessions which focused on how Drupal improved its security with each new version, was Peter Wolanin's - 10 Ways Drupal 8 Is More Secure.

In this session, Peter Wolanin first gave a brief introduction to the OWASP Top 10, a list with the top 10 critical security risks that affect a web application. This is not only Drupal related, it applies to any kind of application that is accessible via the web. Next, he pointed out 10 things Drupal 8 implemented that help the developer to avoid those security risks. Among the points he mentioned were, the autoescaping feature implemented in twig (so now everything which gets outputted by twig, is by default, escaped), the automatic CSRF tokens in the route definitions (making it easier for the developer to create links which are valid only for the current user session), the removal of the PHP input filter (which was very dangerous if misused), and the enforcement of trusted host patterns for requests (so that your application will respond only if requested via a host which you actually trust).

As previously mentioned, having a secure app doesn't guarantee that your Drupal is secure. Nowadays, there is a growing interest in having decoupled apps. This means you have a backend which is usually used for content management only (that can be a Drupal site) and a frontend, which is a modern js application, that can be implemented optionally, using a framework like React, Vue.js, and so on. But then you also need to use npm for installing the additional js libraries you need, webpack for creating the javascript bundles for your app, and babel for transpiling your javascript code. So suddenly you start to introduce a ton of other dependencies, which each depend on a lot of other packages. Alexandru Badiu did a presentation called, “JS and Security”, which covered some of those aspects.

So, you do the best you can to write secure code, try to evaluate the dependencies of your project, and make sure that they don't introduce critical security issues, but is that enough? There could still be several security issues which you’re unaware of, which will only be discovered while you are using the application. It would be awesome if we're able to do something to proactively protect us against common security risks.

Bastian Widmer (@dasrecht) presented a talk on this subject, entitled “How Open Source will help you to survive the next Drupalgeddon”, where he showed us a few tips that we can use in advance, in order to respond to potential security issues in future. Besides ensuring you do regular updates for all your app’s dependencies, you could also take some measures at the web server level. For example, only allow index.php to be executed, use a web application firewall or make sure that your operating system is configured properly.

Of course, there had to be a session about the last Drupalgeddon(s), at a Camp focusing on Security. The event’s keynote was by Jasper Mattsson, who actually discovered Drupalgeddon 2. He shared some tips with us on how to find security breaches. He said that there is no secret 'recipe' for that, but a good starting point, is to look for functions which output data, which can do multiple things, perhaps depending on how they are invoked (in which context or with which parameters) or which can trigger code execution.

There is one very important thing to keep in mind if you discover a security breach: do not post it on the regular Drupal issue queue. Instead, follow the instructions on how to report a security issue when you found one. The implications of reporting a security issue inside the regular Drupal issue queue can be very dangerous, as the attackers will then have plenty of time to create an attack until the issue is fixed.

Being in a city with such a rich history, we could certainly not miss the walking tour that the organisers had prepared for us on the Saturday afternoon. During the tour, we saw Bucharest’s most iconic buildings, which have survived all the great historical periods over the last 200 years - the monarchy, two world wars, communism and now democracy.

Drupal HackCamp Bucharest was a really great event, and I hope it takes place next year. It is of great value to all web developers, especially those at the beginning of their careers, as it prepares them for the dangers of the wild world wide web and equips them with the required knowledge to guard against any that may pop up along the way.

ADCI Solutions: Drupal modules for a university website

Tue, 06/19/2018 - 06:44

A website for a university always needs a lot of functionality because of a heavy amount of data managed there. Here you will find the list of Drupal modules which allow you to add new features to any Drupal university website.

Check them out

Appnovation Technologies: Content Creation: White Paper Wisdom

Tue, 06/19/2018 - 03:00
Content Creation: White Paper Wisdom For any online writer, the white paper is a valuable arrow in the content creation quiver. Depending on the subject matter structures necessarily differ, both in terms of the content itself as well as the overall construction of the material.  That said, writing a white paper is also subject to some fairly universal guidelines, many of which I...

mark.ie: PatternLab: Your Clients Don't Need a Science Lesson

Mon, 06/18/2018 - 16:24
PatternLab: Your Clients Don't Need a Science Lesson

Let's revisit my recent post and see if we can come up with more user-friendly names for PatternLab items.

markconroy Mon, 06/18/2018 - 21:24

My Approach to PatternLab recently got quite an amount of discussion on Slack and other places about PatternLab and naming conventions, especially the line "Clients do not want a science lesson". In that I set out my current naming convention like so:

  • Basic Elements
  • Site Blocks
  • Building Blocks
  • Content
  • Sample Pages

While generally appreciated, some people criticised it for being too Drupal-centred. What happens if your client doesn't want to use Drupal? What happens if you want to use the same PatternLab instance for an app on Android or iOS? Good questions, and they got me thinking more. A number of people on Slack recently have been asking about what naming conventions besides the atoms > molecules > organisms one people have been using.

I had a verrrrry long chat (over 3 hours) with some developers from outside of my work place to see what what naming convention(s) might make sense, be easy for clients to understand, and allow enough scale to be used outside of Drupal. Here's what we came up with:

  • Utilities
    • Items such as utility classes like .visually-hidden or .padding-top
  • Base
    • Items such as colours and fonts
  • Elements
    • Low level elements such as headings, paragraphs, basic lists
  • Components
    • High definition components such as a teaser view mode, an embedded video component, a list of teasers
  • Layouts
    • General layout classes for the different page designs - with sidebar, without sidebar, etc
  • Mock-ups
    • Rendered 'pages' or other UI interfaces
    • We shied away from 'Pages' here because not everything might be a page, such as a login screen on an iPhone app

I'm quite happy with those naming conventions and think I might start porting some of them to my work at Annertech. (Oh, and by the way, if you want to get really good Drupal developers to work on your website, we're available for hire - contact us!)

 

Hook 42: Being Drupal Adjacent

Mon, 06/18/2018 - 10:05
What It Means to be Drupal Adjacent

One of the major objectives of Drupal 8 is the desire to “get off the island.” Drupal opened its doors to using and contributing to a broader ecosystem of projects instead of replicating functionality in Drupal. We now see tools like Twig and various Symfony components in Core. Contributed modules are also able to integrate projects and Software Development Kits (SDKs). For example, Password Strength, Digital Ocean, and Hubspot API integrate through Drupal’s native use of Composer. This philosophy helps those of us that more closely identify as “Drupal Adjacent.”

I consider being “Drupal Adjacent” as having some degree of experience in Drupal but maintaining expertise in a breadth of other technology. You are capable of leveraging Drupal’s strengths along with the strengths of other tools. Drupal Adjacent architects use “the right tool for the right job.” Drupal can serve as a bi-directional tool or framework in a broader architecture of systems and other tools can serve a discrete purpose.

As I consider myself Drupal Adjacent, I want to share my experience working in the Drupal community.

Axelerant Blog: Enterprise Digital Transformation (DX) + Outsourcing

Mon, 06/18/2018 - 09:05

Can you outsource Digital Transformation (DX)?

Let's set this off in the right direction. What people think digital transformation is, often isn’t. Adopting the latest feature is not digital transformation, and neither is a basic migration or new functional enhancements made to a site.

DrupalEasy: DrupalEasy Podcast 210 - Stefanie Gray - DKAN Open Data Platform

Mon, 06/18/2018 - 07:26

Direct .mp3 file download.

Stefanie Gray, (stefaniegray), Engineer and Open Data Specialist for CivicActions joins Mike Anello to discuss all things DKAN.

Interview DrupalEasy News News Sponsors
  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.
Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Drupal Europe: Community at Drupal Europe

Mon, 06/18/2018 - 04:52
Amazee labs @flickr

Drupal Europe brings a unique opportunity to connect, share and learn from the Drupal community and to talk about what holds us together. We grew to be the biggest open source community under the tagline “Come for the code and stay for the community” which we strive to uphold.

Join us on September 10–14, 2018 in Darmstadt, Germany to discuss and learn about growing and strengthening communities and the challenges that come with that.

Drupal has been a historic example of how Open Source communities can thrive and to maintain this leading position we need to learn from each other, include others and inspire everybody to be an active contributor. This might bring its challenges from time to time, so please come and share your stories, expertise and lessons learned with us. This is the only way to keep our community strong, diverse and open minded.

Who should attend?

You! This vertical topic will be the meeting place for everyone in Drupal and other communities.

Whether you want to organise events, you’re new to the community and want to know where you can get involved, or you want to share a success story from your community, you are welcome.

Target groups:

  • Members of the Drupal community
  • Other open source communities
  • Organisations and those interested in how communities work and prosper

Example talks:

  • Being Human
  • Challenges of contribution
  • Community help
  • Community retention
  • Growing leaders & influencers (by empowering, enabling and adding trust)
  • Growing the Drupal Community
  • Improving diversity
  • Mentorship, sponsorship and allies
  • Organizing events
  • Succession planning for organizers and leaders

As you’ve probably read in one of our previous blog posts, industry verticals are a new concept being introduced at Drupal Europe and replace the summits, which typically took place on Monday. At Drupal Europe. These industry verticals are integrated with the rest of the conference — same location, same ticket and provide more opportunities to learn and exchange within the industry verticals throughout three days.

Industry vertical icons by @sixeleven

Now is the perfect time to buy your ticket for Drupal Europe. Session submission is already open so please submit your sessions and encourage others who have great ideas.

Please help us to spread the word about this awesome conference. Our hashtag is #drupaleurope.

To recommend speakers or topics please get in touch at program@drupaleurope.org.

About Drupal Europe Conference

Drupal is one of the leading open source technologies empowering digital solutions in the government space around the world.

Drupal Europe 2018 brings over 2,000 creators, innovators, and users of digital technologies from all over Europe and the rest of the world together for three days of intense and inspiring interaction.

Location & Dates

Drupal Europe will be held in Darmstadtium in Darmstadt, Germany — which has a direct connection to Frankfurt International Airport. Drupal Europe will take place 10–14 September 2018 with Drupal contribution opportunities every day. Keynotes, sessions, workshops and BoFs will be from Tuesday to Thursday.

Amazee Labs: So, you want to run a Drupal Camp. Here's what you should know.

Mon, 06/18/2018 - 04:18
So, you want to run a Drupal Camp. Here's what you should know.

I’ve been running events since college, for work and for fun, and for groups of 3 to 3,000. You’d think there’d be a difference, but the amount of energy it takes to run an event, surprisingly, is the same. It’s crazy how well these things scale.

Stephanie El-Hajj Mon, 06/18/2018 - 10:18

Regardless of size, an event planner goes through a very predictable flow from event conception to event end.

We started planning Texas Camp in September of 2017. Knowing we were going to organize the event again for 2018, we scrambled to finalize the venue and update the sticker. By the time BADCamp rolled around, we had shiny new Texas Camp stickers to distribute at the nation’s largest gathering of Drupal people - all potential camp attendees.  

Because we knew when companies do their budget planning, we were ready with a brand new sponsor prospectus by December. By the second week, a cheerful call to sponsor was in many Drupal company inboxes.  

We worked to get the bestie launched in January, so attendees could plan ahead and to get everyone excited. Let me tell you this when building a spankin’ new React + Drupal site, plan for extra time.

By the time we did launch in February, we had missed a few big camps, but still had plenty of time to get the word out on the call for sessions.

From February to April, we worked hard to get the word out about all the different ways people could get involved with camp. Sponsorship, speaking, volunteering, or simply just attending. Early-bird tickets were on sale and the sessions submissions were trickling in.

Texas Camp organizers attended DrupalCon Nashville and spread the good word of Texas Camp to anyone who would spare a few minutes. Those who promised to submit sessions were gifted a Texas Camp sticker, along with lavish promises of fame and glory.

Because we want Texas Camp to be known as an inclusive camp, we reached out to different groups, including the Drupal Diversity and Inclusion group, to help get the word out to a broader, and more diverse, audience. I’d like to think our efforts here helped us pick up more diverse speakers than we might have gotten through our usual channels.

At the end of April, the craziness began. Although I am a seasoned session selection overseer, this was my first time actively participating in the selection as a team. It’s not an easy task, not just considering the length of time it takes to read sessions!

We had a few mandates: no repeat speakers, diverse topics, variety in experience levels, and oh yeah, the selection was done fully blind to the presenter. All personally identifiable information (pronouns, speaker names, company names, etc) was all painstakingly struck from the submission pile.

At the end of the two-week selection process, the team gathered and made the final selection. Some speakers with multiple sessions had been ranked high enough to make the session cut, so the better of the two, or the session with most topical conflict with other highly ranked sessions, were made into backups.

After session selection, things started moving really fast. We had one week to confirm speakers and another week to make a schedule. Once that newsletter went out announcing the final schedule, the official countdown to Texas Camp had begun.

Week 4: Guess what you’ll need and order everything. This gives you enough time to re-order if anything goes wrong. It’s too early for real attendance numbers, so any amount you order is the best guess.

Week 3: Things will start to arrive. Your office will be filled with an insane number of soda flats and bizarre equipment. We had a silver 4-foot metal trough we had to explain on a few client calls. Speakers will begin canceling. New sponsors will appear out of the woodwork - which is a GREAT thing. Last minute sponsors allowed us to blow the budget on breakfast tacos!

Week 2: You’ve printed everything you can think to print and pray the sizes match and the colors turn out right. The final “Texas Camp is next week!” notice has gone out to attendees. Speakers are thoroughly annoyed at the number of reminders to RSVP we’ve sent.

Week 1: The blessed “eye of the storm”. The week before the event. It’s too late to do anything meaningful. All you can do is hope you’ve done enough ahead of time and remembered everything. Especially if the week of ends in a 3-day weekend for Memorial Day. An unexplained spike in registrations. It looks like we’ll hit 150!

The week of: It’s time for final inventory audits, calling and confirming with all the venues and updating catering counts with vendors. Always add more vegan meals than you have data for! Rally the organizing team and caravan the soda flats and registration supplies to the venue.

Make eye contact and remind each other that you can do it and that there will be coffee in the morning. Charge the iPads. Remember to print the special diet food tents for the morning.  

During camp: Have a stupid amount of fun. See people you haven’t seen in a year. Celebrate the CMS that drew us all together. So many people, at Texas Camp we nearly hit 200! Eat an inordinate amount of food. Watch some amazing talks. Sing karaoke.

After camp: Go home. Swear to never do it again. Take a vacation. Get a sunburn. Reconsider.

The week after camp: Begin researching venues for the next year.  

PreviousNext: How to create and expose computed properties to the REST API in Drupal 8

Mon, 06/18/2018 - 00:51

In Drupal 8.5.0, the "processed" property of text fields is available in REST which means that REST apps can render the HTML output of a textarea without worrying about the filter formats.

In this post, I will show you how you can add your own processed fields to be output via the REST API.

by Jibran Ijaz / 18 June 2018

The "processed" property mentioned above is what is known as a computed property on the textarea field.

The ability to make the computed properties available for the REST API like this can be very helpful. For example, when the user inputs the raw value and Drupal performs some complex logical operations on it before showing the output.

Drupal fieldable entities can also have computed properties and those properties can also be exposed via REST. I used the following solution to expose the data of an entity field which takes raw data from the users and perform some complex calculations on it.

First of all, we need to write hook_entity_bundle_field_info to add the property and because it is a computed field we don't need to implement hook_entity_field_storage_info.


<?php // my_module/my_module.module /** * @file * Module file for my_module. */ use Drupal\my_module\FieldStorageDefinition; use Drupal\my_module\Plugin\Field\MyComputedItemList /** * Implements hook_entity_bundle_field_info(). */ function my_module_entity_bundle_field_info(EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) { $fields = []; // Add a property only to nodes of the 'my_bundle' bundle. if ($entity_type->id() === 'node' && $bundle === 'my_bundle') { // It is not a basefield so we need a custom field storage definition see // https://www.drupal.org/project/drupal/issues/2346347#comment-12206126 $fields['my_computed_property'] = FieldStorageDefinition::create('string') ->setLabel(t('My computed property')) ->setDescription(t('This is my computed property.')) ->setComputed(TRUE) ->setClass(MyComputedItemList::class) ->setReadOnly(FALSE) ->setInternal(FALSE) ->setDisplayOptions('view', [ 'label' => 'hidden', 'region' => 'hidden', 'weight' => -5, ]) ->setDisplayOptions('form', [ 'label' => 'hidden', 'region' => 'hidden', 'weight' => -5, ]) ->setTargetEntityTypeId($entity_type->id()) ->setTargetBundle($bundle) ->setName('my_computed_property') ->setDisplayConfigurable('form', FALSE) ->setDisplayConfigurable('view', FALSE); } return $fields; }

Then we need the MyComputedItemList class to perform some magic. This class will allow us to set the computed field value.


<?php // my_module/src/Plugin/Field/MyComputedItemList.php namespace Drupal\my_module\Plugin\Field; use Drupal\Core\Field\FieldItemList; use Drupal\Core\TypedData\ComputedItemListTrait; /** * My computed item list class. */ class MyComputedItemList extends FieldItemList { use ComputedItemListTrait; /** * {@inheritdoc} */ protected function computeValue() { $entity = $this->getEntity(); if ($entity->getEntityTypeId() !== 'node' || $entity->bundle() !== 'my_bundle' || $entity->my_some_other_field->isEmpty()) { return; } $some_string = some_magic($entity->my_some_other_field); $this->list[0] = $this->createItem(0, $some_string); }

The field we add is not a base field so we can't use \Drupal\Core\Field\BaseFieldDefinition. There is an open core issue to address that https://www.drupal.org/project/drupal/issues/2346347 but in tests there is a workaround using a copy of \Drupal\entity_test\FieldStorageDefinition:


<?php // my_module/src/FieldStorageDefinition.php namespace Drupal\my_module; use Drupal\Core\Field\BaseFieldDefinition; /** * A custom field storage definition class. * * For convenience we extend from BaseFieldDefinition although this should not * implement FieldDefinitionInterface. * * @todo Provide and make use of a proper FieldStorageDefinition class instead: * https://www.drupal.org/node/2280639. */ class FieldStorageDefinition extends BaseFieldDefinition { /** * {@inheritdoc} */ public function isBaseField() { return FALSE; } }

Last but not least we need to announce our property definition to the entity system so that it can keep track of it. As it is an existing bundle we can write an update hook. Otherwise, we'd need to implement hook_entity_bundle_create.


<?php // my_module/my_module.install /** * @file * Install file for my module. */ use Drupal\my_module\FieldStorageDefinition; use Drupal\my_module\Plugin\Field\MyComputedItemList; /** * Adds my computed property. */ function my_module_update_8001() { $fields['my_computed_property'] = FieldStorageDefinition::create('string') ->setLabel(t('My computed property')) ->setDescription(t('This is my computed property.')) ->setComputed(TRUE) ->setClass(MyComputedItemList::class) ->setReadOnly(FALSE) ->setInternal(FALSE) ->setDisplayOptions('view', [ 'label' => 'hidden', 'region' => 'hidden', 'weight' => -5, ]) ->setDisplayOptions('form', [ 'label' => 'hidden', 'region' => 'hidden', 'weight' => -5, ]) ->setTargetEntityTypeId('node') ->setTargetBundle('my_bundle') ->setName('my_computed_property') ->setDisplayConfigurable('form', FALSE) ->setDisplayConfigurable('view', FALSE); // Notify the storage about the new field. \Drupal::service('field_definition.listener')->onFieldDefinitionCreate($fields['my_computed_property']); }

The beauty of this solution is that I don't have to write a custom serializer to normalize the output. Drupal Typed Data API is doing all the heavy lifting.

Related Drupal core issues: Tagged jsonapi, REST, XML, JSON, hal_json, Normalizers

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

Sun, 06/17/2018 - 18: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

Fri, 06/15/2018 - 15: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

Fri, 06/15/2018 - 11: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

Fri, 06/15/2018 - 10: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!

Agiledrop.com Blog: AGILEDROP: Introduction to Drupal Commerce

Thu, 06/14/2018 - 19: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

Thu, 06/14/2018 - 18: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

Thu, 06/14/2018 - 10: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

Thu, 06/14/2018 - 09: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

Thu, 06/14/2018 - 01: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

Thu, 06/14/2018 - 01: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

Pages