Enhance Drupal with the CKEditor 5 Plugin Pack: a free set of rich text editor enhancements at no cost for drupal web projects.There are many opportunities to connect with fellow event organizers throughout the week at DrupalCon Portland 2024.
Community Events Booth
Expo Hall - #106
Visit with the EOWG board and other event organizers in the Expo Hall. Be sure to bring some of your stickers and swag to share with the community!
Event Organizers Roundtable BOF
Room G132, Table 1
Open discussion time for Drupal Event Organizers to gather and for others who are interested in organizing their own events or learning more about the Event Organizers Working Group.
Contribution Day
Room B115-116
Find us to help improve the Community Events page.
Community Summit
Room C120-122
EOWG Board members will present a panel at 9:15am. Join us for a day of community discussions. The summit is open to everyone in the Drupal community, at no additional cost.
Open Meeting via Slack!
Tuesday, May 14 starting at 16:00 UTC / 12:00 pm ET
Join us to discuss these and other topics in the #event-organizers channel.
If there is something you want to share or discuss related to your camp, meetup, or other events organizer topics either leave a message in the Slack channel or comment on the Drupal.org meeting agenda issue.
This blog post was written by Promote Drupal committee member Emma Horrell.
If you’re familiar with Drupal, you will have learned its language. You will be familiar with words like Views, Blocks and Paragraphs, and you will appreciate their respective features and functions. But for those new to Drupal, getting to grips with what words mean can mean a steep learning curve.
User research to improve the Drupal admin UI raised an interesting finding. When the Drupal community was asked to complete an exercise where they grouped terms from the UI into categories that made sense to them, the results showed people were unable to place some of the terms. Further investigation indicated that people weren’t sure what these outlier terms meant (and therefore they had struggled to sort them).
We wanted to address this finding from the research because we recognised the importance of people understanding Drupal terminology to enable and empower them to use Drupal confidently and competently. We strongly felt that Drupal language shouldn’t be a barrier to people new to the community learning and we wanted to take the opportunity to address this. It felt like the most logical place to start was to identify Drupal terms that caused confusion - ‘Drupalisms’. With a core team of community volunteers behind it, issue 3381734 was begun.
With the issue live, we set to work, picking out terms that matched the ‘Drupalisms’ brief – in other words, terms which we felt were confusing to new Drupal users. Our initial list included words like: ‘Node’, ‘Blocks’, ‘Structure’, ‘Entity’, ‘Paragraphs’. As the issue queue gained momentum, more words flooded in, and people expressed opinions on aspects of Drupal terminology – for example, questioning Drupal’s use of ‘Site Builders’, ‘Developers’ and ‘Themers’ to describe the roles and functions of the Drupal community.
Attending DrupalCon Lille presented the chance to run a Drupalisms BoF to encourage people from the community to come together and collaborate on this issue. We spent the time looking at our initial list of terms, thinking of more, and thinking about how we would describe them to people new to Drupal. This exercise helped us appreciate the importance of preventing language being a blocker to new Drupal users and therefore affirm the importance of the issue.
Coming together after the BoF, we reflected on possible ways forward. We established that our original goal to identify Drupalisms was part of something bigger, an impetus to make sure our language opens up Drupal to everyone, to ensure we are being as accessible and inclusive as possible. We all agreed this was not something fixable quickly, and we committed to a regular pattern of fortnightly meetings to work on the issue.
Our initial meetings were spent discussing the issue in more depth. We thought about the varied mental models, expectations, native languages and levels of understanding people bring to Drupal, and how their prior experiences (sometimes with other Content Management Systems) shapes their language perceptions. We considered the roles that glossaries tooltips and micro-copy can play in helping people make sense of our terminology in different contexts. We thought about the past – and how historic events had led to the language we use in Drupal today, and then ahead to the future, thinking about the impact of changing terminology and the possible consequences. We also established that language is an emotive subject, and therefore that making decisions about language should be based on evidence over opinions.
Ralf Koller suggested an objective, multi-step approach to working on the issue inspired by various sources including Abby Covert’s book ‘How to make sense of any mess’, Sophia Prater’s Object-Oriented-User-Experience (OOUX) methodology and the writings of other content design specialists like Erica Jorgensen. The stages we are working through are as follows:
Addressing issues of CMS language more broadly, and acknowledging that Drupal is not alone in wanting our vocabulary to be intuitive and easy-to-understand, I’ve reached out to others in the wider open-source CMS community to think of ways we can use our collective force to develop a more consistent approach to CMS terminology. It’s early days but there is interest, and we’re looking to establish a date for an initial meeting.
We’re working together on the first stage of the process - the noun foraging, gathering terms from many sources. Our current list stands at around 400 terms and we know there will be more. If you would like to join in helping us with this piece of work or you are interested to know more, please comment in the issue queue, join the Drupal Slack channel #drupalisms-working-group, message me on Drupal Slack or email me directly at emma.horrell@ed.ac.uk and I can provide more information or add you to the meeting series. You can also read the ongoing meeting notes from the issue queue.
Rector is a tool for making changes to PHP code, which powers tools that assist with upgrading deprecated code in Drupal. When I recently made some refactoring changes in Drupal Code Builder, which were too complex to do with search and replace regexes, it seemed like a good opportunity to experiment with Rector, and learn a bit more about it.
Besides, I'm an inveterate condiment-passer: I tend to prefer spending longer on a generalisation of a problem than on the problem itself, and the more dull the problem and the more interesting the generalisation, the more the probability increases.
So faced with a refactoring from this return from the getFileInfo() method:
return [
'path' => '',
'filename' => $this->component_data['filename'],
'body' => [],
'merged' =>$merged,
];
to this:
return new CodeFile(
body_pieces: $this->component_data['filename'],
merged: $merged,
);
which was going to be tedious as hell to do in a ton of files, obviously, I elected to spend time fiddling with Rector.
The first thing I'll say is that the same sort of approach as I use with migrations works well: work with a small indicative sample, and iterate small changes. With a migration, I will find a small number of source rows which represent different variations (or if there is too much variation, I'll iterate the iteration multiple times). I'll run the migration with just those sources, examine the result, make refinements to the migration, then roll back and repeat.
With Rector, you can specify just a single class in the code that registers the rule to RectorConfig in the rector.php file, so I picked a class which had very little code, as the dump() output of an entire PHP file's PhpParser analysis is enormous.
You then use the rule class's getNodeTypes() method to declare which node types you are interested in. Here, I made a mis-step at first. I wanted to replace Array_ nodes, but only in the getFileInfo() method. So in my first attempt, I specified ClassMethod nodes, and then in refactor() I wrote code to drill down into them to get the array Array_ nodes. This went well until I tried returning a new replacement node, and then Rector complained, and I realised the obvious thing I'd skipped over: the refactor() method expects you to return a node to replace the found node. So my approach was completely wrong.
I rewrote getNodeTypes() to search for Array_ nodes: those represent the creation of an array value. This felt more dangerous: arrays are defined in lots of places in my code! And I haven't been able to see a way to determine the parentage of a node: there do not appear to be pointers that go back up the PhpParser syntax tree (it would be handy, but would make the dump() output even worse to read!). Fortunately, the combination of array keys was unique in DrupalCodeBuilder, or at least I hoped it was fairly unique. So I wrote code to get a list of the array's keys, and then compare it to what was expected:
foreach ($node->items as $item) {
$seen_array_keys[] = $item->key->value;
}
if (array_intersect(static::EXPECTED_MINIMUM_ARRAY_KEYS, $seen_array_keys) != static::EXPECTED_MINIMUM_ARRAY_KEYS) {
return NULL;
}
Returning NULL from refactor() means we aren't interested in this node and don't want to change it.
With the arrays that made it through the filter, I needed to make a new node that's a class instantiation, to replace the array, passing the same values to the new statement as the array keys (mostly).
Rector's list of commonly used PhpParser nodes was really useful here.
A new statement node is made thus:
use PhpParser\Node\Name;
use PhpParser\Node\Expr\New_;
$class = new Name('\DrupalCodeBuilder\File\CodeFile');
return new New_($class);
This doesn't have any parameters yet, but running Rector on this with my sample set showed me it was working properly. Rector has a dry run option for development, which shows you what would change but doesn't write anything to files, so you can run it over and over again. What's confusing is that it also has a cache; until I worked this out I was repeatedly confused by some runs having no effect and no output. I have honestly no idea what the point is of caching something that's designed to make changes, but there is an option to disable it. So the command to run is: $ vendor/bin/rector --dry-run --clear-cache. Over and over again.
Once that worked, I needed to convert array items to constructor parameters. Fortunately, the value from the array items work for parameters too:
use PhpParser\Node\Arg;
foreach ($node->items as $array_item) {
$construct_argument = new Arg(
$array_item->value,
);
That gave me the values. But I wanted named parameters for my constructor, partly because they're cool and mostly because the CodeFile class's __construct() has optional parameters, and using names makes that simpler.
Inspecting the Arg class's own constructor showed how to do this:
use PhpParser\Node\Arg;
use PhpParser\Node\Identifier;
$construct_argument = new Arg(
value: $array_item->value,
name: new Identifier($key),
);
Using named parameters here too to make the code clearer to read!
It's also possible to copy over any inline comments that are above one node to a new node:
// Preserve comments.
$construct_argument->setAttribute('comments', $array_item->getComments());
The constructor parameters are passed as a parameter to the New_ class:
return new New_($class, $new_call_args);
Once this was all working, I decided to do some more refactoring in the CodeFile class in DrupalCodeBuilder. The changes I was making with Rector made it more apparent that in a lot of cases, I was passing empty values. Also, the $body parameter wasn't well-named, as it's an array of pieces, so could do with a more descriptive name such as $body_pieces.
Changes like this are really easy to do (though by this point, I had made a git repository for my Rector rule, so I could make further enhancements without breaking what I'd got working already).
foreach ($node->items as $array_item) {
$key = $array_item->key->value;
// Rename the 'body' key.
if ($key == 'body') {
$key = 'body_pieces';
}
And that's my Rector rule done.
Although it's taken me far more time than changing each file by hand, it's been far more interesting, and I've learned a lot about how Rector works, which will be useful to me in the future. I can definitely see how it's a very useful tool even for refactoring a small codebase such as DrupalCodeBuilder, where a rule is only going to be used once. It might even prompt me to undertake some minor refactoring tasks I've been putting off because of how tedious they'll be.
What I've not figured out is how to extract namespaces from full class names to an import statement, or how to put line breaks in the new statement. I'm hoping that a pass through with PHP_CodeSniffer and Drupal Coder's rules will fix those. If not, there's always good old regexes!
I've been building and designing automation systems for almost 20 years. I built DevShop on top of Aegir to implement continuous integration and quality control over 10 years ago.
Running CI systems is hard. Really hard. There needs to be an active task runner. A dashboard. API integrations. Tooling. Network Access. It can be incredibly complicated. In the Enterprise? Forget it.
I've been imagining a new system for many years, and here it is.
Portland, Oregon – the Rose City, home to an array of charming experiences that extend beyond the walls of this year's much-anticipated DrupalCon. While knowledge sharing and the industry buzz at the Oregon Convention Center will undoubtedly be the main draw, the locale offers a diversity of attractions, from serene parks to bustling markets. For those fortunate enough to attend DrupalCon, it would be a miss not to maximize your time and immerse yourself in the unique culture Portland has to offer. Here are five more local attractions, in addition to our previous recommendations, that promise to enrich your DrupalCon experience and provide unforgettable memories.
SW corner of NE Oregon St and, NE Lloyd Blvd, Portland, OR 97232
Arriving in Portland, the first thing visitors often notice is the city's commitment to sustainability and the vibrant outdoor lifestyle. What better way to experience this than by gliding through the renowned bike paths and urban green gardens on an E-Scooter? A stone's throw away from the Oregon Convention Center, Peace Memorial Park provides a picturesque setting that is perfect for a leisurely ride. With the Willamette River flowing alongside and the skyscrapers beyond the riverbank, this sanctuary of serenity is a stark contrast to the bustling city center.
400 SW Kingston Ave, Portland, OR 97205, United States
Known as the City of Roses, Portland proudly hosts the International Rose Test Garden, the oldest of its kind in the United States that has been in continuous operation. With the arrival of spring, there's no better moment to witness the garden's vibrant first blooms. Showcasing over 10,000 roses across 610 varieties, the garden not only offers a breathtaking display but also serves a crucial role in the cultivation and testing of new rose species. As a sanctuary for hybrid roses from across the globe, the garden continues its legacy of innovation and preservation in the heart of Portland.
321 NE Davis St, Portland, OR 97232
Portland is known for its craft coffee culture, and Roseline Coffee Cafe & Roastery stands as a testament to this. Just moments from the convention center, this local favorite offers a welcoming reprieve from the conference crowds. Here, you can try blends and single-origin roasts that represent the pinnacle of Portland's coffee craft. Whether you’re an espresso aficionado or simply in need of a caffeine hit, the experience at Roseline will elevate your DrupalCon visit.
1219 SW Park Ave, Portland, OR 97205
Just a brief drive from the Oregon Convention Center, the Portland Art Museum stands as Oregon's largest and one of the nation's oldest art institutions. Nestled within two historic buildings in Portland’s South Park Blocks, a key part of the city's cultural district, the museum boasts an extensive and diverse art collection. Visitors can purchase Portland Art Museum tickets online or at the museum, with adult admission priced at $25. The Museum offers a wide array of exhibitions, from in-depth retrospectives of individual artists to comprehensive historical surveys and significant traveling exhibitions from across the globe. These exhibitions showcase pieces from the museum's own collection alongside masterpieces loaned from other museums and private collections worldwide.
2 SW Naito Pkwy, Portland, OR 97204
If your stay in Portland includes the weekend, the Portland Saturday Market offers a vibrant immersion into the local eccentricity and artisanal zeal that define the City of Roses.
A visit to this lively gathering can be enriching and is just a short drive away from the Oregon Convention Center. Wandering through the maze of stalls, you’ll find an array of handcrafted delights – from jewelry to leather goods, pottery to fine art – all lovingly crafted by the city’s talented makers. The sounds of live music and the aroma of delectable local cuisine will captivate your senses, while the palpable sense of community will remind you of the inclusive spirit that saturates Portland's identity. Whether you're making a purchase or simply taking in the scene, the Saturday Market encapsulates the heart and soul of the city, making it a must-visit destination.
---
With these five enriching experiences, your DrupalCon excursion will extend far beyond the convention doors. You'll build lasting connections with both the Drupal community and the diverse tapestry of Portland. Whether you're charting a solo adventure or teaming up with fellow tech enthusiasts, these local highlights are poised to enhance your trip with a delightful blend of tranquility, creativity, and community.
Congratulations to the inaugural members of the new Project Update Working Group.
This is a new working group tasked with helping maintainers prepare contributed projects for the next major release of Drupal core.
The inaugural members are as follows:
Norah Medlin (tekNorah) (provisional)
Vladimir Roudakov (vladimiraus)
Sven Decabooter (svendecabooter)
Naveen Valecha (naveenvalecha)
Kristen Pol (Kristen Pol)
Matt Glaman (mglaman)
Darren Oh (Darren Oh)
Mark Casias (markie)
Kim Pepper (kim.pepper)
Björn Brala (bbrala)
Lucas Hedding (heddn)
Pedro Cambra (pcambra)
Allan Chappell (generalredneck)
Jakob Perry (japerry)
Timo Huisman (Timo Huisman) (provisional)
The group will work in the coming weeks to establish processes and changes required to Drupal.org to facilitate the role.
If you wish to get in touch and say congratulations, you can find them in the #project-update-working-group channel on slack.
Senior Drupal Engineer
Mike has been part of the Four Kitchens crew since 2018, where he works as a senior engineer and tech lead for a variety of Drupal and WordPress projects.
January 1, 1970
The Columbia SPS homepage
For higher ed institutions, the need to manage updates for multiple websites is an ongoing struggle. Each site should reflect the distinct identity of a given school or department. But as each website’s CMS, frontend design, and backend architecture diverge, any organization will need to grapple with the necessary upkeep.
Columbia School of Professional Studies (SPS) faced this situation with three separate websites. One site presents summer courses, another targets high school students with pre-college offerings, and the third is the traditional SPS website. Each domain serves a different audience and is managed by a small team.
As each website continued to diverge, users found it difficult to recognize them as part of the same school. Worse yet, the three websites were on two different versions of Drupal and had grown difficult to maintain, as one platform was reaching its end of life.
SPS came to Four Kitchens seeking an upstream solution to provide relief. In this preview of an upcoming presentation at DrupalCon Portland 2024’s Higher Education Summit, the Config Split module has a newer feature that cleared the way for an efficient resolution.
Columbia SPS needed a solution that would resolve multiple nagging issues. In much the same way that a design system streamlines operations by creating a centralized content resource, an upstream platform enables multiple websites to share a single codebase.
Along with bringing the organization’s Drupal instances into alignment and reducing technical debt, the approach offered three core advantages:
To make sure each site could still offer a distinct experience, Columbia didn’t want to share content or merge each website into one. They primarily wanted to make each easier to manage for their team.
Creating an upstream platform for Columbia SPS hinged on the Configuration Split Drupal module. Put simply, this module allows you to apply a different configuration to a website to suit specific scenarios. You can use Config Split to make sure you only see error logs on your test environment (not your live site).
The Columbia SPS Summer Session website
However, Columbia SPS still wanted its three websites to offer distinct features. To enable this flexibility, we used a newer feature in the 2.x versions of the module called Config Patch. This feature allows Columbia SPS to apply part of a website configuration to each website.
For example, each university website may share the same article structure. But one website can support a distinctive CTA component at the bottom. Columbia SPS now has that flexibility — and it doesn’t cause chaos from a website maintenance standpoint.
With Config Patch, Columbia can use a single code repository to maintain three sites that have their own distinct details within the same baseline features. We also provided SPS with a base demo site that keeps Config Split from allowing too much flexibility. Adding rules to settings.php provides a home for the logic for each site to make sure they follow the proper configuration.
Plus, the demo site functions as a mold if the organization needs to add a new website. Along with providing support for the organization’s current needs, the upstream platform provides support for the future.
Implementing an upstream solution for Columbia SPS enabled the university to run its separate sites more efficiently and provide a more consistent experience. Just as importantly, the institution escaped the shadow of a Drupal 7 migration, which stands as a major benefit for the organization.
However, adopting an upstream platform carries its own complications. For all the advantages Columbia SPS gained, the organization also needs to be mindful of a few potential pitfalls of an upstream platform:
Navigating the specific needs for multiple websites is a persistent challenge for higher ed institutions. On the one hand, delivering a consistent experience drawn from a single codebase is easier to manage, especially for a small, centralized IT team. On the other hand, individual departments and schools have specific design and functionality needs. They should be able to offer website experiences distinct from the look and feel of your core website.
With an upstream platform, you gain the functionality to serve both needs. The solution introduces new complexity, but with an experienced development partner, a multisite platform allows your team to work more efficiently. Better still, if your organization needs to maintain multiple platforms as your websites have diverged, you gain key benefits from addressing needed upgrades.
Would this kind of solution help your organization? Let us know how we can help.
If you’re going to DrupalCon Portland 2024, please make sure to attend the Higher Education Summit to hear directly from Mike and the team at Columbia SPS.
Where: Oregon Convention Center (777 NE Martin Luther King Jr. Blvd, Portland, OR 97232), Room C123-124
When: Thursday, May 9, 2024, 9:00am – 4:00pm
For tickets and session details, click here.
The post Aligning diverging websites with an upstream platform through Drupal appeared first on Four Kitchens.