789
I Use This!
Low Activity

News

Analyzed 8 days ago. based on code collected 8 days ago.
Posted about 21 hours ago
11 Dec 2017 Thanks to Dropsolid, my first Drupal contribution sponsor Creating time and space to do the work DropSolid in Belgium are the first organisation to ... [More] sponsor some of my time to work on Drupal core. It is very liberating to set apart dedicated time for tackling bigger chunks of Drupal core work instead of sneaking in bits and pieces at the edges of the day. In the time available I was able to: Design a concept for initiative landing pages Write and build a first draft of such a landing page for the Out of the Box initiative Think through a difficult media issue and provide the feedback to unblock it Review a handful of smaller UX related issues to move them forward Many thanks to Nick Veenhof for reaching out and to DropSolid for supporting my work to help design a better Drupal! I’m open to more organisations sponsoring me to work on the ux and product side of Drupal core. If that is something you are interested in, let me know. Tags drupalplanet [Less]
Posted about 22 hours ago
November saw the Drupal Association bring us the Q2 2017 Financial state summary. We were provided with an update as to what is new on Drupal.org, this included information regarding the community page being given its own place to live, it has now been given a proper section with its own blog.
Posted 1 day ago
One of the best practices for Drupal 8 that is still emerging is how to create modules with complex deployable configuration. In the past we often abused the features module to do this, and while that continues to be an option, with Drupal 8’s vastly ... [More] improved configuration management options and the ability to install configuration easily I have been looking for something better. I particularly want to build modules that don’t have unnecessary dependencies but I can still reliably include all the needed configuration in my project. And after a few tries I think I’ve struck on an effective process. Let’s start with a quick refresher on installing configuration for a Drupal 8 module. During module installation Drupal will load any yaml files that match configuration patterns it already knows about that are included in your module’s config/install directory. In theory this is great but if you want to include configuration that comes with other modules you have to figure out what files are needed; if you want to include configuration from core modules you probably will need to find a fairly large collection files to get all the required elements. Finding all those files, and copying them quickly and easily is the challenge I set out to solve. My process starts with a local development sandbox site that is just there to support this development work, and I create a local git repository for the site’s configuration (I don’t need to connect it to a remote, like Bitbucket or GitHub, or handle all of the site’s code since it’s just to support finding changes to config files). Once installation and any base configuration is complete I export the site’s config to the directory covered by the repo (here I used d8_builder/config/sync, the site itself was at d8_builder/pub), and make sure all changes in the repository are committed: Now I create my module and a second repository just for it. The module’s repository is linked to a remote since this is the actual product I’m creating. With that plumbing in place I can to make whatever configuration change I need included in the module. Lately I’ve been creating a custom moderation workflow with several user roles and edge cases that will need to be deployed on a dozen or so sites, so you’ll see that reflected below, but this process should work for just about any project with lots of interrelated configuration. Once I have completed a set of changes, I export the site’s configuration again:  drupal config:export Now git can easily show which configuration files were changed, added, or removed: Next I use git, xargs, and cp to copy those files into your module (hat tip on this detail to Andy Gregorowicz): git ls-files -om --exclude-standard --exclude=core.extensions.yml |  xargs -I{} cp "{}" pub/modules/custom/fancy_workflow/config/install/ Notice that I skip the core.extensions.yml file. If your module had dependencies you’ll still need to update your module’s info.yml file to list them. These files are great except for one detail: they all start with the UUID for the sandbox site, which will cause break imports. So I hop into the module’s config/install directory and use sed to remove those lines: sed -i '/^uuid/d' * Now a quick commit and push of the changes to the module’s repo, and I’m ready to pull the module into other projects. I also commit the builder repo to ensure it’s easy to track any future changes. This isn’t a replacement for tools like Configuration Installer, which are designed to handle an entire site, this is intended just for module development. If you think you have a better solution, or that I’m missing something important please let me know. [Less]
Posted 2 days ago
Direct .mp3 file download. The three original hosts of the DrupalEasy Podcast, Andrew Riley, Ryan Price, and Mike Anello take a look back at episode 1 of the podcast, the last 9 years of Drupal, and what the next 5 years may bring. Discussion A ... [More] look back at DrupalEasy Podcast episode 1 - published February 17, 2009. Site of the week: Mass.gov, Acquia Engage video. DrupalEasy News Mastering Drupal Development Workflows with Pantheon - begins February 27, 2018. Sponsors Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo. WebEnabled.com - devPanel. Upcoming events Florida DrupalCamp 2018 - Orlando - February 16-18, 2018. PNW Drupal Summit - Portland - February 3-4, 2018. Call for mentors for the Diversity & Inclusion initiative Ryan mentioned - Baltimore and Chicago, Jan-May, 2018 Follow us on Twitter @drupaleasy @andrewmriley @liberatr @ultimike @tedbow @sixmiletech @akalata 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. [Less]
Posted 3 days ago
We're in the midst of a Commerce 2 build-out for a client, and a key requirement was to preserve their quantity pricing rules. With thousands of products, and different pricing rules for each one, they need the price for each item in the cart ... [More] adjusted to the appropriate price for the quantity purchased. When validating our plan for Drupal Commerce 2, we stumbled upon some examples of a custom price resolver, and knew this would work perfectly for the need. Drupal 8 Drupal Commerce Drupal Planet Field API [Less]
Posted 4 days ago
This blog has been quiet for the last year and a half, because I don’t like to announce things until I feel comfortable recommending them. Until today! Since July 2016, API-First Drupal became my primary focus, because Dries felt this was one of the ... [More] most important areas for Drupal’s future. Together with the community, I triaged the issue queue, and helped determine the most important bugs to fix and improvements to add. That’s how we ended up with REST: top priorities for Drupal … plan issues for each Drupal 8 minor: 8.2.x — results (25% of release notes issues) 8.3.x — results (10% of release notes issues) 8.4.x — results (14% of release notes issues) 8.5.x — in progress! If you want to see what’s going on, start following that last issue. Whenever there’s news, I post a new comment there. But enough background. This blog post is not an update on the entire API-First Initiative, it’s about a particular milestone. 100% integration test coverage! The biggest problem we encountered while working on rest.module, serialization.module and hal.module was unknown BC breaks 1. Because in case of a REST API, the HTTP response is the API. What is a bug fix for person X is a BC break for person Y. The existing test coverage was rather thin, and was often only testing “the happy path”: the simplest possible case. That’s why we would often accidentally introduce BC breaks. Hence the clear need for really thorough functional (integration) test coverage2, which was completed almost exactly a year ago. We added EntityResourceTestBase, which tests dozens of scenarios3 in a generic way4, and used that to test the 9 entity types, that already had some REST test coverage, more thoroughly than before. But we had to bring this to all entity types in Drupal core … and covering all 41 entity types in Drupal core was completed exactly a week ago! The test coverage revealed bugs for almost every entity type. (Most of them are fixed by now.) Tip: Subclass that base test class for your custom entity types, and easily get full REST test coverage — 41 examples available! Guaranteed to remain at 100% We added EntityResourceRestTestCoverageTest, which verifies that we have test coverage for all permutations of: entity type format: json + xml + hal_json authentication: cookie + basic_auth + anon It is now impossible to add new entity types without also adding solid REST test coverage! If you forget that test coverage, you’ll find an ASCII-art llama talking to you: Good people of #Drupal, I present unto you the greatest method of all time. https://github.com/drupal/drupal/blob/8.5.x/core/modules/rest/tests/src/Functional/EntityResource/EntityResourceRestTestCoverageTest.php#L141 pic.twitter.com/TiWLPt7duH— webcsillag (@webchick) December 8, 2017 That is why we can finally say that Drupal is really API-First! This of course doesn’t help only core’s REST module, it also helps the contributed JSON API and GraphQL modules: they’ll encounter far fewer bugs! Thanks So many people have helped! In random order: rogierbom, alexpott, harings_rob, himanshu-dixit, webflo, tedbow, xjm, yoroy, timmillwood, gaurav.kapoor, Gábor Hojtsy, brentschuddinck, Sam152, seanB, Berdir, larowlan, Yogesh Pawar, jibran, catch, sumanthkumarc, amateescu, andypost, dawehner, naveenvalecha, tstoeckler — thank you all!5 Special thanks to three people I omitted above, because they’re not well known in the Drupal community, and totally deserve the spotlight here, for their impressive contribution to making this happen: arshadcn from the U.S. — helped on loads of the test coverage issues, often posting so many patches I had trouble keeping up! vaplas from Bulgaria — helped on almost every test coverage issue, and posted an epic comment on the three most important submilestones, making everyone smile: one, two, three jamesdesq from the U.K. — helped on many of of the test coverage issues, and wrote an amazing blog post titled How I learned to stop worrying and love Drupal contribution about his experience. One of those issues was his very first core patch! That’s thirty contributors without whom this would not have happened! And of course thanks to my employer, Acquia, for allowing me to work on this full-time! Next What is going to be the next big milestone we hit? That’s impossible to say, because it depends on the chains of blocking issues that we encounter. It could be support for modifying and creating config entities, it could be support for translations, it could be that all major serialization gaps are fixed, it could be file uploads, or it could be ensuring all normalizers work in both rest.module & jsonapi.module … The future will tell, follow along! Backwards Compatibility. ↩︎ Nowhere near 100% test coverage, definitely not every possible edge case is tested, and that is fine. ↩︎ Including helpful error responses when unauthenticated, unauthorized or just a bad request. This vastly improves DX: no need to be a Drupal expert to talk to a REST API powered by Drupal! ↩︎ It is designed to be subclassed for an entity type, and then there are subclasses of that for every format + authentication combination. ↩︎ And this is just from all the per-entity type test issues, I didn’t look at the blockers and blockers of blockers. ↩︎ Acquia Drupal [Less]
Posted 4 days ago
Last week, Colan and I attended SaasNorth, a conference for Software-as-a-Service founders and investors, with a strong focus on marketing, finance and growth. To be honest, we were a little skeptical at the near total absence of technical content. ... [More] However, we were pleasantly surprised by some of the truly excellent speakers we heard. The one that had the most impact on us was April Dunford’s OBVIOUSLY AWESOME – Using context to move your customers from “What? [Less]
Posted 4 days ago
3 minutes: Starting Drupal 8 project with a composer template Jürgen Haas Fri, 12/08/2017 - 17:11 Starting a new Drupal 8 project with the LakeDrops composer template only takes less than 3 minutes. And in that short period of time you're note only getting the code base but also a number of extra benefits:
Posted 4 days ago
Topics:  Aegir Open source Drupal Planet DevOps Cloud Hosting / SaaS This ... [More] blog post has been re-published from Aegir's blog and edited with permission from its author, Christopher Gervais. My tenure with the Ægir Project only dates back about 7 or 8 years. I can’t speak first-hand about its inception and those early days. So, I’ll leave that to some of the previous core team members, many of whom are publishing blog posts of their own. New look for www.aegirproject.org As part of the run-up to Ægir’s 10-year anniversary, we built a new site for the project, which we released today. It will hopefully do more justice to Ægir’s capabilities. In addition to the re-vamped design, we added a blog section, to make it easier for the core team to communicate with the community. So keep an eye on this space for more news in the coming weeks. Ægir has come a long way in 10 years When I first tried to use Ægir (way back at version 0.3), I couldn’t even get all the way through the installation. Luckily, I happened to live in Montréal, not too far from Koumbit, which, at the time, was a hub of Ægir development. I dropped in and introduced myself to Antoine Beaupré; then one of Ægir’s lead developers. One of his first questions was how far into the installation process I’d reached. As it turns out, he frequently asked this question when approached about Ægir. It helped him gauge how serious poeple were about running it. Back then, you pretty much needed to be a sysadmin to effectively operate it. A few months, Antoine had wrapped the installation scripts in Debian packaging, making installation a breeze. By that point I was hooked. Free Software is a core value Fast forward a couple years to DrupalCon Chicago. This was a time of upheaval in the Drupal community, as Drupal 7.0 was on the cusp of release, and Development Seed had announced their intention to leave the Drupal community altogether. This had far-reaching consequences for Ægir, since Development Seed had been the primary company sponsoring development, and employing project founder and lead developer Adrian Rossouw. While in Chicago I met with Eric Gundersen, CEO of DevSeed, to talk about the future of Ægir. Whereas DevSeed had sold their flagship Drupal product, OpenAtrium, to another company, Eric was very clear that they wanted to pass on stewardship of Ægir to Koumbit, due in large part to our dedication to Free Software, and deep systems-level knowledge. Community contributions are key Since then Ægir has grown a lot. Here is one of the more interesting insights from OpenHub’s Ægir page: Very large, active development team Over the past twelve months, 35 developers contributed new code to Aegir Hosting System. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Open Hub. To help visualize all these contributions, we produced a video using Gource. It represents the efforts of no less than 136 developers over the past 10 years. It spans the various components of Aegir Core, along with “Golden” contrib and other major sub-systems. Of course, many other community members have contributed in other ways over the year. These include (but aren’t limited to) filing bug reports and testing patches, improving our documentation, answering other users’ questions on IRC, and giving presentations at local meetups. The Future The core team has been discussing options for re-architecting Ægir to modernize the codebase and address some structural issues. In the past few months, this activity has heated up. In order to simultaneously ensure ongoing maintenance of our stable product, and to simplify innovation of future ones, the core team decided to divide responsibilities across 3 branch maintainers. Herman van Rink (helmo) has taken up maintenance of our stable 3.x branch. He’s handled the majority of release engineering for the project for the past couple years, so we can be very confident in the ongoing stability and quality of Ægir 3. Jon Pugh, on the other hand, has adopted the 4.x branch, with the primary goal of de-coupling Ægir from Drush. This is driven largely by upstream decisions (in both Drupal and Drush) that would make continuing with our current approach increasingly difficult. He has made significant progress on porting Provision (Ægir’s back-end) to Symfony. Keep an eye out for further news on that front. For my part, I’m pursuing a more radical departure from our current architecture, re-writing Ægir from scratch atop Drupal 8 and Ansible with a full-featured (Celery/RabbitMQ) task queue in between. This promises to make Ægir significantly more flexible, which is being borne out in recent progress on the new system. While Ægir 5 will be a completely new code-base, the most of the workflows, security model and default interface will be familiar. Once it has proven itself, we can start pursuing other exciting options, like Kubernetes and OpenStack support. So, with 10 years behind us, the future certainly looks Bryght*. * Bryght was the company where Adrian Rossouw began work on “hostmaster” that would eventually become the Ægir Hosting System. [Less]
Posted 4 days ago
Amazee Agile Agency Survey Results - Part 5 Welcome to part five of our series, processing the results of the Amazee Agile Agency Survey. Previously I wrote about forming discovery and planning. This time let’s focus on team ... [More] communication and process. Josef Dabernig Fri, 12/08/2017 - 15:51 Team Communication When it comes to ways how to communicate, the ones that got selected with the highest rating of “mostly practised” where “Written communication in tickets”, “Written communication via (i.e. Slack)” as well as “Group meetings for the entire team”. The options that most often got selected as “Not practised” where “Written communication in blog or wiki” and “Written communication in pull requests”. For us at Amazee Labs Zurich, a variety of communication channels is essential. Regular 1-on-1 meetings between managers and their employees allow us to continuously talk about what’s important to either side and work on improvements. We communicate a lot via Slack where we have various team channels, channels together with clients related to projects, channels for work-related topics or just channels to talk about fun stuff. Each morning, we start with a short team stand-up for the entire company where we check in with each other, and that’s followed by a more in-depth standup for the Scrum teams where we talk about “What has been done, What will be done and What’s blocking us”. Written communication happens between the team and customers in Jira tickets. As part of our 4-eyes-principle peer review process, we also give feedback on code within pull requests that are used to ensure the quality of the code and train each other. Process We talked about iteration length in part 1 of this series. Now let’s look into how much time we spend on which things. According to the survey, the majority of standups take 15 minutes, followed by 5 minutes and 10 minutes with a few ones taking up to 30 minutes. This also reflects ours: we take 10 minutes for the company-wide stand up amongst 24 team members and another 15 minutes for the Scrum Team specific stand-ups. For the review-phase, teams equally often selected 2 hours and 1 hour as the top-rated option followed closely by 30 minutes. 4 hours has been chosen by a few other teams, and the last one would be one day. For the retrospectives, the top-rated option was 30 minutes, followed by 1 hour. Much fewer teams take 2 hours or even up to 4 hours for the retrospective. For planning, we saw the most significant gap regarding top rated options: 30 minutes is followed by 4 hours and then 2 hours and 1 hours were selected. In the teams I work with, we usually spend half a day doing sprint review, retrospective and planning altogether. Our reviews typically take 45 minutes, the retrospective about 1.5 hours and the planning another 30 minutes. We currently don’t do these meetings together with customers because the Scrum teams are stable teams that usually work for multiple customers. Instead, we do demos along with the clients individually outside of these meetings. Also, our plannings are quite fast because the team split up stories already in part of grooming sessions beforehand and we only estimate smaller tasks that don’t get split up later on as usually done in sprint planning 2. When looking at how much time is being spent on Client work (billable, unbillable) and Internal work we got a good variety of results. The top-rated option for “Client work (billable)” was 50-75%, “Client work (unbillable)” was usually rated below 10% and “Internal work” defaulted to 10-25%. Our internal statistics match these options that have been voted by the industry most often. I also asked about what is most important to you and your team when it comes to scheduling time? Providing value while keeping our tech debt in a reasonable place has been mentioned which is also true for us. Over the last year, we started introducing our global maintenance team which puts a dedicated focus on maintaining existing sites and keeping customer satisfaction high. By using a Kanban-approach there, we can prioritise timely critical bugs fixes when they are needed and work on maintenance-related tasks such as module updates in a coordinated way. We found it particularly helpful that the Scrum-teams are well connected with the maintenance-team to provide know-how transfer and domain-knowledge where needed. Another one mentioned, “We still need a good time tracker.” At Amazee we bill by the hour that we work so accurate time tracking is a must. We do so by using Tempo Timesheets for Jira combined with the Toggl app. How do you communicate and what processes do you follow? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us. Stay tuned for the next post where we’ll look at defining work.     [Less]