Drupal

Drupal Association blog: It's Time To Vote - Community Elections 2018

Planet Drupal - 2 July 2018 - 2:00am

Voting is now open for the 2018 At-Large Board positions for the Drupal Association!  If you haven't yet, check out the candidate profiles including their short videos found on the profile pages. Get to know your candidates, and then get ready to vote.

Cast Your Vote!

How does voting work? Voting is open to all individuals who have a Drupal.org account by the time nominations open and who have logged in at least once in the past year.

To vote, you will rank candidates in order of your preference (1st, 2nd, 3rd, etc.). The results will be calculated using an "instant runoff" method. For an accessible explanation of how instant runoff vote tabulation works, see videos linked in this discussion.

Election voting will be held from 2 July, 2018 through 13 July, 2018. During this period, you can continue to review and comment on the candidate profiles.

Have questions? Please contact me: Rachel Lawson.

Categories: Drupal

Gizra.com: Using JSON API with WebdriverIO Tests

Planet Drupal - 1 July 2018 - 9:00pm

In Drupal, you can write automated tests with different levels of complexity. If you need to test a single function, or method of a class, probably you will be fine with a unit test. When you need to interact with the database, you can create kernel tests. And finally, if you need access to the final HTML rendered by the browser, or play with some javascript, you can use functional tests or Javascript tests. You can read more about this in the Drupal.org documentation.

So far this is what Drupal provides out of the box. On top of that, you can use Behat or WebDriver tests. This types of tests are usually easier to write and are closer to the user needs. As a side point, they are usually slower than the previous methods.

The Problem.

In Gizra, we use WebdriverIO for most of our tests. This allow us to tests useful things that add value to our clients. But these sort of tests, where you only interact with the browser output, has some disadvantages.

Imagine you want to create an article and check that this node is unpublished by default. How do you check this? Remember you only have the browser output…

One possible way could be this: Login, visit the Article creation form, fill the fields, click submit, and then… Maybe search for some unpublished class in the html:

var assert = require('assert'); describe('create article', function() { it('should be possible to create articles, unpublished by default', function() { browser.loginAs('some user'); browser.url('http://example.com/node/add/article') browser.setValueSafe('#edit-title-0-value', 'My new article'); browser.setWysiwygValue('edit-body-0-value', 'My new article body text'); browser.click('#edit-submit'); browser.waitForVisible('.node-unpublished'); }); });

This is quite simple to understand, but it has some drawbacks.

For one, it depends on the theme to get the status of the node. You could take another approach and instead of looking for a .node-unpublished class, you could logout from the current session and then try to visit the url to look for an access denied legend.

Getting Low-Level Information from a Browser Test

So the problem boils down to this:

How can I get information about internal properties from a browser test?

The new age of decoupled Drupal brings an answer to this question. It could be a bit counterintuitive at first, therefore just try to see is fit for your project.

The idea is to use the new modules that expose Drupal internals, through json endpoints, and use javascript together with a high-level testing framework to get the info you need.

In Gizra we use WDIO tests write end-to-end tests. We have some articles about this topic. We also wrote about a new module called JsonAPI that exposes all the information you need to enrich your tests.

The previous test could be rewritten into a different test. By making use of the JsonAPI module, you can get the status of a specific node by parsing a JSON document:

var assert = require('assert'); describe('create article', function() { it('should be possible to create articles, unpublished by default', function() { browser.loginAs('some user'); browser.url('http://example.com/node/add/article') browser.setValueSafe('#edit-title-0-value', 'My unique title'); browser.setWysiwygValue('edit-body-0-value', 'My new article body text'); browser.click('#edit-submit'); // Use JSON api to get the internal data of a node. let query = '/jsonapi/node/article' += '?fields[node--article]=status' += '&filter[status]=0' += '&filter[node-title][condition][path]=title' += '&filter[node-title][condition][value]=My unique title' += '&filter[node-title][condition][operator]=CONTAINS' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); assert.ok(json[0].id); assert.equals(false, json[0].attributes.content['status']); }); });

In case you skipped the code, don’t worry, it’s quite simple to understand, let’s analyze it:

1. Create the node as usual:

This is the same as before:

browser.url('http://example.com/node/add/article') browser.setValueSafe('#edit-title-0-value', 'My unique title'); browser.setWysiwygValue('edit-body-0-value', 'My new article body text'); browser.click('#edit-submit'); 2. Ask JsonAPI for the status of an article with a specific title:

Here you see the two parts of the request and the parsing of the data.

let query = '/jsonapi/node/article' += '?fields[node--article]=status' += '&filter[status]=0' += '&filter[node-title][condition][path]=title' += '&filter[node-title][condition][value]=My unique title' += '&filter[node-title][condition][operator]=CONTAINS' browser.url(query); 3. Make assertions based on the data:

Since JsonAPI exposes, well, json data, you can convert the json into a javascript object and then use the dot notation to access to a specific level.

This is how you can identify a section of a json document. browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); assert.ok(json[0].id); assert.equals(false, json[0].attributes.content['status']); A Few Enhancements

As you can see, you can parse the output of a json request directly from the browser.

browser.url('/jsonapi/node/article'); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false));

The json object now contains the entire response from JsonAPI that you can use as part of your test.

There are some drawbacks of the previous approach. First, this only works for Chrome. That includes the Json response inside a XML document. This is the reason why you need to get the HTML from body pre.

The other problem is this somewhat cryptic section:

let query = '/jsonapi/node/article' += '?fields[node--article]=status' += '&filter[status]=0' += '&filter[node-title][condition][path]=title' += '&filter[node-title][condition][value]=My unique title' += '&filter[node-title][condition][operator]=CONTAINS'

The first problem can be fixed using a conditional to check which type of browser are you using to run the tests.

The second problem can be addressed using the d8-jsonapi-querystring package, that allows you to write an object that is automatically converted into a query string.

Other Use Cases

So far, we used JsonAPI to get information about a node. But there are other things that you can get from this API. Since all configurations are exposed, you could check if some role have some specific permission. To make tests shorter we skipped the describe and it sections.

browser.loginAs('some user'); let query = '/jsonapi/user_role/user_role' += '?filter[is_admin]=null' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); json.forEach(function(role) { assert.ok(role.attributes.permissions.indexOf("bypass node access") == -1); });

Or if a field is available in some content type, but it is hidden to the end user:

browser.loginAs('some user'); let query = '/jsonapi/entity_form_display/entity_form_display?filter[bundle]=article' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); assert.ok(json[0].attributes.hidden.field_country);

Or if some specific HTML tag is allowed in an input format:

let query = '/jsonapi/filter_format/filter_format?filter[format]=filtered_html' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); let tag = '<drupal-entity data-*>'; assert.ok(json[0].attributes.filters.filter_html.settings.allowed_html.indexOf(tag) > -1);

As you can see, there are several use cases. The benefits of being able to explore the API by just clicking the different links sometimes make this much easier to write than a kernel test.

Just remember that this type of tests are a bit slower to run, since they require a full Drupal instance running. But if you have some continuous integration in place, it could be an interesting approach to try. At least for some specific tests.

We have found this quite useful, for example, to check that a node can be referenced by another in a reference field. To check this, you need the node ids of all the nodes created by the tests.

A tweet by @skyredwang could be accurate to close this post.

Remember how cool Views have been since Drupal 4.6? #JSONAPI module by @e0ipso is the new "Views".

— Jingsheng Wang (@skyredwang) January 9, 2018

Continue reading…

Categories: Drupal

FZ Test

New Drupal Modules - 1 July 2018 - 2:05pm
Origin

A wanted to make a little module to help the Drupal development

Features

There are functions:
fz_t(variable name) - to write out the value of variable (array also)

fz_die() - The same than fz_t() + die();
fz_mem() - shows only the memory using
fz_q() - wuery testing

Categories: Drupal

FZ Teszt

New Drupal Modules - 1 July 2018 - 1:59pm
Origin

A wanted to make a little module to help the Drupal development

Features

There are functions:
fz_t(variable name) - to write out the value of variable (array also)

fz_die() - The same than fz_t() + die();
fz_mem() - shows only the memory using
fz_q() - wuery testing

Categories: Drupal

Wim Leers: Shipping the right thing

Planet Drupal - 30 June 2018 - 5:03pm

Two weeks ago, I stumbled upon a two-part blog post by Alex Russell, titled Effective Standards Work.

The first part (The Lay Of The Land) sets the stage. The second part (Threading the Needle) attempts to draw conclusions.

It’s worth reading if you’re interested in how Drupal is developed, or in how any consensus-driven open source project works (rather than the increasingly common “controlled by a single corporate entity” “open source”).

It’s written with empathy, modesty and honesty. It shows the struggle of somebody given the task and opportunity to help shape/improve the developer experience of many, but not necessarily the resources to make it happen. I’m grateful he posted it, because something like this is not easy to write nor publish — which he also says himself:

I’ve been drafting and re-drafting versions of this post for almost 4 years. In that time I’ve promised a dozen or more people that I had a post in process that talked about these issues, but for some of the reasons I cited at the beginning, it has never seemed a good time to hit “Publish”. To those folks, my apologies for the delay.

Parallels!

I hope you’ll find the incredibly many parallels with the open source Drupal ecosystem as fascinating as I did!

Below, I’ve picked out some of the most interesting statements and replaced only a few terms, and tadaaa! — it’s accurately describing observations in the Drupal world!

Go read those two blog posts first before reading my observations though! You’ll find some that I didn’t. Then come back here and see which ones I see, having been a Drupal contributor for >11 years and a paid full-time Drupal core contributor for >6.

Standards Theory

Design A new Drupal contrib module is the process of trying to address a problem with a new feature. Standardisation Moving a contributed module into Drupal core is the process of documenting consensus.

The process of feature design Drupal contrib module development is a messy, exciting exploration embarked upon from a place of trust and hope. It requires folks who have problems (web developers site builders) and the people who can solve them (browser engineers Drupal core/contrib developers) to have wide-ranging conversations.

The Forces at Play

Feature Drupal module design starts by exploring problems without knowing the answers, whereas participation in Working Groups Drupal core initiatives entails sifting a set of proposed solutions and integrating the best proposals competing Drupal modules. Late-stage iteration can happen there, but every change made without developer site builder feedback is dangerous — and Working Groups Drupal core initiatives aren’t set up to collect or prioritise it.

A sure way for a browser engineer Drupal core/contrib developer to attract kudos is to make existing content Drupal sites work better, thereby directly improving things for users site builders who choose your browser Drupal module.

Essential Ingredients
  • Participation by web developers site builders and browser engineers Drupal core/contrib developers: Nothing good happens without both groups at the table.
  • A venue outside a chartered Working Group Drupal core in which to design and iterate: Pre-determined outcomes rarely yield new insights and approaches. Long-term relationships of WG participants Drupal core developers can also be toxic to new ideas. Nobody takes their first tap-dancing lessons under Broadway’s big lights. Start small and nimble, build from there.
  • A path towards eventual standardisation stability & maintainability: Care must be taken to ensure that IP obligations API & data model stability can be met the future, even if the loose, early group isn’t concerned with a strict IP policy update path
  • Face-to-face deliberation: I’ve never witnessed early design work go well without in-person collaboration. At a minimum, it bootstraps the human relationships necessary to jointly explore alternatives.

    If you’ve never been to a functioning standards Drupal core meeting, it’s easy to imagine languid intellectual salons wherein brilliant ideas spring forth unbidden and perfect consensus is forged in a blinding flash. Nothing could be further from the real experience. Instead, the time available to cover updates and get into nuances of proposed changes can easily eat all of the scheduled time. And this is expensive time! Even when participants don’t have to travel to meet, high-profile groups Drupal core contributors are comically busy. Recall that the most in-demand members of the group Drupal core initiative (chairs Drupal core initiative coordinators, engineers from the most consequential firms Drupal agencies) are doing this as a part-time commitment. Standards work is time away from the day-job, so making the time and expense count matters.
Design → Iterate → Ship & Standardise

What I’ve learned over the past decade trying to evolving the web platform is a frustratingly short list given the amount of pain involved in extracting each insight:

  • Do early design work in small, invested groups
  • Design in the open, but away from the bright lights of the big stage
  • Iterate furiously early on because once it’s in the web Drupal core, it’s forever
  • Prioritize plausible interoperability; if an implementer says “that can’t work”, believe them!
  • Ship to a limited audience using experimental Drupal core modules as soon as possible to get feedback
  • Drive standards stabilization of experimental Drupal core modules with evidence and developer feedback from those iterations
  • Prioritise interop minimally viable APIs & evolvability over perfect specs APIs & data models; tests create compatibility stability as much or more than tight prose or perfect IDL APIs
  • Dot “i”s and cross “t”s; chartered Working Groups Drupal core initiatives and wide review many site builders trying experimental core modules are important ways to improve your design later in the game. These derive from our overriding goal: ship the right thing.

    So how can you shape the future of the platform as a web developer site builder?

The first thing to understand is that browser engineers Drupal core/contrib developers want to solve important problems, but they might not know which problems are worth their time. Making progress with implementers site builders is often a function of helping them understand the positive impact of solving a problem. They don’t feel it, so you may need to sell it!

Building this understanding is a social process. Available, objective evidence can be an important tool, but so are stories. Getting these in front of a sympathetic audience within a browser team of Drupal core committers or Drupal contrib module maintainers is perhaps harder.

It has gotten ever easier to stay engaged as designs experimental Drupal core modules iterate. After initial meetings, early designs are sketched up and frequently posted to GitHub Drupal.org issues where you can provide comments.

“Ship The Right Thing”

These relatively new opportunities for participation outside formal processes have been intentionally constructed to give developers and evidence a larger role in the design process.

There’s a meta-critique of formal standards processes in Drupal core and the defacto-exclusionary processes used to create them. This series didn’t deal in it deeply because doing so would require a long digression into the laws surrounding anti-trust and competition. Suffice to say, I have a deep personal interest in bringing more voices into developing the future of the web platform, and the changes to Chrome’s Drupal core’s approach to standards adding new modules discussed above have been made with an explicit eye towards broader diversity, inclusion, and a greater role for evidence.

I hope you enjoyed Alex’ blog posts as much as I did!

Categories: Drupal

Stepping up my photography to make a cookbook

Dries Buytaert - 30 June 2018 - 3:52pm

We're going on a two-week vacation in August! Believe it or not, but I haven't taken a two week vacation in 11 years. I'm super excited.

Now our vacation is booked, I'm starting to make plans for how to spend our time. Other than spending time with family, going on hikes, and reading a book or two, I'd love to take some steps towards food photography. Why food photography?

The past couple of years, Vanessa and I have talked about making a cookbook. In our many travels around the world, we've eaten a lot of great food, and Vanessa has managed to replicate and perfect a few of these recipes: the salmon soup we ate in Finland when we went dog sledding, the hummus with charred cauliflower we had at DrupalCon New Orleans, or the tordelli lucchesi we ate on vacation in Tuscany.

Other than being her sous-chef (dishwasher, really), my job would be to capture the recipes with photos, figure out a way to publish them online (I know just the way), and eventually print the recipes in a physical book. Making a cookbook is a fun way to align our different hobbies; travel for both of us, cooking for her, photography for me, and of course enjoying the great food.

Based on the limited research I've done, food photography is all about lighting. I've been passionate about photography for a long time, but I haven't really dug into the use of light yet.

Our upcoming vacation seems like the perfect time to learn about lighting; read a book about it, and try different lighting techniques (front lighting, side lighting, back lighting but also hard, soft and diffused light).

The next few weeks, I plan to pick up some new gear like a light diffuser, light modifiers, and maybe even a LED light. If you're into food photography, or into lighting more generally, don't hesitate to leave some tips and tricks in the comments.

Categories: Drupal

Conditional Modes

New Drupal Modules - 30 June 2018 - 3:01pm

Selects default form or display modes based on conditions.

Categories: Drupal

Larry Garfield: PHP: Use associative arrays basically never

Planet Drupal - 30 June 2018 - 1:59pm
PHP: Use associative arrays basically never

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

Continue reading this post on Steemit

Larry 30 June 2018 - 4:59pm
Categories: Drupal

Value

New Drupal Modules - 30 June 2018 - 1:00pm

The goal of the value module is to make field values easily accessible inside Twig templates.

Categories: Drupal

Websocket

New Drupal Modules - 30 June 2018 - 9:47am

Real time chat via sockets based on Ratchet.

Categories: Drupal

Server IP

New Drupal Modules - 30 June 2018 - 2:00am

Server IP is a simple module it will display the ip address of the server. Nowadays most of the sites using the cloud servers with more than one IP address for different region for the same site.It will be helpful for developers to debug the IP address of cloud server that contains more than one ip address for single site.

Developers can also view the below details for easily debugging :

Categories: Drupal

Social Post Weibo

New Drupal Modules - 29 June 2018 - 10:53pm

原文事情详细地址:http://hunterphp.com/public/bad
项目测试结果公开:http://hunterphp.com/public/test/result

这是兑现承诺分享出来的模块! 我不想再了为了那个狗逼解释什么,他要是公开更多聊天记录出来更好,反正我删了他,记录也找不回来了,不要相信我们额外描述的,看真实聊天记录,自辨是非! 就这样的功能,6000给你做出来了,能用了,你在中国找谁给你这个价。 全程尽心尽力给你做出来了!你自己是不是也测了满意了,如果不是后面一摧再摧,很明显感觉到你就是不想要了,想毁约了的态度,我至于撕破脸吗?不说了,翻篇了,我不想再让这事影响我的心情,哥还要去学音乐呢!后会无期!历史青鉴!

另外,告诉你,你不要就算了,哥自己做成免费的自媒体运营平台系统 (基于HunterPHP),让你后悔去吧!

Categories: Drupal

Drupal blog: Design 4 Drupal: The future of JavaScript in Drupal

Planet Drupal - 29 June 2018 - 7:59am

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

Today, I gave a keynote presentation at the 10th annual Design 4 Drupal conference at MIT. I talked about the past, present and future of JavaScript, and how this evolution reinforces Drupal's commitment to be API-first, not API-only. I also included behind-the-scene insights into the Drupal community's administration UI and JavaScript modernization initiative, and why this approach presents an exciting future for JavaScript in Drupal.

If you are interested in viewing my keynote, you can download a copy of my slides (256 MB).

Thank you to Design 4 Drupal for having me and happy 10th anniversary!

Categories: Drupal

Drupixels: Progressive Web App (PWA) integration with Drupal

Planet Drupal - 29 June 2018 - 5:41am
A Progressive Web App (PWA) is a web app that uses modern web capabilities to deliver an app-like experience to users by combining features offered by most modern browsers with the benefits of mobile experience. Integration of PWA with Drupal makes Drupal inherit the latest web technologies and harness devices capabilities.
Categories: Drupal

Page menu reorder

New Drupal Modules - 29 June 2018 - 4:01am

Page menu reorder module helps to rearrange menu links of a page. A new reorder tab is added onto a page if the page has menu links. It works similar to Drupal 7 version of submenu reorder module (https://www.drupal.org/project/submenu_reorder) but this module is developed in Drupal 8.

Normally we reorder the menu links on the menu administration page admin/structure/menu/manage/main. But it’s not so easier for a large site with thousands of menu links. This module helps to overcome the issues.

Categories: Drupal

Axelerant Blog: Axelerant At Drupal Developer Days Lisbon 2018

Planet Drupal - 29 June 2018 - 3:16am


Drupal Developer Days brings together people who contribute to the progress of Drupal from around the world. There are code sprints, workshops, sessions, BoFs, after parties (and after-after parties) and more.

Categories: Drupal

Design 4 Drupal: The future of JavaScript in Drupal

Dries Buytaert - 28 June 2018 - 4:44pm

Today, I gave a keynote presentation at the 10th annual Design 4 Drupal conference at MIT. I talked about the past, present and future of JavaScript, and how this evolution reinforces Drupal's commitment to be API-first, not API-only. I also included behind-the-scene insights into the Drupal community's administration UI and JavaScript modernization initiative, and why this approach presents an exciting future for JavaScript in Drupal.

If you are interested in viewing my keynote, you can download a copy of my slides (256 MB).

Thank you to Design 4 Drupal for having me and happy 10th anniversary!

Categories: Drupal

Dries Buytaert: Design 4 Drupal: The future of JavaScript in Drupal

Planet Drupal - 28 June 2018 - 4:44pm

Today, I gave a keynote presentation at the 10th annual Design 4 Drupal conference at MIT. I talked about the past, present and future of JavaScript, and how this evolution reinforces Drupal's commitment to be API-first, not API-only. I also included behind-the-scene insights into the Drupal community's administration UI and JavaScript modernization initiative, and why this approach presents an exciting future for JavaScript in Drupal.

If you are interested in viewing my keynote, you can download a copy of my slides (256 MB).

Thank you to Design 4 Drupal for having me and happy 10th anniversary!

Categories: Drupal

Angie "webchick" Byron: An update on Drupal 8.6 pre-feature freeze

Planet Drupal - 28 June 2018 - 1:52pm

Greetings, folks! As we head into feature freeze for Drupal 8.6 (the week of July 18), here's a run-down of the various initiatives, and a hit-list of what they're trying to accomplish in the next two weeks. Patch reviews, testing, design, docs, and many more skills are very welcomed!

A couple of caveats here:

1) This is my own personal best understanding of where this stuff is all at, based on reading issue comments, attending meetings, overhearing things from other people who attended meetings, catching the odd Slack snippet of conversation, carrier piegon, etc. And therefore may not be 100% accurate, or even 80% accurate — there's a lot going on! (please clarify in the comments if you see any errors/omissions)
2) Just because something is listed here, there is absolutely no guarantee that it gets reviewed + (truly) RTBCed + committed in time for feature freeze and makes it into 8.6. As you can see, there are lots of issues in the list below, and we're all doing our best to stay on top of them. Worst-case, there's always 8.7. :)
3) This post gets into nitty-gritty "technical audience" details; if you're interested in a more broad overview of initiatives and their aims for 8.6 and beyond, there's the strategic initiatives overview on Drupal.org. I was also recently on a Lullbabot podcast to that effect.

OK, here we go! These are listed in alphabetical order.

Admin UI & JavaScript Modernization

This initiative has some lofty goals indeed, to redesign Drupal's admin experience, and modernize the underlying JavaScript code in Drupal to meet modern standards/best practices. While there's a ton of work actively going on in these areas right now, most of the fruit won't bear until 8.7 or later. If you're planning/able to go, come join the sprint next week at Drupal Developer Days Lisbon!

For 8.6, one of the big accomplishments of this initiative was introducing Nightwatch.js testing framework to core, which allows us to test JavaScript code with (wait for it)... JavaScript (what a concept!). This will be critical in ensuring that the React-ified components work as expected, and our existing JavaScript-rich functionality continues to work solidly as we expand on dynamic functionality in the UI.

Here are the issues this team has surfaced as important for 8.6:

Make Nightwatch testing more generally useful
  • Add login/logout commands to nightwatch [#2973879]
  • Create nightwatch command to install modules [#2974619]
Fix long-standing issues in the JavaScript system

Seriously, check out the five-digit node IDs on these bad boys! :P

  • ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs [#736066]
  • Provide a common API for displaying JavaScript messages [#77245]
Bring JS code up to modern standards
  • Use Prettier for formatting core JavaScript [#2978964]
API-First

This team's 8.6 goals are two-fold: 1) stabilizing and filling gaps in the existing REST API, and 2) attempting to add JSON API to core.

TONS of work has been going on in the JSON API contributed module queue to fix a number of outstanding issues to make it core-worthy. So even if this module doesn't make it in time for 8.6, the entire ecosystem will benefit throughout 8.6's lifecycle by using a much more robust and well-tested contributed module. Additionally, a long-standing gap of file upload support has been added. Huzzah!

For the remainder of 8.6, the team would like to focus on the following:

Unblockers to API-First in general
  • Add DateTimeNormalizer+TimestampNormalizer, deprecate TimestampItemNormalizer: @DataType-level normalizers are reusable by JSON API [#2926508]
  • @DataType=map cannot be normalized, affects @FieldType=link, @FieldType=map [#2895532]
Unblockers to REST
  • EntityResource should add _entity_access requirement to REST routes [#2869426]
  • PATCHing entities validates the entire entity, also unmodified fields, so unmodified fields can throw validation errors [#2821077]
Unblockers to JSON API

These are all issues in the JSON API contrib module, which help unblock "Add experimental JSON API module [#2843147]" for core.

  • [PP-1] Work around core's ill-designed @FieldType-level TimestampItemNormalizer normalization until #2926508 lands [#2929932]
  • JSON API indicates it supports POST/PATCH/DELETE of config entity types, but that's impossible [#2887313]
  • Needs Issue: Module name conflict between contrib/core (what happens when we bring a same-named contrib module to core that sites are actively using?)
  • [>=8.5] Remove JSON API's "file URL" field work-around now that Drupal core 8.5 fixed it [#2926463] - Fixed!
Automatic Updates / Composer in Core

These two initiatives overlap in that we're aiming to build the automatic update functionality around improving core's underlying Composer support.

The Composer team has compiled an excellent plan of attack for how to provide Composer support without jeopardizing the site builder experience. Most of that work will take place in 8.7.

However, one of the pre-requisites for Composer to work well, is adding semantic versioning support for contrib. Support for this would also be tremendously helpful to contrib module authors and site builders, regardless if they use Composer to manage their dependencies or not.

Unblockers to semver for contrib
  • Core version key in module's .info.yml doesn't respect core semantic versioning [#2313917]
  • Module version dependency in .info.yml is ineffective for patch releases [#2641658]
Configuration Management 2.0

This team spent most of the 8.6 cycle forming, brainstorming a list of blockers to configuration awesomeness, and prioritizing those efforts. The hope is for a roadmap to get published after the sprint next week at Drupal Developer Days Lisbon.

One major win in 8.6 is the ability to Allow a site-specific profile to be installed from existing config, which is part of the aim to Allow a site to be installed from existing configuration (basically, moving the capabilities of the Config Installer module into core.)

Unblockers of install from existing configuration
  • Install a site from config if the config directory is set in settings.php [#2980670]
Documentation

The Documentation initiative has a lot on the go right now, from designing a top-level landing page for the new docs system, to taking a holistic look at the existing docs and how to refactor the IA around them, and finally creating a repository around "quick start" guides. None of these have a particular deadline around 8.6, because they're happening independently of core.

On the core side, there's work being done on a new experimental module for overhauling the in-app help system and this work has an 8.6 deadline.

New topic-based core help system
  • Refactor using a plugin system [#2961552]
  • Add experimental module for Help Topics [#2920309]
Extended Security Support

For the plan around this initiative to happen, we need to make several adjustments to core's Update Status module, which currently makes several hard-coded assumptions about the last minor release of Drupal expiring immediately once a new minor release is available.

Update Status Improvements
  • If the next minor version of core has a security release, status still says "Security update required!" even if the site is on an equivalent, secure release already [#2804155]
  • Status report should indicate next minor release date (needs issue)
  • (other issues TBD)
Layout

The Layout team has been hard at work improving upon the experimental Layout Builder functionality that was added to 8.5. The main goal of the team for 8.6 is to gather real-world testing feedback from end users, which they are accomplishing by adding Layout Builder to a new branch of the Lightning distribution. Doing this has uncovered a few holes in the implementation relative to what's possible in contrib right now, and filling those gaps is the focus of the remaining 8.6 time for the team.

Layout Builder gaps
  • Allow the inline creation of non-reusable Custom Blocks in the layout builder [#2957425]
  • Add a validation constraint to check if an entity has a field [#2976356]
  • Determine if Layout Builder should replace entity_view_display for all Entity Types [#2936358]
  • No ability to control "extra fields" with Layout Builder [#2953656]
  • Allow Custom blocks to be set as non-reusable adding access restriction based on where it was used. [#2976334]
Integration with other subsysytems/modules
  • [PP-1] LayoutBuilderEntityViewDisplay::getRuntimeSections() does not delegate to plugins [#2976148]
  • Add EntityContextDefinition for the 80% use case [#2932462]
  • [meta] Decide how Layout Builder should function with Content Moderation and Workspaces modules [#2973382]
  • Layout Builder does not respect translations [#2946333]
  • Track Layout override revisions on entities which support revisioning [#2937199]
Media

Media has made tremendous strides in 8.6, including remote video support and a newly designed media library.

Next, we need to integrate that media library into the node form, and ideally allow people to add from there as well in a more streamlined fashion.

Blockers to media awesomeness
  • Create a field widget for the Media library module [#2962525]
  • (needs issue) Mark Media Library as beta
  • [PP-1] Allow media to be uploaded with the Media Library field widget [#2938116]
  • Any AJAX call disregards machine name verification when AJAX is used and leads to a fatal error [#2557299]
Migrate

The goal of this initiative for 8.6 is to stabilize the migration system which means marking the experimental Migrate Drupal + Migrate UI modules stable. This was also the goal for 8.5. What's making it tricky is multilingual migrations, which are themselves tricky because there are a multitude of ways one might have set up multilingual functionality prior to it being included in core in Drupal 8, which introduces lots of edge cases around making IDs line up and whatnot.

The team is taking a two-pronged approach here:

1) Attempt to close all of the remaining i18n-related issues.
2) Worst-case, split off multilingual migrations to an experimental module, so that the rest of the system that works for 80%+ of sites can be marked stable.

Make Migrate Stable
  • [policy, no patch] Mark Migrate Drupal as stable [#2905736]
  • [policy, no patch] Mark Migrate Drupal UI as stable [#2905491]
  • [META] Multilingual migrations meta issue [#2208401]
  • Experimental migrate_drupal_multilingual module [#2953360]
Out-of-the-Box

The Umami profile was committed (albeit marked hidden) in 8.5, and major efforts have been going on to remove all of the "beta blockers" preventing it from being visible in the UI. The last of these—Install profile in settings.php and mismatch check makes re-installs of Drupal hard [#2975328]—just landed earlier this week!

From here to 8.6, the team is working on stability and accessibility improvements.

Umami awesomesaceness
  • Un-hide Umami in 8.5 to vastly improve Drupal's evaluator experience [#2957464]
  • Improve Umami demo's support for managing field display settings [#2980029]
  • Improve Umami Demo's header layout and responsive behaviour [#2980528]
  • Umami missing some Media "plumbing" found in Standard profile [#2939594]
Workflow

Last, but certainly not least, is the Workflow initiative, which aims to add the Workspace contributed module to core in 8.6 to facilitate content staging and full-site previews. The module was already committed to 8.6 awhile back, but must be brought up to "beta" level stability to remain in the tagged + shipped release.

Because Workspaces can only stage content that's revisionable, there's also a parallel effort to add revision-ability to more types of data in Drupal core.

Blockers to Workspaces Stability
  • WI: Workspace module roadmap [#2732071]
  • Add workspace UI in top dialog [#2949991]
  • Remove the automatic entity update system [#2976035]
MOAR revisionable thingies
  • Convert taxonomy terms to be revisionable [#2880149]
  • Convert custom menu links to be revisionable [#2880152]
  • Convert comments to be revisionable [#2880154]
Anything else?

Whew! That's QUITE a lot. Are there any issues out there that we're missing that you feel are mission-critical to get into Drupal 8.6? Feel free to suggest them, with the caveat that the longer the list is, the more distributed the community's and core committers' focus is.

Thanks for reading!

Tags: drupaldrupal 8drupal 8.6product manager hat
Categories: Drupal

WeKnow: Creating a Custom Ajax Command in Drupal 8

Planet Drupal - 28 June 2018 - 12:37pm
Creating a Custom Ajax Command in Drupal 8

Drupal 8 provides the option to include an Ajax Callback within our applications using the Ajax Framework. There are some existing functions which can be used: Methods to hide/show elements in the html document, attach content to an element, redirect a page after a submit, and so on. Sometimes we need to implement something particular, or a custom JS code. In that case, those out-of-the-box functions are not enough. Fortunately, we can also create our own custom responses. So, let’s start creating a new ajax callback for a custom form submission.

mcastillo Thu, 06/28/2018 - 19:37
Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal