All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Let's say that you need to spin up a new Drupal environment in... minutes. To quickly test a new patch to Drupal core, maybe, or to switch between 2 or more clients on the same day and thus to run multiple copies on several websites... In this case, how about taking the quick and easy way and set up a local Drupal site with Lando?
"What is Lando?" you might legitimately ask yourself.
A DevOps tool and Docker container-based technology enabling you to spin up all the services and tools that you need to develop a new Drupal project in no time.
"Why would I choose Lando as a method to set up a local Drupal site?"
This small module implements the Scrollprogress library js to the nodes by type of content.
Activate the module and visit the administration page.
Quite a few people in the Drupal community are looking forward to see the JSON API module ship with Drupal 8 core.
- they want to use it on their projects
- the Admin UI & JS Modernization Initiative needs it
- they want to see Drupal 8 ship with a more capable RESTful HTTP API
- then Drupal will have a non-NIH (Not Invented Here) API but one that follows a widely used spec
- it enables them to build progressively decoupled components
So where are things at?Timeline
Let’s start with a high-level timeline:
- The plan (intent) to move the JSON API module into Drupal core was approved by Drupal’s product managers and a framework manager 4 months ago, on March 19, 2018!
- A core patch was posted on March 29 (issue #2843147). My colleague Gabe and I had already been working full time for a few months at that point to make the JSON API modules more stable: several security releases, much test coverage and so on.
- Some reviews followed, but mostly the issue (#2843147) just sat there. Anybody was free to provide feedback. We encouraged people to review, test and criticize the JSON API contrib module. People did: another 1000 sites started using JSON API! Rather than commenting on the core issue, they filed issues against the JSON API contrib module!
- Since December 2017, Gabe and I were still working on it full time, and e0ipso whenever his day job/free time allowed. Thanks to the test coverage Gabe and I had been adding, bugs were being fixed much faster than new ones were reported — and more often than not we found (long-existing) bugs before they were reported.
- Then 1.5 week ago, on June 28, we released JSON API 1.22, the final JSON API 1.x release. That same day, we branched the 2.x version. More about that below.
- The next day, on June 29, an updated core patch was posted. All feedback had been addressed!
I wrote in my comment:
Time to get this going again. Since #55, here’s what happened:
- Latest release at #55: JSON API 1.14
- Latest release today: JSON API 1.22
- 69 commits: ($ git log --oneline --since "March 30 2018 14:21 CET" | wc -l)
- Comprehensive test coverage completed (#2953318: Comprehensive JSON API integration test coverage phase 4: collections, filtering and sorting + #2953321: Comprehensive JSON API integration test coverage phase 5: nested includes and sparse field sets + #2972808: Comprehensive JSON API integration test coverage phase 6: POST/PATCH/DELETE of relationships)
- Getting the test coverage to that point revealed some security vulnerabilities (1.16), and many before it (1.14, 1.10 …)
- Ported many of the core REST improvements in the past 1.5 years to JSON API (1.15)
- Many, many, many bugfixes, and much, much clean-up for future maintainability (1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22)
That’s a lot, isn’t it? :)
But there’s more! All of the above happened on the 8.x-1.x branch. As described in #2952293: Branch next major: version 2, requiring Drupal core >=8.5 (and mentioned in #61), we have many reasons to start a 8.x-2.x branch. (That branch was created months ago, but we kept them identical for months.)
Why wait so long? Because we wanted all >6000 JSON API users to be able to gently migrate from JSON API 1.x (on Drupal ⇐8.5) to JSON API 2.x (on Drupal >=8.5). And what better way to do that than to write comprehensive test coverage, and fixing all known problems that that surfaced? That’s what we’ve been doing the past few months! This massively reduces the risk of adding JSON API to Drupal core. We outlined a plan of must-have issues before going into Drupal core: #2931785: The path for JSON API to core — and they’re all DONE as of today! Dozens of bugs have been flushed out and fixed before they ever entered core. Important: in the past 6–8 weeks we’ve noticed a steep drop in the number of bug reports and support requests that have been filed against the JSON API module!
After having been tasked with maturing core’s REST API, and finding the less-than-great state that was in when Drupal 8 shipped, and having experienced how hard it is to improve it or even just fix bugs, this was a hard requirement for me. I hope it gives core committers the same feeling of relief as it gives me, to see that JSON API will on day one be in much better shape.
The other reason why it’s in much better shape, is that the JSON API module now has no API surface other than the HTTP API! No PHP API (its sole API was dropped in the 2.x branch: #2982210: Move EntityToJsonApi service to JSON API Extras) at all, only the HTTP API as specified by http://jsonapi.org/format/.
TL;DR: JSON API in contrib today is more stable, more reliable, more feature-rich than core’s REST API. And it does so while strongly complying with the JSON API spec: it’s far less of a Drupalism than core’s REST API.
So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch!
EDIT: P.S.: 668K bytes of the 1.0M of bytes that this patch contains are for test coverage. That’s 2/3rds!
To which e0ipso replied:So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch! So much pride! This was a long journey, that I walked (almost) alone for a couple of years. Then @Wim Leers and @gabesullice joined and carried this to the finish line. Such a beautiful collaboration!
Then, about 12 hours ago, core release manager xjm and core framework manager effulgentsia posted a comment:(@effulgentsia and @xjm co-authored this comment.) It’s really awesome to see the progress here on JSON API! @xjm and @effulgentsia discussed this with other core committers (@webchick, @Dries, @larowlan, @catch) and with the JSON API module maintainers. Based on what we learned in these discussions, we’ve decided to target this issue for an early feature in 8.7 rather than 8.6. Therefore, we will will set it 8.7 in a few days when we branch 8.7. Reviews and comments are still welcome in the meantime, whether in this issue, or as individual issues in the jsonapi issue queue. Feel free to stop reading this comment here, or continue reading if you want to know why it’s being bumped to 8.7. First, we want to give a huge applause for everything that everyone working on the jsonapi contrib module has done. In the last 3-4 months alone (since 8.5.0 was released and #44 was written):
- Over 100 issues in the contrib project have been closed.
- There are currently only 36 open issues, only 7 of which are bug reports.
- Per #62, the remaining bug fixes require breaking backwards compatibility for users of the 1.x module, so a final 1.x release has been released, and new features and BC-breaking bug fixes are now happening in the 2.x branch.
- Also per #62, an amazing amount of test coverage has been written and correspondingly there’s been a drop in new bug reports and support requests getting filed.
- The module is now extremely well-documented, both in the API documentation and in the Drupal.org handbook.
- We generally prefer to commit significant new core features early in the release cycle for the minor, rather than toward the end. This means that this month and the next couple are the best time to commit 8.7.x features.
- To minimize the disruption to contrib, API consumers, and sites of moving a stable module from core to contrib, we’d like to have it as a stable module in 8.7.0, rather than an experimental module in 8.6.0.
- Per above, we’re not yet done breaking BC. The mentioned spec compliance issues still need more work.
- While we’re still potentially evolving the API, it’s helpful to continue having the module in contrib for faster iteration and feedback.
- Since the 2.x branch of JSON API was just branched, there are virtually no sites using it yet (only 23 as compared with the 6000 using 1.x). An alpha release of JSON API 2.x once we’re ready will give us some quick real-world testing of the final API that we’re targeting for core.
- While the module has reached maturity in contrib, we still need the final reviews and signoffs for the core patch. Given the quality of the contrib module this should go well, but it is a 1 MB patch (with 668K of tests, but that still means 300K+ of code to review.) :) We want to give our review of this code the attention it deserves.
So there you have it. JSON API will not be shipping in Drupal 8.6 this fall.
The primary reason being that it’s preferred for significant new core features to land early in the release cycle, especially ones shipping as stable from the start. This also gives the Admin UI & JS Modernization Initiative more time to actually exercise many parts of JSON API’s capabilities, and in doing so validate that it’s sufficiently capable to power it.
For us as JSON API module maintainers, it keeps things easier for a little while longer: once it’s in core, it’ll be harder to iterate: more process, slower test runs, commits can only happen by core committers and not by JSON API maintainers. Ideally, we’d commit JSON API to Drupal core with zero remaining bugs and tasks, with only feature requests being left. Good news: we’re almost there already: most open issues are feature requests!
For you as JSON API users, not much changes. Just keep using https://www.drupal.org/project/jsonapi. The 2.x branch introduced some breaking changes to better comply with the JSON API spec, and also received a few new small features. But we worked hard to make sure that disruption is minimal (example 1 2 3).1
Use it, try to break it, report bugs. I’m confident you’ll have to try hard to find bugs … and yes, that’s a challenge to y’all!
If you want to stay on 1.x, you can — and it’s rock solid thanks to the test coverage we added. That’s the reason we waited so long to work on the 2.x branch: because we wanted the thousands of JSON API sites to be in the best state possible, not be left behind. Additionally, the comprehensive test coverage we added in 1.x guarantees we’re aware of even subtle BC breaks in 2.x! ↩︎
This module provides a form element on each block to set the cache metadata(Context, Tags, Max-Age).
"Og Share Content" is a Drupal module that enables the user to share content between Organic Groups. All group members can share content within that group. Users can be members of multiple groups. The "Share Content" button will be displayed in the "Node Links" of the node.INSTALLATION
Install as you would normally install a contributed Drupal module. See: https://Drupal.org/documentation/install/modules-themes/modules-7 for further information.
If you have been to any of the North American Drupal Camps, chances are you recognize Amber Matz. She is the production manager and a trainer at Drupalize.Me. Drupalize.Me is a site for Drupal tutorials and trainings. Amber, along with Joe Shindelar, travel to the various Drupal Camps and DrupalCons and currently run Drupal 8 Theming workshops.
"Executives promised us that they wanted us to speak up about the ugly things, the harmful things, and that we wouldn't be punished for doing so," fired ArenaNet staffer Jessica Price tells Polygon. ...
This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.
During my DrupalCon Nashville keynote, I shared a brief video of Mike Lamb, the Senior Director of Architecture, Engineering & Development at Pfizer. Today, I wanted to share an extended version of my interview with Mike, where he explains why the development team at Pfizer has ingrained Open Source contribution into the way they work.
Mike had some really interesting and important things to share, including:
- Why Pfizer has chosen to standardize all of its sites on Drupal (from 0:00 to 03:19). Proprietary software isn't a match.
- Why Pfizer only works with agencies and vendors that contribute back to Drupal (from 03:19 to 06:25). Yes, you read that correctly; Pfizer requires that its agency partners contribute to Open Source!
- Why Pfizer doesn't fork Drupal modules (from 06:25 to 07:27). It's all about security.
- Why Pfizer decided to contribute to the Drupal 8's Workflow Initiative, and what they have learned from working with the Drupal community (from 07:27 to 10:06).
- How to convince a large organization (like Pfizer) to contribute back to Drupal (from 10:06 to 12:07).
Between Pfizer's direct contributions to Drupal (e.g. the Drupal 8 Workflow Initiative) and the mandate for its agency partners to contribute code back to Drupal, Pfizer's impact on the Drupal community is invaluable. It's measured in the millions of dollars per year. Just imagine what would happen to Drupal if ten other large organizations adopted Pfizer's contribution models?
Most organizations use Open Source, and don't think twice about it. However, we're starting to see more and more organizations not just use Open Source, but actively contribute to it. Open source offers organizations a completely different way of working, and fosters an innovation model that is not possible with proprietary solutions. Pfizer is a leading example of how organizations are starting to challenge the prevailing model and benefit from contributing to Open Source. Thanks for changing the status quo, Mike!
This module adds a field formatter that expands and collapses to obscure content that is longer than desired. It is similar in principle to Expanding Formatter, but operates in a different manner. Rather than trimming based on a number of characters, this module uses a specific height to trim the text. This results in a predictable layout every time.
Nexon and EA have ended development on the team-up project that would've brought an entirely online Titanfall game to Asian markets. ...
Amelia Zins from Facebook Audience Network takes a deeper view into the field of app bidding, which is causing app publishers and game developers to pause and take notice. ...