Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 2 horas 18 mins

Third & Grove: The 15 Things Your AEM Team Says Drupal Can't Do, But Can

Mié, 02/06/2019 - 10:00
The 15 Things Your AEM Team Says Drupal Can't Do, But Can justin Wed, 02/06/2019 - 07:00

ThinkShout: Fear and Loathing in Support Development

Mié, 02/06/2019 - 10:00

Consider the following exchange:

Project Manager: “Hey Joe, next week we’d like you to add some new features to [client site].”

Me: “Sure thing! Where is it hosted?”

PM: “Ah, well… we’re not really sure. We’ve asked the client. The thing is, they haven’t been able to do any work on the site for the last couple of years, because someone built the site for them and then launched it without documentation, and with no support.”

Me: *Stunned Look*

PM: “Also, they don’t use any version control. So updates will have to be done via FTP.”

Me, reeling: “I… I don’t even think I have an FTP client on my computer.”

PM: “We believe in you.”

This is a worst-case support development scenario, one likely to bring with it uncertainty and fear. However, with a methodical approach, even the worst case can be turned to your advantage.

Getting started: Docs and detective work.

The very first thing to do when you have a new support project is to find the site documentation, or failing that, create a place for new docs. You are in the best position to document the site, because you don’t have any preconceived ideas about what to do - so document everything. Future engineers (and future you) will thank you.

Starting with the site and its hosting, you can reverse-engineer pretty much anything. You can even reverse-engineer the hosting if you need to, using Robtex! (Find the host, and ask the client to reach out to them for login info).

Once you have the hosting info, you can log in and establish the following: Are they running backups? Do they use a database, and is it backed up? Do they have any version control? Is there any sort of deployment process? Do they have a staging environment?

If the answer is ‘No’ to any of the above, then it’s usually pretty easy to add/enable. Once you have a ‘Yes’ for all of the above, update the documentation, password manager, etc. For example, even if they don’t use version control, there’s nothing stopping you from adding it to your local install, and pushing that code to a (now free!) private GitHub repo.

From there, you can add user accounts for yourself, and if it’s a CMS-based website such as WordPress or Drupal, log in and start investigating the code.

Figuring out the code - locally.

It’s always a good idea to do code investigations on a local installation - any tweaks and debug code can be spotted pre-deploy and removed. Make sure you document the process of getting a local installation up and running as well! Example: letting your co-workers know that they should run the WordPress-based wp-cli command wp search-replace client-site.com client-site.localhost on a newly imported database will save them hours of frustration, as well as preventing terrible accidents from happening (WordPress will quietly redirect you to the live site after logging in if you don’t change the site URLs in the local database. Oopsie!)

Once set up locally, you can start looking for theme-layer build tips. In the root of the project, look for Composer files, (which could indicate an automated build process). A README would also be a good thing to look for - these will often be the hidden documentation for a project.

You should also look for any taskrunner files, such as those used by Gulp or Grunt, or any other files that you wouldn’t expect to see in a clean install of the CMS.

Next, find the active theme. Usually, you can inspect the website and find paths to the theme from images (WordPress), or the favicon link in the header (Drupal).

Once you’ve located (and documented) the theme location, look in the theme for taskrunners, as well as any README files. If there’s are none to be found, look for a Sass or {less} directory. Gemfiles and Rakefiles will also give hints about the type front-end preprocessors in use, and what the scope of the preprocessor is. If it’s an older site, it might still use a Compass-based framework. If there’s no preprocessor, it might be using vanilla CSS!

Once all of that is done (and documented), you can actually start finding and working on code!

Where code?

Actually finding code can be tricky - say it’s a WordPress site, and you’ve been asked to add a menu to ‘campaign’ pages across the site. How to find the template quickly?

This is where a codebase searchable IDE is handy. Sites can have tens of thousands of files, and you want to be able to narrow your search. In the case of a WordPress template, you’d limit the search to the theme directory, preferably with a *.php file extension. From there, you can look at a campaign page and look for specific classes. In our case, hero-area campaign.

Result:

Don’t be a hero - use smart search

This site had over 100,000 files! A full search could have taken several minutes instead of the 1-2 seconds it took to search the 244 PHP files in the theme.

From here, you could simply get to work and add the menu, but it can be valuable to run a codesniffer against the template. The more it deviates from the coding standard for a particular CMS, the more likely your ‘correct’ code will run into issues. In addition, if the site is ever migrated to an automated deployment environment, it will fail builds that have coding standard filters.

You can also glean a lot about the mindset of the people who built the site - were they careful and clean in their coding style? Did they document/comment code? Did they make the same style errors over and over (like a lone developer would do) or is it random (like a team)?

You can also occasionally make fun discoveries:

Me: “OK, I installed the site locally and added the menu to the campaign template. I also noticed a coding error in the ‘related content’ section that was causing it to not display.”

PM: “Really? Do they have that on other content on the site?”

Me: “Yeah, every other content type has it. I suspect it was just an error that snuck in when someone was doing a search-and-replace on the code.”

PM: “So… how many pages did that impact?”

Me: “About 500 or so. It’s been that way for at least the last three years too.”

PM: *Stunned Look*

Appnovation Technologies: Simple Website Approach Using a Headless CMS: Part 1

Mié, 02/06/2019 - 06:00
Simple Website Approach Using a Headless CMS: Part 1 I strongly believe that the path for innovation requires a mix of experimentation, sweat, and failure. Without experimenting with new solutions, new technologies, new tools, we are limiting our ability to improve, arresting our potential to be better, to be faster, and sadly ensuring that we stay rooted in systems, processes and...

Commerce Guys: Eliminating barriers to Drupal Commerce growth

Mar, 02/05/2019 - 23:52

At the end of 2018, Dries Buytaert, creator of Drupal, asked folks involved with the project to share their thoughts on what's "holding Drupal back." His prompt came on the heels of two great blog posts related to his company Acquia's growth strategy and lessons he's learned and applied from Amazon's growth strategy. I didn’t beat his third post on overcoming Drupal’s obstacles to the punch, but the series did prompt me to think long and hard about the barriers we face as maintainers and leaders of the Commerce project within the Drupal ecosystem.

For the entirety of our existence, Commerce Guys has focused on building and promoting Drupal as an eCommerce platform, first through Ubercart and then Drupal Commerce. While eCommerce is a huge industry, our reach within the community has only averaged around 5% of all Drupal sites. Given the diverse and varied types of users Drupal serves, I consider this relatively low number unsurprising. (A certain percentage will also choose to integrate third party shopping cart systems, but historically that’s always been a fraction of the number of Drupal sites using our native solutions.)

It’s tempting to be fatalistic about Drupal Commerce’s growth and accept that our growth rate will be pegged to Drupal’s own growth rate so long as our relative percentage holds. It actually is an important baseline to acknowledge - our success is tied to Drupal’s success, and so we prioritize contributing to initiatives that help improve Drupal’s core APIs, make it easier to maintain and upgrade, and attract new audiences through API-first / JavaScript initiatives. However, I think we can and should do better than just waiting for growth to happen upon us.

Why should I think we can do better?

After Dries’s posts last year I compared our usage statistics for Commerce 2.x (on Drupal 8) to our usage statistics for Commerce 1.x (on Drupal 7) at the same point in its life-cycle. What I saw convinced me we have plenty of room to grow:

  • In 2013, Drupal Commerce 1.x grew from 23,224 to 33,989 sites.
  • These numbers represent growing from 4.02% to 4.50% of all Drupal 7 sites.
  • Our average growth rate that year was 3.89% month over month; Drupal’s own growth rate was 2.72%.
  • In 2018, Drupal Commerce 2.x grew from 3,097 to 6,980 sites.
  • These numbers represent growing from 1.41% to 2.85% of all Drupal 8 sites.
  • Our average growth rate last year was 8.65% month over month; Drupal’s own growth rate was 1.23%.

Just based on those numbers, even though Commerce 2.x grew over twice as fast last year as Commerce 1.x did in a similar timeframe in its life-cycle, we still represent only half of the relative number of Drupal sites we did back then. We can double our user base on Drupal 8 without challenging our historical average representation at all. That’s good news!

Our growth rate right now is fantastic, especially compared to Drupal's own. There are likely a variety of factors at play here, but I think it boils down to some combination of recognized maturity, excellent word of mouth from a steady stream of case studies, and our contributed module ecosystem stabilizing to a point that Drupal 7 / Commerce 1.x sites are finally porting to Drupal 8 / Commerce 2.x. As our 2.x project lead recently observed, we’re now up to over 250 contributed modules on drupal.org and maintain a community support Slack channel with over 1,000 participants.

Eliminating barriers to growth in 2019

In order for us to keep up and even accelerate our rate of growth, Commerce Guys has been working hard to identify our barriers to growth and develop solutions to them. As a small team playing in a large market (against very well-funded competitors), we can only do so much … but every bit of progress on any of the following fronts will help.

1. Features and integrations

The biggest barrier to growth has historically been our under-developed contributed module and integration ecosystem. Ecosystem development is incredibly important - agencies don’t often have the expertise or confidence to develop new features or integrations themselves. Our major competitors (Magento, Shopify, et al) all have massive ecosystems that third-party software vendors take the initiative to join while our own ecosystem remains dependent on our own team or the core of our development community to expand.

2. Developer support and education

It’s tempting to point to performance and scalability as another barrier to growth, but we see poorly performing Drupal Commerce sites as a symptom of another issue - lack of exposure by the average Drupal developer to best practices for scaling sites with a large amount of authenticated (or otherwise cache-breaking) traffic. We know that we can scale Drupal Commerce to support 10,000+ transactions per hour and thousands of concurrent users, but we also know that otherwise capable Drupal teams struggle at a fraction of that scale. In other words, it’s not a capabilities gap, it’s a knowledge gap, and we’re to blame for not sharing what we've learned with our userbase.

3. Reaching our core audience

Finally, we’re hardly communicating to the market at all about why they should be choosing Drupal Commerce. Our websites are aging, and organizations who do decide upon Drupal are often confused about what sort of support, if any, we might offer them if they choose to adopt our software. We understand how our solution differs from other major players in the market and where it should be seriously evaluated (e.g. cross-border commerce, digital product sales, subscription billing), but we aren’t doing enough to demonstrate our capabilities or provide a vision for why merchants will be better off using Drupal Commerce than a competing application.

We certainly have our work cut out for us in 2019, but we’re encouraged by last year’s growth and the support of our friends and champions within the Drupal community. We believe we can work to eliminate these barriers to growth while building a sustainable business that allows us to grow without compromising our values. In reverse order, the basic roadmap we’re targeting to address those known-blockers above will be:

  1. Relaunch our company and project websites to more clearly communicate who we are, what our software can do, and how we support eCommerce teams to build with confidence on Drupal.
  2. Standardize our consulting efforts and support retainers into concrete, documented offerings that anyone can understand.
  3. Coordinate our development roadmap with more agency and technology partners to ensure essential contributed modules receive the attention they deserve and our integration roster continues to grow.

We'll be encoding our expertise into productized solutions that allow us to grow a team focused on ensuring eCommerce sites built with Drupal are optimized for stability, security, and scalability. We've always valued the impact we have on the Drupal community even as a small team, and we believe addressing these issues will afford us the opportunity to grow, broaden our impact, and grow Drupal itself as a result.

DrupalEasy: 11 Tips to start your Drupal 8 project right

Mar, 02/05/2019 - 19:55

As someone who has been building Drupal sites for over 12 years now, I'd like to think that my knowledge and expertise has grown at a rate similar to the power, flexibility, and complexity of the Drupal project itself. For well over 10 years, Drupal training and development has been the focus of my consulting business; over the holidays I took some time to look back and really think about the lessons I've learned and how I can utilize them moving forward. 

In addition to documenting the process for myself as well as my current and future clients, I also wanted to share what I've learned with the Drupal community. After all, it is this community that has made it possible for me to have the success that I have found so far. I have worked on projects of all sizes from large Fortune 500 companies to small local businesses. I’ve been alone on project as well as with large teams of developers. There have also been projects with massive budgets as well as projects with no budget. The breadth of this experience has really contributed to my ability to provide more value for my clients. 

One word I use often when speaking with current as well as prospective clients is "sustainability". I always want to be involved in a solution that provides good value not only now, but for the lifetime of the project. I want to build sites that are easy to maintain, easy to update, and easy for different developers to cycle in-and-out of. With sustainability, and all of the elements that contribute to it in mind, I present the 11 tips to start a Drupal project right. 

1. Commit to a Local->Dev-Stage->Prod developer workflow

Having a professional developer workflow should go without saying, but I often come on-board small, single-developer projects that have a remote development environment and a live environment - and nothing else. At the very least, projects of all sizes should have not only a dev and live environment, but developers should have local environments as well. 

There's a lot of focus on DevOps in the Drupal ecosystem (with good reason), but before you jump into a continuous integration/continuous development (CI/CD) system, be sure you have the basics first and then add complexity only as necessary. I've seen way too many projects invest in a full-on CI/CD system only to have it ignored because developers didn't have the time and/or expertise to utilize it properly.

2. Commit to the entire team using a project tracker

This is a bit of a pet-peeve of mine. I'm a firm believe that commitment to a project tracker must include 100% of the development team and stakeholders. Note the "and stakeholders" - this includes project managers, content and QA folks, and anyone else who has a role in the project. How often is a project ready to launch and then at the last minute a stakeholder chimes in requesting changes? This is demoralizing and frustrating for the entire development team.

Project tracker tasks should be focused. Large tasks like "theme the site" aren't very helpful and comment threads in tasks like this often become unwieldy, defeating the purpose of using a project tracker. Train the entire team on using the project tracker and committing to using it for the majority of project task communication. 

3. Utilize a remote Git repository

You're not using Git yet? Seriously? Stop reading this and go get yourself and your team trained up (we offer training). Also - commit early and often. Smaller, more focused commits (like project tasks) are easier to manage.

4. Use Composer to manage the code base

This is an article about Drupal 8, so this isn't really optional. While there is work in the community on various Composer-related projects, for now the Composer template for Drupal projects is the de-facto standard for managing your Drupal 8 project's codebase. Don't know how to use Composer? Learn it (we also offer Composer training).

5. Use consistent local development environments for development team

Avoid "it works on my machine" conversations for the rest of your life by ensuring that the entire development team is using identical local environment configurations. Docker-based solutions are tailor-made for this type of thing, but it has been possible for awhile with virtual machine-based solutions as well. A solid local development environment will pay dividends - making it easy to get new developers up-and-running, and allowing developers to focus on building the project, not monkeying around with their local environment.

I've been a fan of DDEV-Local, a Docker-based solution, for awhile - I provide training and I also wrote a book about it! 

6. Define information architecture with all stakeholders

This is where I see projects go sideways more often than not. When defining the information architecture (IA) for the site, all stakeholders must be involved. This tip really goes hand-in-hand with the next one, but the bottom line is that this needs to be a discussion. There's nothing worse than getting near the end of a project and showing it to a content author and finding out that there are gaps. Generally, the goal is to get the granularity right when defining IA. This is next to impossible to do without feedback early in the process from all stakeholders.

Review any existing content that is to be migrated to the new system, ask content authors what the issues with their current system are, and be careful not to over-engineer a solution that won't provide enough bang-for-the-buck. 

7. Prototype information architecture with content authors

This tip goes hand-in-hand with the previous one - an important part of defining the IA is testing and confirming that everything is accounted for. In my experience, the absolute best way to do this is by prototyping the system. Allow your actual content authors, editors, and admins to test-drive the new architecture by adding and editing content on a prototype of the site. This needs to be done very early in the development process, so the focus should be 100% on the add/edit forms - not the output. In fact, I recommend not putting any effort into theming the output at this point, making it crystal clear that the prototyping exercise is to confirm that the set of entities, bundles, and fields designs are on-target.

I really cannot stress enough how important this step is. IA mistakes made early that are not corrected will be a burden until they are corrected (if ever). It's normally relatively easy (and inexpensive) to fix IA mistakes early - quite the opposite if they are left to fester and other parts of the site are built upon them. I have never been part of a project where the IA prototyping didn't result in important updates to the IA. 

8. Create a style guide

If you're building a custom theme, then you probably need a style guide. Part of a solid UX/UI design is consistency in design. Consistency brings user comfort. When users are more comfortable on your site, they'll spend more time there. 

Style guides can be as simple or as complex as they need to be. At the absolute minimum, I would recommend that a style guide contain basic typography and a color palette. You'll need to consider how/if typography will change based on responsive mode (are H1s the same pixel size on mobile as they are on a desktop display?) Similarly, you'll want to think about how the header/navigation/footer respond to various screen widths as well. Have an element that appears throughout your site? Then define rules how it looks in various places and various screen widths. 

9. Create wireframes and mockups as necessary

Similarly, if your project is going to have a custom theme, then you're going to need to design the layout of key pages. How are landing pages arranged? How do they respond at various screen widths? Think about the entire site and design wireframes for a representative sample of pages. Only 2 or 3 wireframes are necessary for many projects (home page, content page, interior landing page). 

Consider these representative pages as a group, not individually. Look for common elements (easier to theme) and value consistency. If every page is a one-off, then implementation costs will rise. 

Start with wireframes and generate only the mockups you need. Often, between a solid style guide and some good wireframes, mockups aren't necessary in many cases. Think of the style guide as a box of LEGO bricks that can be assembled into mockups in various configurations. If time and budget is limited, favor the style guide over mockups.

10. Use the Configuration System

Drupal 8's configuration system provides a powerful tool to easily push non-code configuration changes between environments. The "trick" to using it is that the entire team has to understand and participate in the process. If the development team is five people, and only two are using the configuration system, you're going to have rough sledding. 

The configuration system will help enforce a solid developer workflow, encouraging team members to update and test configuration (like a new View) locally before pushing it to remote development environments. A byproduct of using the configuration system is that config changes can easily tracked by the project tracker via commit messages. 

11. Define realistic and meaningful milestones

There's not much that kills developer morale and confidence in a project more than lack of project leadership. At the core of this is often a lack of project planning and milestones. All team members should be involved in the setting of goals and milestones for the project. A single milestone of "the site must be done in 5 months" doesn't cut it. The entire team should work together to define realistic and meaningful milestones. Take into account non-project responsibilities of team members, identify and plan for potential pain points in the project. 

Project leaders need to listen to team members and provide training and professional guidance when necessary. Most developers are problem solvers who like to learn new things. Project leaders should embrace and leverage this for the betterment of their projects, the result will be a positive one for the entire team!

Mike Anello is the architect and instructor for DrupalEasy’s Drupal Career Online, which includes intensive live online sessions, rich learning resources, an active learning community and hands-on projects designed to provide those who need to get skilled up in Drupal with the best possible start. The next session of the DCO starts February 25th. If you’d like to learn more, you can sign up for a no-cost Taste of Drupal mini-webinar.

Jacob Rockowitz: Webform 8.x-5.x stable release plan

Mar, 02/05/2019 - 13:38

Looking back

Three years ago on Christmas day, I tagged the first alpha of the YAML Form module, which became the Webform module for Drupal 8. Looking back, it has been a great learning experience building and maintaining the Webform module. Looking forward, I want to make sure the Webform module is as stable as possible while still trying to smooth out any rough edges around accessibility and user experience. Everyone should feel that the Webform module is a stable, supported, and maintained part of Drupal's ecosystem of contributed modules. To help organizations and individuals understand what to expect from a stable release of the Webform module, it’s worth defining some general goals.

Setting goals

The goals of this blog post and the overall stability of the Webform module are to…

  • Define the ongoing stable release cycle.

  • Document what to expect from stable releases.

  • Encourage the growth of Webform add-ons and integrations.

Tagging releases

For the past three years, I've been tagging a new release at the beginning of each month. Frequently monthly releases were quickly followed up with a hotfix release to address unexpected regressions. Regressions happen because the Webform module is a feature-rich application with maybe not enough test coverage and definitely not enough eyeballs reviewing the code. Quality assurance is a challenge for open source projects; reviewing code for free is not as much fun as writing it. Even Drupal core needs help with improving the reliability of minor updates.

For example, Webform 8.x-5.1 was released at the...Read More

ComputerMinds.co.uk: A/B Testing with ABJS module

Mar, 02/05/2019 - 11:00

ABJS is a contrib Drupal module, and, without any requirements or ties to paid services, is as low cost as you can get. As we’ll see, it’s pretty basic but it really lets you get down to building your own understanding of how A/B testing works. The beauty of ABJS is in its simplicity. The settings pages are fairly self-explanatory, which is really helpful. Let’s set up a basic A/B test to show how things work.

Setting up our first experience

In our test, we’re going to split the site 50:50 in order to test an alternate homepage design. Go to /admin/config/user-interface/abjs and get a feel for things. See the tabs across the top? The best way to set up a new test is to work backwards. That’s because your Tests will need to reference your Conditions and Experiences - and you’ll need to create them before you can use them.

First up, create an Experience. Experiences make the actual A’s and B’s of your A/B tests. Go to the Experiences tab. Give your experience a very clear and helpful name. Our first one will be our normal homepage experience. Making a ‘normal’ experience allows us to explicitly log our page views for our analytics.

The Javascript we set up for our site looks like this:

if (typeof(ga) !== "undefined") { ga('set', 'dimension1', 'normal'); } window.Drupal = window.Drupal || { 'settings': {}, 'behaviors': {}, 'locale': {} }; window.Drupal.behaviors.abtesting = { attach: function(context, settings) { jQuery('#request-a-quote-form').on('submit', function() { ga('send', 'event','Productfinder', 'ID search', 'Homepage'); }); } }

1. We came to the Drupal Behavior format after realising that the ABJS scripts in the header would run before the Google Analytics scripts, and we would need the GA script to run before we could log our analytics. You could probably do this another way if you wanted, but this is easy enough to copy and paste for now.

2. Set our custom GA dimension.

3. This ends up happening before Drupal is actually ready to accept and execute behaviors, hence the very careful creation/copy of the window.Drupal variable.

4. Add a submit handler to our form, which will send an event to GA. This is the thing we’re trying to measure. Hopefully our alternate version of the page will result in more clicks on this button, and we’ll be able to track those in GA.

If you copy & paste the above, you'll want to make your tweaks:

1. Change the first call to ga() in line 2 to be a dimension you’ve set up in Google Analytics (Go do that now! Their support articles are really good, so I won’t explain that here).

2. Set the value for that call to be the value you want (‘normal’ may well be fine).

3. Change the event values in the final call to ga() to send the event values you want or need. They don’t need to be fancy, just unique - you just need to be able to track them in GA. Now, go create an “Alternate homepage experience” experience.

Set up your Alternate Experience

This is the Experience for the change / difference you're wanting to test.

Copy the JS from your ‘Normal’ experience, and tweak it to:

1. Have a different value for your GA dimension

2. Make an actual change to your page. Put this after the jQuery/ga call.

Now go create your condition(s).

All your experience Javascript will be added to every page, so this is where you make sure that you’re only running things where and when you really want to. Again, you write up some Javascript; it will return a Boolean value indicating to ABJS whether you want your test to be run. In our example, we’re just testing the homepage. So we’ll just do this:

return (window.location.pathname == "/");

Don't forget to set a helpful and clear name for your Condition, so it's easy to select later.


Test time!

At last, you can now go set up your Test.

1. Give your test a name. Make it helpful, so that you know which test does what when you have multiple tests later :) Perhaps name it after the change you’re making in your alternate test.

2. Select your two experiences in the two select boxes. Don’t let the fraction field confuse you - this is just the proportion of people you want to be diverted to each of your two experiences. This can be super helpful if you want, for example, to test something on a small proportion of users. For us doing our small, low-cost A/B test on our small client’s site, we want to maximise our data. So we’re doing 50:50 - this means fractions of 0.5 and 0.5 You can have multiple experiences here, which is pretty neat. So if you want to test multiple variations of your homepage, you can! Go for it!

3. Double check your Javascript :) Go execute it in the browser console or something, to make sure it works. No point taking your site down accidentally!

4. Set your test to 'Active'! This will add your tests to the site, so you can start collecting data! Now is the time to go to Google Analytics and watch the data pour in (for some definition of pour, depending on how busy your site is right now!).


Analysing your data

A key thing to remember when watching your analytics is that things change all the time, and sometimes randomness can be responsible for what you’re seeing. Or maybe there was a seasonal spike in sales which increased revenue that week, or maybe you’re not filtering your users to the right segment… A few recommendations for you:

  • Create segments for your two dimension values, so you can easily filter your data.
  • Data can be misleading. Always check other angles before declaring you’ve fixed the problem.
  • Run your numbers to check the Statistical Significance. If you don’t have tens of thousands of samples, your results may just be random chatter rather than necessarily related to the changes your Experience made. Either remember your A-Level statistics, or go use an online calculator. I recommend https://measuringu.com/statistically-significant/ for a good explainer.
  • If your site is not high traffic, you may need to run your tests for weeks or even months to get enough data to clearly show whether there's a difference. Or, it may be worth deciding that there's not clearly a difference, so it's worth testing something else.
     

     

So, we’ve created some tests with ABJS. How did it go?

Overall, ABJS is nice because it feels like you’re in control. And all developers like to feel in control. It’s also nice because if you want to go set up a test, you can! It’s easy!

Where ABJS loses out is in the pile of lovely features that the big products out there can offer. Creating, managing, scheduling and analysing are all tasks that have been made a lot easier by some off-the-shelf products. But if you can’t afford that budget, or really rather enjoy thinking things through (or indeed love a bit of statistics!) then this is your lot - and it works well enough.

Later on in the series we'll be playing with Google Analytics' A/B testing suite and seeing how it compares. Stay tuned!

CTI Digital: How do you start contributing to Drupal without code?

Mar, 02/05/2019 - 08:27

Outlets for contributing to Drupal beyond code, whilst abundant, are not always evident to those having interest to do so. I want to help people become better acquainted with ways to get involved and how to start their contribution journey. Be they completely new to Drupal or simply yet to find an outlet.

Agiledrop.com Blog: Top Drupal blog posts from January 2019

Mar, 02/05/2019 - 06:25

Just like every month, we’ve prepared a selection of the most interesting and engaging Drupal-related blog posts from the previous month. Check out January’s list and make sure you haven’t missed any!

READ MORE

Spinning Code: SCDUG November 2018

Lun, 02/04/2019 - 11:00

This fall the South Carolina Drupal User’s Group started using Zoom are part of all our meetings. Sometimes the technology has worked better than others, but when it works in our favor we are recording the presentations and sharing them when we can.

In November Kaylan Wagner gave a draft talk on using experiences in the world of online gaming to be a better remote team member.

We frequently use these presentations to practice new presentations and test out new ideas. If you want to see a polished version hunt group members out at camps and cons. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback.

If you would like to join us please check out our up coming events on Meetup for meeting times, locations, and connection information.

DrupalEasy: DrupalEasy Podcast 215 - Kaleem Clarkson - Drupal Event Organizers Working Group

Lun, 02/04/2019 - 10:00

Direct .mp3 file download.

Kaleem Clarkson, Operations Manager and Front-End Drupal Developer at Kennesaw State University and Drupal developer at blend me inc. Listen in as they discuss the newly formed Drupal Event Organizers Group and Mike breaks bad news about the Marvel Universe to Kaleem.

Discussion DrupalEasy News Upcoming Events Sponsors 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.

Matt Glaman: Testing your Drupal code base for deprecated code usage with PHPStan

Dom, 02/03/2019 - 13:14
Testing your Drupal code base for deprecated code usage with PHPStan Sunday 3, February 2019 mglaman

Last month I wrote about writing better Drupal code with static analysis using PHPStan. One of the more practical uses I saw for PHPStan and Drupal was the discovery of deprecated code usages through the phpstan/phpstan-deprecation-rules package. I had not fully tested it, until this week. 

blog.studio.gd: Drupal 8 Views Plugins (Part 2) : The display extender plugin

Dom, 02/03/2019 - 06:04
Let's see how and why to use a views display extender plugin.

blog.studio.gd: Views Plugins (Part 1) : Simple area handler plugin

Dom, 02/03/2019 - 06:04
In this series I will show you how to make use of the new Drupal 8 Plugin system, we begin with a simple example : the views area handler plugins.

blog.studio.gd: Overview of CMI in Drupal 8

Dom, 02/03/2019 - 06:04
Some notes about the new Configuration management system in Drupal 8

blog.studio.gd: Migrate to Drupal 8 from a custom site

Dom, 02/03/2019 - 06:04
Migrate is now included in the Drupal core for making the upgrade path from 6.x and 7.x versions to Drupal 8.

In this article will see how to use the Drupal migration framework to migrate custom sites to drupal 8.

blog.studio.gd: Inline Entity Display

Dom, 02/03/2019 - 06:04
Handle referenced entity fields directly in the parent entity

WeKnow: Improving Drupal and Gatsby Integration - The Gatsby Boina Starter

Vie, 02/01/2019 - 15:47
Improving Drupal and Gatsby Integration - The Gatsby Boina Starter

This is the latest post of the “Improving Drupal and Gatsby Integration” series. This time I will be talking about the Gatsby Boina Starter; we are contributing to make your Drupal-Gatsby integration easier. The Boina starter ships with the main Gatsby configuration files you might need to get up and running on your Gatsby site.

jmolivas Fri, 02/01/2019 - 17:47

OPTASY: How to Decouple Drupal Commerce to Deliver Richer Shopping Cart Experiences: Useful Modules

Vie, 02/01/2019 - 10:16
How to Decouple Drupal Commerce to Deliver Richer Shopping Cart Experiences: Useful Modules radu.simileanu Fri, 02/01/2019 - 12:16

Just imagine it: Drupal 8's robust features as a CMS, the flexible e-commerce functionality of the Drupal Commerce ecosystem and a JavaScript framework for the front-end! All in the same native mobile app! You can easily achieve this “combo” — a reliable content repository & a JS-based front-end providing a fantastic shopping cart experience — if you just... decouple Drupal Commerce.

For why should you trade Drupal's battle-tested content authoring and administration tools for a more interactive user experience? 

And why should you give up on your goal to deliver richer cart experiences just because Drupal 8 can't rival the JavaScript in terms of advanced native mobile app functionality?
 

DrupalCon News: You should stay at a DrupalCon partner hotel. Here’s why.

Vie, 02/01/2019 - 10:12

The hotels we chose each offer an ideal hub—connecting you to a rewarding DrupalCon community experience. 

Páginas