Getting started with Jest

In the past, my automated testing for javascript was done in either QUnit if it was a browser app or Mocha if it was a node app. On a new project, I decided to kick the tires on Jest and thus far, I really like it. It did have a bit of a learning curve through to get it up and running, but now writing tests in it feels natural and is going well. Here are a couple of things I've learned thus far.

Jest defaults to an outdated version of jsdom

.jsdom added support for HTMLElement.dataset in a recent version. However, due to minimum node version support differences, Jest by default uses an older version of jsdom.  Switching to the latest version though turned out to be fairly easy. I installed jest-environment-jsdom-latest and changed my package.json to run jest with "testEnvironment": "jsdom-latest". Alternatively I could have used --env=jsdom-latest.

Steal Configs From elsewhere

It's really easy to run down the rabbit hole of learning everything about how to set up a tool before learning if you want to actually use it. To get started, I stole some of the config from an ejected create-react-app application and looked at the docs for using jest with webpack. That was all I needed.

Use .resolves() for your promises

Unwrapping a promise and using .resolves() allows me to easily unwrap promises and keep my expectation in a single chain.  It feels as much like magic to me as promises did the first time I used them.

Additional Resources 

Overall, I'm excited to continue playing with Jest. 

Why I love Captioning for Conferences

I had been to conferences with live transcription before, but SRCCON 2014 was my first time seeing them at a mainstream conference. The transcription services even inspired a battle between a debate champion and the captioner. Three years later, and I’ve gone back the transcripts a few times a phrase or remind myself of the conversation.

I am generally a person without any hearing related disability. I’m sure years of playing music, working concerts, and listening to headphones has left me with some hearing loss, but in general, I can hear at conferences. Except sometimes the room is loud. Or a person near me is talking. Or the mic isn’t held close enough to the speaker. In those cases, I’m reminded of one of the top reasons I love live captioning for tech conferences.

Anyone in the room can become a non-hearing person

Anyone has been to a conference has sat near someone that needed to comment on the presentation while it is going on.  I’m sorry if that person was me for you. Having the ability to see what was said, helps me when I miss something that was spoken.

Real-time captioning also allows the audience to be less focused on taking notes since the talk is already available in text. Some people are less auditory of learners and thus the written record allows them
learn using a method that works better for them.

Transcripts allow the speaker to see what we said

Like many speakers, I have verbal ticks that I fall back on. Transcripts allow me to see how many times I say “you know” or begin a sentence with “so”. The live transcript can also be utilized to help create a blog post from your talk.

People need it to attend

As much as captions help me, they can make the difference between someone being able to learn at an event and someone not being able to learn. 360 million people have disabling hearing loss. Captioning of conferences can help make it possible for that otherwise could not participate to participate.

The other day, a video made the rounds of a man being gifted Enchroma glasses and experiencing color for the first time.  Helen Hou-Sandí asked the question “What if we thought about web accessibility work as bringing these moments to people?”  What if we also thought about event accessibility as bringing these moments to people?

The right to learn is the right to earn. Education, both formal and informal, is the foundation for advancement. Captioning can break down a barrier that prevents people from learning. By enabling all people to learn, we enable all people to earn.

Gutenberg and Publishers: unconference notes from WordCamp for Publishers

At WordCamp for Publishers, I hosted an unconference session on "Gutenberg and Publishers". There were forty people overflowing a conference room who worked at agencies, publishers, universities, hosting companies, as freelance developers and writers, and one person who described their affiliation as "I left my backpack at the bar last night and lost my name badge, and that's representative of my professional career."

The people in the room had all largely used Gutenberg in some way before the session. Almost the entire room had at least 5 custom meta boxes on the editor screen, over two thirds had at least 10 custom meta boxes, and a few had more than 20. The vast majority used custom taxonomies, many of which had at least one using a UI other than the default taxonomy UI. 


After everyone introduced themselves, I gave a brief introduction to Gutenberg, including demonstrating some of its features. I also explained the block based approach, the desire to eliminate mystery meat, and that Gutenberg is still in very active development with things changing all the time.  After that, I kicked off the discussion.

What do you view as the biggest challenge for publishing companies in making the editor better?

  • Long form layouts. Even with something like short cake to render short codes, you still don't get the full-width experience that you do in a full post. A lot of bouncing back and forth to compare sizes.
  • Everything hooked on to save post and how that negatively impacts the actual saving experience.
  • Collaborative editing and the work around to collaborative editing, which is moving from a thirdparty tool, Google Docs, some other workflow. Bringing that integration into WordPress.
  • Allowing users to preview a prepublished preview version of the post in, the home and the category views. Platform Preview: How do posts look different on different size devices, different platforms, whatever.

What are the customization points that matter most Publishers for the editor? On your site, what's the most custom part of the editor in your eyes?

  • Probably our biggest anxiety around Gutenberg, what is the fate of that metadata management system under the new Gutenberg regime.
  • Taxonomy customization comes in multiple forms:
    • A taxonomy that's a single value, a drop down for it.
    • A taxonomy that can have zero or one with radios and a "clear" button.
    • We'll group multiple taxonomies together in a single meta box that maybe has a repeating field either an autocomplete or a drop down where you select. So there might be five taxonomies which each can have multiple terms.
    • I've had numerous times is where I want a hierarchical taxonomy, but I wanted to limit to two levels. And another is a really long list of taxonomy terms. And so I want to get an audit complete. And then when you select one, it adds to the list of ones that are selected. And have a check box next to the ones that you decide you want to do later. So there's a whole bunch of different ways to do taxonomy.
    • We end up doing a lot of custom validation around taxonomies. We check this one taxonomy, you can check three other of this other type, or X, Z, Z. And right now, I think there isn't sort of a builtin validation mechanism to do enforcement on the layout or on taxonomy.
    • So a couple that I've used as well, in addition to the ones mentioned, is where taxonomies can't be you can choose taxonomies, but you can't add new ones. I think that's probably fairly common.
    • Taxonomies where you must select one, but there's no prepopulated one. There's no default. And taxonomies where you have to select one before you can save the post as well. And it has to pass a save checklist validation thing.
  • I think just validation in the editor as a whole is a wonderful thing that can help us, as developers, make richer experiences. So I can think of other use cases beyond taxonomies. But say like someone has a rich media embed. Is it tagged correctly extremely in another place? Say someone has a citation they're using. Has it been factchecked? Has it been proven? Validation is currently very difficult. Unless you're doing something extremely custom. Which takes a lot of time and a lot of maintenance.

What other hooks for validation do people think are needed?

  • Knowing which block is above and below in some way so that you can enforce not stacking seven videos on top of each other. It's really easy to write a beautiful post in Gutenberg and it's really easy to write a horrible post too.
  • We work with a lot of news agencies. And something that they have been asking us about is how to handle packages. This article has a sub, a side bar. This article has eight photos connected to it. Plus, a graphic, plus, an opinion piece. It would be really great to be able to create that kind of content, either taxonomy or association for future output. 
  • Per context, content. Because for us WordPress is the entry point for web, mobile, and print. So right now we have a tabbed interface with multiple tiny MCE editors to prepare content for all three. Videos make no sense for print. So with Gutenberg to switch over and see the printenabled blocks, but not see the webenabled ones. Or native. Because native will only support certain things too.
  • One opportunity Gutenberg might have is less developercentric and more journalistic is, so if you decide on an atomic unit of writing called the Block, you could annotate this. And you could preserve reporter's notes as to the source of the information. This was from an interview. So a year from now, that reporter is long gone. Right now the source material is lost, scrawled into paper notebooks and stuff like that. So I like that opportunity for this. Each Block could have a source that is published or not published or whatever.
  • One point to accept further on your note about comments within block level, it would be awesome if there was a hook to create additional kinds of data. So not just comments, but also, again, I'm thinking back clarifications. I'm thinking custom meta about meta. Which is weird to say, but it's useful, because at some point when we have to look at this, if a copy editor comes in and wants to look at the posts and validate or triple check, whatever that might be, having a starting point or a place to view all that information, that doesn't sit there baked on the side under the context menu. But you can view that directly next to it.
    • That opens up possibilities around having blocker paragraph levels. Like this has been signed off by the copy editor. Like the collaborative features. The photo editor signed off on a picture. And then you can easily view what paragraphs haven't been signed off. Or if a paragraph changes, the sign off automatically turns off and it needs to get resigned off on.
    • And if there are tasks associated with that article that have to go through revisions or approval or whatever might be. Those become part of the dashboard. An article requires work? Who has to do that work? You can associate more information beyond just the article. Even though we currently do this in our own individual workflows, some of the workflows can be sussed out by having the additional information.
    • Kind of along those lines, the side effects of editing a block. One thing I want to point out. It's built with React and Redux. If you're not familiar with Redux, when things change, you can see the actions that have been changing. And you can hook into those changes and do something else in WordPress, right? So you have a block or let's say somebody is typing a paragraph and you just find that, okay, this is for a publisher, we need to factcheck every paragraph. Whatever. You can have that, as they finish the article, use Redux to send that off to validation server as they're writing the next block. And if it doesn't pass validation or fact checking, maybe the state changes and it's highlighted red.
    • And actually, I can't validate that you talked to this person. And they respond on a different system using the heart beat API or whatever. And within 15 seconds, you my light that, they're off working fact checking. I'm still working on content.

Data Storage

  • Would it be a good idea to maybe have an ability to save this in a JSON format and keep that all together with its own components being stacked? So I think that might help a lot of us. Especially if you're doing things that are WP API based. And headless. 
  • The HTML comments as structured data is Shortcodes reloaded. It's too easy to break. 
  • It's certainly possible to store data elsewhere and then hydrate it for the editor. 

Other Observations and thoughts

  • We do have prototype support for WPGraphQL for Gutenberg. It uses the blocks parser to transform the content. 
  • Gutenberg opens up the possibility for front end editing in the customizer since it's also essentially a sidebar and main content area like Gutenberg. 
  • We had an idea we played with in shortcake for a little bit which was contextual rendering of the short code so, for instance, to say it's a YouTube embed that's being rendered under the RSS view. Maybe you don't want us in the iFrame. You want the YouTube API and get an image instead to replace it. I feel there's a lot of adaptive content ideas you could play with around that.
  • For us, posts end up being three different pieces of content. So if they need to fix a typo in one, it's three spots currently. With something like that, if you had context for a block, it would be the same source of truth. If they change here, the context is just a visual thing.
  • I don't know if this is being thought about but right now you go to get a new post and you basically, have a blank screen, a blank canvas. And if you have task workers you want to, give them a bunch of different things to fill out. I don't know if that's part of the vision to be able to create those task worker forms as well.
  • And another is kind of adaptive posts where you start entering things in and depending on what you select, I'll use the term "Post type" here. But I don't mean specific post type. You select certain fields and get different subfields that you would be able to fill in.
  • There were two ideas that came from a workshop yesterday. I wanted to share these with you. One of them was, building in the blocks themselves rules and best practices. So, you know, that could include things like a link catcher sort of validation process. Another one was to integrate context into distribution. This block will work better at this time. Or in these conditions. 
  • I think a lot of what we're talking about with the blocks with, deciding AMP versus mobile, what it all kind of boils down to is setting specific custom meta for the blocks individually and then saving them as a whole. That would allow you to do your different views because you would be filtering out based on just, I want to see just the AMP version of this. So anything that is either not flagged general or AMP, I'll just not put in. But I have no idea how that would work elegantly in the comments. The current system.

Closing Thoughts

After the session, a few of us chatted further.  One of the ideas discussed was a "Block Council", essentially a group to collaborate on blocks so that there aren't 15 different Facebook blocks floating around (i.e., issues we all see with widgets and plugins). Overall, there is a lot of anxiety around the unknowns of Gutenberg, but most of the people are excited for what Gutenberg offers. There is a lot of work remaining, but the more people that can be involved, the more likely Gutenberg is to be successful.

This post would not have been possible without the transcription by Amanda Lundberg from White Coat Captioning who live captioned the session. Most words are direct from the speaker's mouth. Some have been lightly edited for easier reading. 

Random Thoughts on…WordPress?

I wasn't sure how to title this one. I went to the WordPress NYC "Help Desk" meet-up on Wednesday and learned a lot about things users of WordPress are struggling with.   So I guess in some ways it is random thoughts on me learning more.

  • The biggest thing people struggle with is themes they bought off Theme Forest. Most of them are hard to configure and include so many damn options that it's easy to screw up a site and get lost trying to fix it.
  • One of the worst parts of these themes is that when there is an issue, I can't just open up the source from everywhere in the world and trouble shoot.  If they used themes from WordPress.org, I could help them.
  • The first question someone asked me about related to Gutenberg. People are paying attention to it. I don't know if this is a good or a bad thing. 
  • I was referred to as a WordPress Celebrity and it was a bit off putting. The people that make and contribute to WordPress are just people. Some of us have the privilege of contributing to WordPress. Others have the privilege of maintaining WordPress. But both come from points of privilege as they require time, energy, and money (for a computer, internet access, etc.),  but ultimately we shouldn't be considered celebrities. That's not to say it isn't nice to be thanked every once in a while, but I don't know anyone who contributes to WordPress for fame. 
  • It's important that we don't assume people know the difference between WordPress.org and WordPress.com. Especially with the lines getting more and more blurred due to "WordPress.com Business".
  • Finding the right theme is still #HardAsFuck for most users. I think that no matter how great WordPress the application
    is, until people find the right theme for them, we are likely to lose them.

Mini Tracks for Technical Conferences

Conference organizing comes with many challenges. Attendees are going to complain about the food. Someone is going to think "There aren't enough SEO/Security/Regular Expression/". Overall, you are not going to be able to make everyone happy. But one way to increase attendee hapiness and make sure people walk away with solid lessons is by curating mini tracks.

Your job as an organizer is to curate the experience and lessons you want your attendees to have. You shouldn't pick a talk because it's popular, you should pick talks that tell the story you are aiming to tell. The story you are telling is one that takes its characters and lessons from the speakers and talks you choose.

What will the attendees be talking about tomorrow? 

The attendees of a conference are going to go back to work, are going to rejoin their professional circles, and bring things with them. Unless you are doing longer workshops, these are going to often be the themes and lessons that are weaved throughout the day. I like to create "mini tracks" of a couple of talks that build upon a theme.  

For example at a WordCamp, a mini track on "Fundamentals of WordPress Development" could include talks on custom post types, child themes, the user and role APIs and post meta. These talks may be at multiple levels, but that's ok.  They all build upon a thesis of "WordPress has multiple ways to be extended". A new to development person may gain an understanding of how a plugin they use works and may come up with a new idea. A new to WordPress developer may gain an understanding of how to structure a custom plugin. An experienced WordPress developer may gain a new way of thinking about when to use one API over an other. 

Some themes come in different styles than others. I've seen a number of different types of mini tracks including ones focused on a vertical ( Real Estate, Education, Enterprise, etc ), those focused on a type of worker ( Freelancer, Manager of People, Remote Worker, etc ), or on more generalized theme (Advancing as a Developer, Redesigning Websites, Social Media). 

Mini Tracks in Action

Mini tracks were something I first observed for a conference at WordCamp Boston 2011. This conference went so far as to print the names of these tracks on the schedule. (Sidenote: The greatest technical talk I've ever seen at a WordCamp was at this WordCamp. )

By grouping three "Enterprise" talks together, an attendee who wanted to gain an understanding about enterprise could make sure they were setup in one location to do so. And while there, they could learn about growing teams, growing code bases, and growing sites. With Boston having so many world class universities, the education track was a natural choice.  This track included engineering talks, strategy talks, and more. It was about a common interest, rather than common skill that united these talks.

Another example can be found at WordCamp DC 2017 were three talks in a row looked at questions concerning equality, inclusion, and intersectionality in three very different ways. Attendees could see these three talks and walk away inspired and with a better understanding of how they could use WordPress in an entirely different way.

If you start working on a conference schedule, consider what the lessons are that you want the attendees to walk away with. Think about the themes in the talks. Schedule something "Hard" or "Complex" or "Technical" where it might not be obvious. Allow people to learn something they weren't ready to learn. Give them something to walk away with that may not be useful for years, but might stick with them. 

A Few Use Cases I Would Like To See Solved In Gutenberg

While I've used WordPress in many ways over the last nearly ten years, I primarily spend my time working on two publications: Scary Mommy and Cafe. "Big Media" publications have challenges and use cases that are different than standard WordPress sites. As Gutenberg continues to evolve, there are a number of use cases that I see as needing to be accommodated. Most of these are things that don't need to be solved "out of the box", but that the extensibility of Gutenberg should accommodate.

It's possible that some of these use cases are already accounted for, but that that the documentation on them is lacking. 

Publication Requirements

Before "Publish" can be pressed, a number of steps need to happen. This could be selecting a featured image, making sure some taxonomies are properly filled out, or that there is 2nd sign off. This takes the form from the super basic such as what make.wordpress.org sites use ( an "Are You Sure" checkbox that must be checked before the publish button is enabled) to the complex custom plugins that are prevalent.

The important part is that there needs to be a documented and extensible way of only allowing posts to be published when other criteria have been met. 

Block Removal

Out of the box, Gutenberg has alot of blocks.  Not every site needs a "Verse" block, and there needs to be a way to remove it. As the classic saying goes, "Design is done not when there is nothing left to add, but instead when there is nothing left to take away".  The ability to remove blocks is necessary for the success of Gutenberg.

Block Modification

Currently, the headings block in Gutenberg allows for selecting H2, H3, and H4. What about sites that also support H5? What about sites that only use H2?  There is a need to make minor modifications to many of the default blocks. While some sites and some users benefit from allowing the content producer to select the alignment of blocks, other sites have strict rules and want to lock it down.

Block Rules

There is a need for blocks such as subheads that only exist after the title. Similarly, there may be editorial rules such as never using more than 3 twitter embeds, or always having at least two paragraphs between headings. These should be a way to enforce these rules.

As Gutenberg continues to evolve, more modification requirements are sure to come up. It's going to take years before all sites can use Gutenberg due to the millions of dollars invested in custom editorial processes, but these are my initial modification use cases.  What are yours?

BRAD: Better Responsibility Around Discoverability

Last week, I saw a tweet that identified a challenge for the WordPress UI:

https://twitter.com/williamsba/status/885520668154089472

I wasn’t alone in seeing this as an issue that was worth solving:

https://twitter.com/norcross/status/885582016456130560

Knowing that plugins are best when they are built and supported by teams rather than individuals, Norcross and I started collaborating (though in the end, the majority of the code was written by him). What we came up with a plugin to improve the experience for site creators. As the responses to Mr. Williams tweet shows, It’s very common to mark a site as inaccessible to search engines and then forget to uncheck that setting when it comes time to launch.

BRAD aims to solve this by moving the notice about search engine discouragement to the top of the dashboard.  It also becomes a recurring dismissable notification.

  • Every week, there is a check to see if the site is still hidden from search engines, and if it is the notice comes back
  • If you change the siteurl or home options, then the notice comes back (note, you need to change these via the UI or via wp-cli, directly changing the DB)

BRAD is already loved by many

I was lost before BRAD

Before this plugin, I never knew if my site was excluded from search engines or not. And if it was, where the heck did they move the “Discourage search engines from indexing this site” checkbox to?

Thank you, BRAD

Heavy praise from the leader of a great WordPress Agency!

Life changer!

BRAD literally changed my life – now BRAD tells me where to go every day!

It feels amazing to help change the life of someone who wrote the book on WordPress (over and over again)

If you would like to contribute to BRAD, join us on Github. If you are building sites, add BRAD to your WordPress site today!

Birth of a Community

Seven years ago today, the First WordPress D.C. Meetup that was focused on a continuity of community took place. Tomorrow the first WordCampDC kicks off. It's been a heck of a journey. 

I've been gone from the community for a few years.  I know the community has continued to evolve and grow, but for the first 3 years of its existence, I was honored to serve it as one of the organizers. Looking back, there are a number of things that stand out to me about those early days of WordPress DC. 

The DC community has helped many people grow. Many people took on larger roles in the WordPress community in part due to the involvement in the meetup. Committers, Lead Developers, Training Team Leads, Speakers, Meetup Organizers, Meetup Organizer Organizers, Code Contributors, Testers, Theme Reviewers, Accessibility Team Leads and Support team members. You would be hard pressed to find a community that has done more for WordPress.

I know of countless people who got jobs because they started networking at the WordPress DC meetup. Early on, we stole from the PHP meetup the idea of asking "Who's hiring, Who's looking" at the end of the meetup and giving people a moment to introduce themselves.

Early on, the decision was made to focus the main monthly meetup on users of WordPress, with the idea that designers and developers can always learn more about users and for many of them, networking after the meetup could be even more valuable than hearing yet another talk about custom walkers. We did hold a number of special events especially aimed at developers and designers though. We tried "Brown Bag Lunches", Saturday afternoon pre-release testing sessions, Friday Night's with
Mitcho (sadly, only one since he was only in town one night), and "Happiness Socials" focused on helping each other with issues. 

The collaboration the meetup had with the broader DC community helped WordPressDC standout.  The Open Source BBQ become the summer event that everyone looked forward to.

This isn't to say the meetup group was perfect.  It took us a too long to realize that our speaker roster was heavily male, and leaned young.  Thankfully, we realized it before it poisoned the community.  In many ways, it reminds me of one of my favorite tweets. We fucked up, but then we tried not to make the same mistake again. 

Finally, the friendships that grew and developed can't be understated. For many of us, The second Tuesday of the month became a highlight that we didn't want to miss. Many people I met or got to know better through the WordPressDC community are people I still consider friends today.

Happy Birthday WordPressDC.  Tomorrow, we celebrate with the first WordCamp DC!

WordPress Serves Many Masters

I have used WordPress in a number of different ways over the last (just shy of )10 years.  I got my start building a blog that my friends I and I wrote
satire on. We got a bit of a following (I remember the first time we hit 1000 views in a day on one article, it was exciting). I then moved on to building a site for a movie my friends and I wanted to make, before starting freelancing and being exposed to many sites.

Freelancing Days

Over the course of about two and a half years of freelancing, I worked with dozens of clients. They most commonly were:

  • Comedians
  • Small non-profits.
  • Small Businesses and Restaurants
  • An SEO consultant on products that he offered (my first foray into product development rather than developing primarily for marketing) 

A site I worked onwhile freelancing

The first three groups of sites make up a large percentage of WordPress sites. There are freelancers and agencies in just about every town/city in the world helping Individuals, smaller non-profits, small businesses, and restaurants get online every day. In general, the organization has little knowledge about what tools they should use, and doesn't care what WordPress is. These are the passive users of WordPress.

The Enterprise

I then moved to a couple of large organizations( ranging from 50 to 500,000 employees). Here, WordPress was chosen by the organization, but it was never the main technology of the site.  It was a supplement

WordPress supplemented the technology, rather than being its base.

Each of these organizations had at least 5 engineers, but it was rarely more than one or two people who worked on WordPress, and outside of security updates, months would go by without any work being done to WordPress from a coding standpoint.  At one organization during a major redesign, the only reason WordPress was updated to match the site design was due to other tasks taking less time than anticipated.  

Big Media

Some of the biggest WordPress sites (at the time) were at Condé Nast. The New Yorker switching to WordPress received praise from Matt Mullenweg (twice!), while WIRED, Vogue, Bon Appetit, and others were receiving large amounts of page views and allowing editorial teams to seamlessly publish a lot of content. Working with the teams on each of these sites showed me that when you have multiple people all working on WordPress at once, you can make it do whatever you need it to.

Let's Try Something Different

The next step was a short stop building an analytics product with WordPress as the main piece of the backend technology. Essentially, it was using WordPress as a framework. WordPress provided much of what we needed, but we could have just as easily used something that advertises itself as a framework. WordPress gave us a lot of things out of the box though. We didn't need to build a user system, we could use WordPress. We didn't need to build a command line interface, we could use WP-CLI. By using WordPress, we got a lot out of the box for free.

Where I am now

I primarily work on five sites now: two personal, one volunteer non-profit, two for work. My personal sites are "boring" sites. The non-profit site is rather complicated, in that it is a marketing site, a conference registration system, a blog, and an intranet all in one. But it's also not 100% WordPress. Many pieces have been carried forward

And my two work sites? Those are content-heavy media sites. They feature a lot of videos and regularly go viral. 

What WordPress Excels At

The problem for WordPress is that for all of these sites, it works pretty well.  It's far from perfect, but it works. One of the biggest challenges for WordPress, especially when it comes to core features that are used on almost all sites, is that it needs to work for many many use cases. Working on sites of all shapes and sizes has taught me there is rarely one solution that solves every site's problems. 

Serving many masters means people look at WordPress and think "It's just a blog", and it is, it powers this blog.  They look at it and think "It's for small business brochure sites" and it is, it powers many of them.  They look at it and think "It's for big media sites with large staff" and it is, it powers ScaryMommy.

Scale is often thought of as the ability to receive a lot of traffic or handle a lot of users, but scale also means working for many use cases.  This is the type of scale that is the biggest challenge for WordPress. It doesn't have a narrow focus of serving one use case, it has a broad focus of serving all users use cases. Scaling WordPress from a core perspective means providing features that first, work for all, and second can be modified to be better for them as well.  Out of the box, WordPress is never going to solve every use case, but when features make it harder for a use case, we really need to ask ourselves if they should go into core.

Patty Melts

One of the greatest food items is the patty melt. It's a burger, it's a sandwich, it's delicious.

As great dinner sandwiches go, it is hard to beat the patty melt

The patty melts deliciousness comes from the fact that's it's only four components. Rye bread,
hamburger, Cheese, and grilled onions. The simplicity doesn't mean you can't customize it though. Dark, light, and marbled rye each add a different flavor, but the biggest way to customize it though is the choice of cheese. Swiss and American are the two classics, but I think cheddar and muenster also deserve consideration.

BONUS: If you want to make the patty melt even better, make sure to include a pickle on the side for dessert.

A patty melt with a side of fries and pickles in a bag