Personal battle plans for Drupal 8

Fighting creeping featurism while cleaning up core APIs.

Not surprisingly, I expect my focus to be the Butler project. I'm also talking about it at DrupalCon Chicago. See those links for the gory details, but in short: unified context system, unified plugin system, reversed page building flow to approximate "Panels and Services in core", unicorns, and puppies (in that order). We'll see how far we get. :-)

As time permits, I also have begun exploring ways to revisit how hooks work for greater performance. Drupal is still fundamentally architected for Drupal 4.5 circa 2004. Modern Drupal is a lot bigger, and that means we need to reconsider some of our underlying assumptions.

So yeah, expect me down in the plumbing again. :-)

The one thing I would like to see sorted in Drupal 8 and something I am happy to lead / take part in is node previews.

Currently when authoring a node the preview button just outputs the not content above the node/add form in the admin theme. The preview *should* display the full node as it would be seen by the user of the site, in the site theme, with all blocks and all field content. Ideally this should be in a new window / tab.

I plan on focusing my core work in Drupal 8 on the staging and deployment problem, with the goal of enabling a workflow in which any part of your Drupal site (content, configuration or other) can be moved between environments without concern. Please see the related core conversations in Chicago for more details.

I also plan on helping Larry in the Butler implementation, particularly in the places where Butler and web services coincide. Hopefully this will result in portions of the Services and RestWS modules ending up in core, enabling a wider variety of response formats and making mobile app interaction much easier.

Oh and ponies.

Drupal has really scaled up the amount of JavaScript in use. As such we need to bring in some new patterns to help with the scaling, modularity, and more inside our JS. In addition to these we need minified JS and some standards.

The other element I want to work on, though I'm sure I'll touch on others, is performance. We need Drupal to run faster on shared hosting. Drupal 7 is the version that scales. Lets make Drupal 8 the version that performs. To do this we will need to make some architectural changes.

• Adding the basic HTML5 elements to core
  #675348: META: Support HTML5 form input elements
• Unifying and fixing a lot of entity and entity API inconsistencies
  http://drupal.org/project/issues/search/drupal?issue_tags=entity
• Improving token support, and adding a token UI into core
  http://drupal.org/project/issues/search/drupal?issue_tags=token
• Providing an easier pathway for Pathauto in core (e.g. allowing the {url_alias} table to store what entity and entity ID an URL alias is associated with).
  http://drupal.org/project/issues/search/drupal?issue_tags=pathauto
• Evaluating the Statistics module if we need to make it into a more usable API or if it should be dumped into contrib
• Improving the user picture UI and API

I *really* want us to take second looks at our API

A whole group of people have been working on HTML5 since July 2010.
http://groups.drupal.org/html5
http://chicago2011.drupal.org/coreconv/let-s-html5-ify-drupal

The plan: Work out how core should implement HTML5 forms and markup in the HTML5 Tools Module and HTML5 Base theme. And then put Tools and Base into core.
http://drupal.org/project/html5_tools
http://drupal.org/project/html5_base

1/ Adding validation framework (including basic rules) for fields and FAPI, so contrib can build on this in a consistent way for adding more custom/complex rules

2/ Optionally add support for client side validation (http://drupal.org/project/clientside_validation), at least make sure we can do it easier in contrib by providing the right theme functions.

Add user revisions to core, and maybe even something more general aka entity_revisions so we can use it for node, user, taxonomy, files, ...

I know there's a lot to SEO but I always found it odd that META tags for nodes/elements weren't ever in Drupal core. I'd be willing to help supply a patch but I do not contribute or maintain the SEO/META modules used for this so I don't want to step on any toes but I'm always willing to help progress Drupal and would volunteer my coding fingers for this.

I've just released the first alpha of File Cache for Drupal 7. I believe this is important performance feature and I'd like to see it in Drupal 8 Core. Its benefits are not only in shared hosting scenarios because memory and network filesystems can be utilized for caching too.

I would love to see proper access control list support on entities and fields. Something more in line with POSIX ACL support, or at a bare minimum CRUD perms per object, would be a large win for those in the enterprise.

I want to advocate for Small Drupal Users, and make it easier for users and site admins to get the most out of Drupal, and take their first steps towards contributing.

Dries has mentioned the tension between making Drupal great for great big sites, and focussing on scalability, deployment etc - (Critical and important and wonderful work) but also keeping an eye on what small sites need, and those small sites generally don't have a team of Drupal developers, and can't afford to hire a top-tier Drupal shop.

I'd like to see Drupal be the number one choice for open source project websites - and not see them wasting developer time on their website, instead of their project.

I'd like to see Drupal be the number one choice for communities that want to get on the web and maintain their web presence. We need to make it easier to setup and host drupal sites on low-end hardware and make the information on how to do it as straightforward and easy to find as possible.

That's what I'd like to work on for Drupal8.

I can imagine myself working on this issue: #481560: Provide proper AJAX URL resp. base path depending on context
We shall see if RL allows me.

Mainly I plan to work on Drupal calendar localization and I hope to see the required patch in core. See Calendar Framework and jQuery Calendars which might be merged into a World Calendars module, soon.

Let's give some love to the still neglected File & Media system. I'm heading up a brainstorming session at DrupalCon to bring fieldable media / file entities to core, and plan to put in some work over the spring & summer in that direction. We need to finish up the excellent start in Drupal 7 of overhauling the File and Stream Wrapper API, so that it's elevated from its orphaned state.

I'd like to focus on forum and blog UX in context of Butler

Also cares about caching #636454: Cache tag support

Performance and scalability

In that order - since Drupal 7 made some very good advances with scalability, but is a lot more mixed in terms of performance.

As well as working on specific issues and broader refactoring, I also want to help get better processes, tools and documentation in place to prevent regressions and make performance knowledge more generalised in the community. Almost every line of code that gets committed has potential performance ramifications, and a few performance specialists trying to cover things doesn't cut it.

Some specifics are in the queue tagged with performance, I also started the beginnings of a series on the bigger picture.

API cleanup

- Improvements and cleanup to the entity API. I think this is on a lot of people's minds, which is great.
- Refactoring system module and /includes
- Improving the caching API and adding a cache invalidation API.

I'll also be continuing with code gardening.

a11y improvements (e.g., https://drupal.org/node/447816)
Helping eager new code contributors become patch creators and reviewers.

Continuing to evangelize Drupal (cause as sexy as Druplicon is, we still have to market the product)

Keep it lightweight.

Don't try to put too much into core. Only make it a basic framework and use modules to extend. Don't bloat core too much.

Drupal 8 should focus on keeping a small footprint but still provide the hooks. Look at any "specific" functionality bundled into Drupal that shouldn't.

Should it ship with Forum by default? Why have a basic forum included in core, instead of through modules?
Should a node require a title? Can't it be abstracted into fields?
etc.

Once again I will try to get some more 'translatability' into Drupal core. While I think content translation and translation workflows can be better developed in contrib, there are some features we absolutely need to have in Drupal core. These are:

- Translation for user defined strings, by extending the locale API to handle 'named strings'. This may be worked out as an extension of the 'context' idea.
- Multilingual variables. Also I'd like to attack (again) the problem of a Variables API in general, but this time we have some working approach in contrib, pretty much what I'd like to have for Drupal core, http://drupal.org/project/variable

And I'll also try to help with anything that makes Drupal smaller, not bigger, better APIs, smallcore.

I plan to concentrate on improving (or completely rewriting — of course, neither of those alone) core search to be a more flexible API, strictly separated from the default implementation in core.

- g.d.o discussion
- Core conversation at DrupalCon

I will be working on a unified Values API. Just like we have fields that are abstracted from the node types and are reusable, value sets (e.g. Allowed Values, perhaps Taxonomy Terms) should also be reusable, pluggable, and managed through their own API, rather than an arbitrary textarea.

I've already done some contrib work for this in Drupal 6.x and I'm in the process of porting it to Drupal 7.x. My battle plan is to port this for inclusion in Drupal 8.x core.

I will try to provide means of "selecting" something in the user interface to appear on a list of things of that kind somewhere else. Sounds kind of confusing :) In other words something like a slimmer Selector in core.

I'll try to port calendar system or at-least its require core patches to Drupal 8's core
http://drupal.org/project/calendar_systems

We really need a better help system. I started an issue already:
#1031972: Discussion: What would a better help system for D8 be?
I plan to do some of the work at least on this issue (beyond the requirements gathering that I've already been working on), but (reality being what it is) I will not be able to do it alone, and there are quite a few pieces that will be needed.

We're having a core conversation on it in Chicago:
http://chicago2011.drupal.org/coreconv/help-needs-help

• Simplifying and unifying our APIs.
• A multi-format, multi-device rendering pipeline.
• Improvements to FAPI and AJAX for better handling of modal wizards and other advanced interaction flows.
• Improvements to the theme system to make it make more sense to designers and front-end developers, and fit their workflows better. This ranges from several easy issues that we failed to complete for D7 to a new round of architectural thinking about how to make render/theme manipulations more rule based.
• Generally help out in the issue queue, trying to prevent issues from getting stuck or languishing from lack of attention.

EDIT:
This post does not exactly describe what I am going to work on. So it probably does not fit in here.

What I can say: When the namespace bikeshedding has found a direction, I will probably contribute in one way or another. At least I'm going to participate in the bikeshedding.

A) Meta: help massively improve the D8 development process and our collaboration tools. In particular:

• Git Phase Next (see the talk at DrupalCon I'm giving with sdboyer and webchick on this)
• Redesign the issue queue

B) Continue to try to maintain the Update manager in core. Lots still to do. Ideally:

• #606592: Allow updating core with the update manager
• Fixing error propagation and making the messages when things go wrong not quite so horrifyingly bad (I've got high standards, huh?) ;)
• #774254: Provide backup/restore functionality for db/code (related to the staging/deployment problem other people want to solve, which is great)
• Potentially a module and theme browser

From experience, I know most (all?) of this will not happen unless more people decide the Update manager is important and contribute real resources to its further development. I can help by providing direction, detailed reviews, and some of the code, but I can't write all of this myself in my "free" time, especially not with all the other responsibilities I have...

C) Help API cleanup efforts. I believe the goal needs to be clearer/cleaner separation of Drupal-the-framework and (a set of?) Drupal-the-product(s). This money quote from eaton perfectly expresses the problem:

... until they treated Twitter.com as a web application built on top of their API, other users of their API would always be second-class citizens.

D) Cheer on (and when possible, help) the Butler effort.

E) General help in the issue queue (giving detailed reviews, triage, helping unstick things, etc).

I'm going to make Drupal Beautiful, currently on the planheap are themes, icons and design templates.

I'm also really wanting to get a good theme repository on D.O.

My points

localization
speedup
large systems integration (cms,erp, e-commerce)

The blocks page needs a shot in the arm. If you get a heavy number of blocks on that page, the browser fails to load/render/use all the JS and when you hit submit you lose all your block orders. That page needs the ability to filter by region, archive disabled blocks, search, all sorts of things. Blocks also need revisions, and the ability to integrate with workflow and rules.

I'll help with whatever efforts are planned to get things like path redirect, global redirect, page titles, and other SEO efforts into core, that stuff is beyond key--we can't have a default install that breaks many key SEO guidelines.

But dearest to my heart is the need to move toward a unified revision system. Coming from enterprise deployments of Drupal we typically had to launch new nodes, node revisions, new blocks, theme updates (typically via svn), css/js injector changes, view updates (typically via features) and other things to make even monthly promotional site changes go live. A unified system for setting up and managing these revisions is key.

Oh, and helping to move toward guids.

Generally, I'd like to work on improving the entity API in core based on my experiences with entity API module. Some points are
* Improve the entity API to handle full CRUD and unify existing stuff to make use of it.
* Introduce a common entity base class and improve the DX for dealing with entities (no $entity_type, $entity any more)
* If time permits, establish a common place for entity property information and unify access to entity properties regardless whether they are fields or not.

Points of interest in order of priority
(although I can't really plan to work on any of those all by myself) :

API for "long running processes" (house cleaning tasks, mass data update, schema refactoring / migrations)
- Unify Batch API and (Job-)Queue API : turn the 'batch progress bar UI' into a mere consumer of queued jobs, amongst others (cron, drush...)
- Figure out the paradigm impacts :
functions that you cannot be sure have done their job yet when they return;
difference between blocking processes (site unusable or 'incomplete' before job is finished) and background processes.

(no existing issue # that I can remember)
Might include something like getting http://drupal.org/project/queue_ui in core

OO rewrite of Field API
Will probably highly depend on Butler's "unified plugin system" (wink @Crell)
Group brainstorming highly needed to figure out the correct OO model (field / instance / value).

http://drupal.org/node/1032850

Rework the "entity display" API (and UI ?)
- Formalize an API for entity "components" ("Field API" fields, "extra" fields, groups...), with the ability to have formatters and settings.
- Introduce "Displays" as a standalone (exportable) animal, that encloses display settings for an entity's components with order and settings. No more spreading this info between N field instance definitions + a serialized array in the {variables} table for non-fields + data in the {field_groups} table + ...
- Question convergence points between Views' "field display options" and Field UI's "Manage display" UIs

http://drupal.org/node/367498
http://drupal.org/node/1050664#comment-4052376
http://realize.be/comment/1372#comment-1372

About a month ago I wrote up a pretty detailed outline of my battle plan for the upcoming release. To quote:

1. Missing APIs: Some of Drupal's most pressing blind spots could be filled by providing a unified "Context" system and exposing all Drupal entities via a RESTful interface.
2. Deployment: The pain of managing, deploying, and sharing Drupal solutions can be dramatically reduced with universally unique IDs for all Drupal data, and a standard system for importing, exporting, and overriding those items in code.
3. User Experience: The work in D7UX can be extended by documenting and simplifying the use of common UX patterns like color pickers and draggable blocks, while a streamlined "Focus on the post" theme would act as a compliment to Bartik's swiss army knife.
4. A Real Profile for a Real Use Case -- Tailored to an actual audience, Drupal's default install profile could empower users with no site-building experience, free the drupal UX team from the tyranny of one-size-fits-all workflows, and reveal areas where our assumptions are crippling other solutions. Rather than "dumbing down" Drupal it should provide an example of what a built-out site looks like, how Drupal's pieces work together, and provide a 'gateway drug' to the wild world of Contrib for those exploring site building.

None of these items are simple -- each one would be a huge undertaking for any development team. Over the past decade, though, our community has proven that it can do amazing things. Teams of passionate developers, designers, and UX experts have already been working on many of these tasks: working with this plan would simply highlight and prioritize the work that's already going on.

In addition, coordinating efforts between these three major areas will help bring balance and a compelling narrative to the Drupal 8 development cycle: outside observers will know what we're shooting for, why it matters, and what the promise is for those outside the Drupal development club.

This is where I'll be focusing. How about you?

The concept of the focused install profile - currently being called 'Tsunami' - has gotten a lot of traction already. There's a groups.drupal.org section set up for it and we'll be conducting a BOF session at Drupalcon on Thursday to coordinate further work.

I'm interested in improving installation profiles and maybe node's edit form improvements.

would like to join my hands on extending 'features' for practical scenarios.

Also, interested in incremental DB related stuffs as well.

I'm also going to try and push the boundaries of Drupal theme design by contributing themes for the community to help with the efforts of making Drupal more beautiful. In comparison to other CMS' I feel Drupal needs to "up the peg" design wise which I hope to help with and bridge the gaps.

It's all about flexibility, practicality and beauty.

My plan for next months:

1. PDF Views (direct generating PDF form Views)

I want to increase the support for PDF output (quality and performance) in Drupal. I choose a different approach to do that. You can find more information about my progress and ideas here:
http://drupal.org/sandbox/hunziker/1084012

2. Meta MVC Pattern

In modern web application you have often a so called Model View Controller (MVC) pattern. Drupal has not direct implemented such a pattern, but on the meta level there establish something very similar.

One of the strengths of Drupal is the possibility of parameterizing much of the applications. This implies the usage of meta models. Such meta models decrease the developing and maintenance costs of an application. This happens for each of the three components of the MVC pattern separately.

You have the entity API introduced in Drupal 7; this is a kind of modeling a Model. This part of the meta MVC pattern is relatively well established and therefore also a part of the Drupal Core. The Views part of the MVC pattern is delivered by the Views module. This part is also stable and widely used and therefore it becomes maybe a part of the Drupal core.

The last component of the MVC pattern, the controller, is not yet fully established. There are several modules that try to accomplish the parameterizing of the control flow of an application.
Example:

• Rules module
• Trigger module
• Workflow module (Drupal 6)
• Maestro module (Drupal 7)
• and some others

But here is some open space to do a better parameterizing of the control flow of an application. For that reason I will spend some time to enhance this part of Drupal and come over with a new approach to solve this.

A common theme has been 'API Cleanup' and I think alot of this is going to come down to our default entity implementations and how well they work. I'm planning to work on unifying the base entity controller that core provides, adding better support for revisioning and possibly even making entities into instances of their own class (maybe even with methods). I've been able to accomplish this on a limited scale in contrib for Drupal 7, so I think this is a realistic goal for D7. After we enable all this, I'd like to see core entities converted (one at a time) to use these new APIs/features. $node->save() anyone? I think it's time we give it try.

The biggest problem with this, will be the reason that our APIs are currently in a state where they need 'cleanup' anyway: backwards compatibility. While it's nice that contrib modules can implement clean interfaces now, I'd really like to be able to use the same features with Drupal core.

EDIT:
This post does not exactly describe what _I_ am going to work on for D8 core. So it probably does not fit in here.

What I can say:
I am going to participate in discussions about more permissive backport policy and "forward API extensions" added to stable branches. The decisions need to be made by others. When a direction on that is settled, I will probably contribute in one way or another. If this counts for this thread - probably not.

Propose. In node_load add a parameter that would indicate which fields to retrieve. This optimization will save memory in the development of modules.

Example: node_load($nid, array('title', 'created'));

Dear friends ... seemingly mobile ecosystem is a D8's major target.

Therefore, some tips could be reviewed:

1.- D8 should make sure staying within the intersection of JQuery and jquery-compatible syntax JS microframeworks (i.e zeptojs or xui). A feasible goal.

2.- To manage properly the new APIs of HTML5, particularly client-side resources (as DB support), to build Drupal apps capable to run into off-line mobile terminals. Yes, ... these are strong words.

#1077356: HTML5 in core battle plan
Sandbox initiative set up, battle plans being drawn up.

#1087784: Add new theme to Drupal 8.1.x or another minor version
Out with Garland, all new plans for a new theme and D4DC Initiative (Design 4 Drupal Core).

http://groups.drupal.org/accessibility
In accessibility queue we're talking about our battle plan for D8, testing, what standards we want to achieve and revising D7 efforts.

I'll try to get user management more user friendly. Right now, you got a big-ass list. You can filter it by role, permission and state. If you want to find a specific user, based on username or email address, you're out of luck (you'll have to use the "search" feature outside of the user management screen, unless if that part's been turned off -- which is very often the case). It might be just a small addition, but every bit helps.

I would like to help improving and making some enhancement in frontend related stuff, like JavaScript refactoring, html5ying Drupal Core and helping with accessibility concerns. I think JS' presence in Drupal core has been increasing and we have to rethink some parts to make a new Drupal JS library or something like this to help along developers to create ssome js functionality in an standard drupal way

Documentation contribution was my initial thought. But there's one thing that keeps jumping out at me as a potential difficulty for all but the very proficient users; the connection / integration / use of Drupal along with elements that appear to be becoming mainstream - Views, Panels, Contexts and Spaces.

Obviously Views is going to be the best known and most used. But I am still figuring out what they all mean together, what crossovers there are and what they can, can't, should and shouldn't do together and separately.

The reason I see it as important is because I get the impression that together these modules are likely to change the concept of making websites in Drupal (if they haven't already). But the power is likely to be underused due to the possible lack of clarity defining exactly what these elements do.

So what I'd like to do depends on which of these (if any) will be part of D8 core. Either clarification of the connection from Drupal to these things (for example, showing people that they may not need to hack code in certain cases by using such modules) or if integrated, to show how they work as one.

As I right this I am thinking how my contribution could be of benefit. Documentation probably, along with me getting a better understanding and being able to document that in a way that others will understand it.

I'm going to help the Field API people on the possible OO rewrite and the idea of a 'Display object'. I'd like to introduce the concept of regions on single objects too, so the ultimate goal could be to replace a lot of existing default template files with one single template file to start with.

Another work area is a new field UI which will start out as a contrib for D7 which we hopefully can move afterwards into core.

No real issues yet; see remarks from yched above and in the minds of bojhan, yoroy, me and possible others too.

For me the biggest issue first starting with D6 and later D7 was not to give up after a few hours e.g. for customizing the frontpage.

Especially beginners want quick results in a short time with no effort nor knowledge.

YES - maybe mission impossible, but if we could manage this, the drawn attention and especially the motivation to find out more would increase.

Typo3 (typo3.org), one of the most favored CMS here in germany and for me my main competitor when it´s going to choose the CMS (my clients: "we heard that this should be possible with Typo3") hat a edition with predefined content & structure.

I would love to help on something like a "designers starter edition" to help people get cool results without any programming knowledge.

A d7 version is in progress: http://drupal.org/project/dsk

Of course in D8 there should exists an install-option by default.

To extend the idea the basic site structure should be a ajax based welcome tutorial to show a total new customer all the basics within less then 30 minutes to e.g. create a cool personal blog.

And yes - wordpress is still the most used system within the low-budget-section cause customers don´t think about extending first. For them the most important is a good looking front-end and quick results.

I submitted this too late for D7, but would like to see it make it into D8, and have updated the patch already.
http://drupal.org/node/880940

I would also like to improve the module list as per Module Filter:
http://drupal.org/project/module_filter

Writing "the Designer's Guide to Drupal," and working on making more designers less scared of the occasional command line moment. (hopefully) bringing Drupal workshops to the web design curriculum at the Center for Digital Imaging Arts in Waltham. Working on an idea I've been kicking around for an HTML5 base theme that outputs clean code and incorporates a 24-column adaptive grid (which is about 75% done at the moment). Continuing to be an overall loudmouth on behalf of all us Drupal designers.

Stuff and things.

Registration and log-in flow is my manageable D8 priority (ideally with D7 module).

Helping build the infrastructure/network to make coordinating (and funding) Drupal initiatives a matter of flow (to stick to a theme) is my unmanageable D8-cycle priority.

... and maybe, just maybe finding some naive people to write the Definitive Guide to Drupal 8. But finding a project manager for same first.

One of the things I've never liked about Drupal is how it handles the profile and the edit account pages.

Short version

I've created a sandbox project to start working on ideas and to solve this in D7. The whole idea consists of two simple concepts:

• Profiles should be easier to customize/hack/change at least for themers. Even if this means starting with a blank page. Why? Because an admin could just add blocks to customize the profiles without having to remove the "History" section, the Picture and who knows how many more stuff.
• Settings should be separated from Profiles

Extended version

Let me give you two examples of why I'm frustrated with this situation.

• If you're trying to make a simple community site, where users visit their profiles very often, you'll probably want to theme the Profile. The problem is that the Edit Account is always right next to the Profile. Even worst, the View and Edit tabs make everything more confusing. Why is this? Because we have in one single place, the Profile, Stuff like "History", Content, Pages added with Views, and Settings.
• Lack of consistency. If you look at the Shortcuts module you'll see it implements user/uid/shortcuts as a path. OpenID does something very similar and many other contrib modules do the same, like Notifications. The problem with this approach is that it's in the same level as the Profile (user/uid/account), when this is a configuration page and it should be under user/uid/edit/shortcuts.

Where does this come from? Well, if you visit websites like Twitter.com or Digg.com and many more you'll see that they separate the Profile from the Account Settings. Both sites, use a Tab for each group of settings so Change your password is not mixed with Change your Email like Drupal does. A long form in user/uid/edit is usually confusing.

As I mentioned above, I created a module to address this problem. What it does so far is:

• Separate the Profile and Edit Account pages completely. The user won't see the View and Edit tabs at all.
• Create a Settings page to handle the user settings. Account, Profile and Password have been separated into their own pages. This gives us more meaningful paths for the edit account page. Instead of having user/uid/edit/foo, the user will see settings/uid/foo
• Provides a hook_profile_page_category() based in hook_categories() so any module can create a configuration page on its own and integrate with this module in a more consistent way.

If you have ideas or want to jump in and help shape this project, please create an issue at http://drupal.org/sandbox/lelizondo/1098228

Entity API. Performance. I would love to see a return to the lean system we once were...

It appears that I have accidentally hinted at killing PHP filter in Drupal 8, and some people took interest in the idea. I've started a sandbox at http://drupal.org/sandbox/wizonesolutions/1109974 to work on developing a D7 module to prototype the idea and have something to offer if I decide to run the gauntlet and try to call it the death of PHP filter.

Tall order. Lazy is hard to kill. But I'll at least start the fight in contrib, and who knows, maybe it'll wind up in D8 core!

Twitter hashtag: #KillPHPfilter

And that's my D8 "thing," I suppose.

This is a scenario for me, and possibly for other _not_ hardcore core developers: Just listen, follow the development from the beginning, learn a lot, then write more plans in Personal battle plans for Drupal 9 topic. :)