Some good thoughts but I mainly submitted this to highlight how snappy Aaron's site is.. What kind of magic is that?
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.
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
Like the last point. I am still not sure whether the problem is in finding the right theme or being able to customize the chosen theme.
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
A funny - and useful - read for WordCamp organizers and attendees.
Last year, the WordCamp US organizing team asked me to assist them with putting all the selected talks into the grid. It was a lot of fun and a challenge, but I was able to do it because I had a set of personas ready. Personas are regularly used in web design to make sure that you are solving your users. Usability.gov describes effective personas as having these five characteristics:
Represent a major user group for your website
Express and focus on the major needs and expectations of the most important user groups
Give a clear picture of the user’s expectations and how they’re likely to use the site
Aid in uncovering universal features and functionality
Describe real people with backgrounds, goals, and values
When looking through the attendee list from previous WordCamps, looking through pictures from those camps, and drawing on the dozens of WordCamps I have attended, I came up with ten personas that I used. My goal was to make sure whenever possible, each persona would want to attend only 1 session per slot (minimize FOMO), If there was nothing in one slot for a persona, there absolutely was something in the session that followed.
Adjusting usabilities Persona guidelines
What if we had a twenty sixteen theme idea session and that the theme could be released with ReactJS and WP-API?
If you're a developer and/or contributor, take a few minutes out to read this. Nice quote: "User trust isn’t something you earn and then just get to keep forever. It’s a maintenance relationship."
Helen Hou-Sandi, in response to someone suggesting a large rewrite in slack wrote this: Your plan as I understand it disregards a couple of core WordPress philosophies/practices: striving for maintenance of backwards-compatibility, and that an X.0 release is no more significant than X.1 or Y.9 (this is closely related to maintaining back-compat, in that something like semantic versioning is less meaningful for WordPress core).
Generally, the most successful refactorings in core have been done in support of features being built, whether that’s a user- or dev-focused feature. It’s not that core code can’t be improved (clearly it can), it’s that better decisions regarding back-compat and, more importantly, forward-compat for an API or other bit of code can be made when one eye is on practical application.
As a user centric project, WordPress chooses philosophies that put the user first. There is also an unwritten philosophy point that many committers talk about which is that User Trust Matters. What that means to me is that users trust WordPress for running businesses, sharing content, and engaging with their own users. User trust must be maintained in order to
Interesting feedback, with answers to questions on biggest challenges for publishing companies in making Gutenberg better, what matters most, validation hooks, and more. Nice to hear more feedback!
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.
#wcpub unconference session on Gutenberg and how Publishers might be impacted. Conversation lead by @aaronjorbin pic.twitter.com/clwqLZ7Yah
— Dwayne McDaniel (@McDwayne) August 18, 2017
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,
Not just a nice little plugin to help with search engines, but also a nice example of how the WordPress community works.
Last week, I saw a tweet that identified a challenge for the WordPress UI: I REALLY wish this was easier to spot on WordPress installs. So many sites are launching with privacy enabled https://t.co/X12J8tdYVy
I wasn't alone in seeing this as an issue that was worth solving:
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.
Download BRAD TODAY
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
Aaron Jorbin compiles some interesting stats for 2016. Example: The total number of commits is down from 5106 to 2967.
I’m sharing these stats with the duel caveat that commits aren’t a great measure of impact and that commits only represent one type of core contribution. When I talk about employers it’s with the caveat that some people change jobs. Also not everyone works on donated time. Now that I have looked at these numbers for two years I think that it’s interesting to see the trends. In 2015 31 people with 16 unique employers committed to WordPress core. In 2016 it’s 37 people with 20 employees.
The employer with the highest percentage of commits in 2016 remains Automattic at 14.66%. This is down from 20.37%.
The individual with the greatest number of commits is @ocean90 at 360. Last year it was @wonderboymusic.
The total number of commits is down from 5106 to 2967. While that number is big I don’t think it’s necessarily bad.
For props this year 750 individuals got props with 396 for the first time. This is up from 721 total and 379 first timers in 2015. 91 people contributed to every release in 2016 vs 94 in 2015.
"If you contribute to one release, there is a 46% chance you will contribute to the next release. "
I posted a graph of new WordPress contributors per release and Brian Krogsgard had some questions that I decided to look into. Mostly he wanted to know how well WordPress did at maintaining contributors. So I made some more graphs. In general, past contributions as a predictor of future contributions are pretty consistent across releases. If you contribute to one release, there is a 46% chance you will contribute to the next release. Overall, 44% of individuals who have contributed, have contributed at least twice. While on its head, that means 56% of people only contributed once, digging in I was able to find that from 3.2 to 4.3, if you contribute, there is a 70% chance you will contribute again.
A total of 12 individuals contributed to all 14 versions analyzed and 57 contributed to 10 or more versions.
What does this mean? Mostly that we need to continue watching for change in this regard. Outside of 4.4, WordPress has remained consistent. Adding the git mirrors didn’t change anything. Switching to including the build tools and tests in the repo didn’t either. As the WordPress contribution process continues to evolve, it will be interesting to see what if anything moves
Some interesting thoughts on Gutenberg and it's current state. These are all comments on the usage of the app - and I'm sure many of the concerns will be addressed. I think there's a lot of potential in Gutenberg but they need to make sure it at least matches the current editor in terms of functionality.
Gutenberg is being developed as the next generation WordPress editor. I made my first contribution earlier today. Nothing big, but something that will hopefully help people test it. The contribution process was , but for end users, that’s not the important thing. What is important is the actual editor. I’ve seen talk that Gutenberg is in “Open Beta” now, but I think calling this beta software is still premature. I think there is plenty that will change between now and any possible inclusion in WordPress core for Gutenberg. Here are my random thoughts and my first reactions to using Gutenberg.
It’s pretty. And Fast. I never thought of the post editor as being slow, but there is something about Gutenberg that makes it feel fast.
There are a lot of rough edges. It’s hard to know what is a bug, what is intentional, what just hasn’t been done yet, and what hasn’t been thought of.
There is an option for “Drop Cap” that doesn’t seem to do anything on the front end yet.
I’ve also never intentionally been able to highlight multiple blocks at once, but I’ve sure done it on accident a lot.
I can’t seem to delete
New features to the grunt-patch-wordpress which adds 2 cool features: GitHub URL Support and uploading patches from command line.
Today I released an update to grunt-patch-wordpress which adds 2 cool features. GitHub URL support. You can now use grunt patch:https://github.com/aaronjorbin/develop.wordpress/pull/3 with any copy of WordPress on GitHub. No longer will you need to download the patch manually. Works for both core and develop mirrors on GitHub. This feature was suggested by Helen 侯-Sandí
Upload patches directly from the command line. No longer will you need to create a patch and manually upload it to trac. grunt upload_patch:20000 will upload a patch to the appropriate ticket after a user enters a WordPress.org username and password. This is limited to users with the appropriate XML-RPC privileges in trac (right now, that is just bug gardeners). You still need to manually add the `has patch` keyword. This feature was added by Eric Andrew Lewis. Thanks Eric!
Full changelog: https://github.com/aaronjorbin/grunt-patch-wordpress/compare/0.3.0…0.4.0
Thanks to the following additional people for contributing to this release: Stephen Edgar and Michael Beil. Further enhancements to make it easier to work with WordPress Trac are always welcome. Also, I would love a logo or wapuu for grunt-patch-wordpress,
A look at what we would be missing if WordPress had no female contributors (answer: a lot). I love how diverse WordPress and its community is.
If WordPress had no Woman contributors, 4.7 wouldn’t have had a release lead. If WordPress had no Woman contributors, The queue for plugin reviews would rarely be empty.
If WordPress had no Woman contributors, many WordCamps would lack lead organizers, speaker wranglers and sponsor wranglers.
If WordPress had no Woman contributors, most WordCamps never would have been approved to be organized.
If WordPress had no Woman contributors, The REST-API never would have made it into core.
If WordPress had no Woman contributors, WordPress for Dummies never would have been written.
If WordPress had no Woman contributors, many support questions would go unanswered.
If WordPress had no Woman contributors, the training team wouldn’t have created lesson plans to help anyone teach WordPress.
If WordPress had no Woman contributors, most waapuu would never have been designed.
If WordPress had no Woman contributors, WordPress would be inaccessible to many people using assistive technology.
If WordPress had no Woman contributors, WordPress wouldn’t be fully translated in over 60 languages.
There is no area of WordPress that is untouched by the contributions of Woman. In honor of International
A great idea! "I wouldn’t be surprised to find out that WordPress runs on well over 100,000 different stacks."
So this is a half-baked idea. Well, maybe 3/4 baked since I’ve mentioned it to a few people. Right now, Automated testing in WordPress is based on Travis CI. Which works pretty well. Tests are run on 1 OS vs 8 versions of PHP (plus hhvm, but those don’t pass) which based on my completely unscientific estimates covers less than 0.1% of the actual WordPress userbase. If WordPress really wants to do quality automated testing, we need to rely on the people hosting sites to test vs their stack. To do that, Core needs to provide an infrastructure that both encourages and enables easy automated testing.
It’s not that the current test matrix is bad, but it currently is only covering a small corner of the true test matrix.
What I would like to see is an API that hosts (both shared and dedicated) could use to register their unique setups for automated testing. Using PUBSUBHUB, WordPress Core would signal that a change has taken place. Then, the hosts could run their setup(s) vs the new version of trunk. They could run both a plain version of trunk, but also perhaps the version that includes everything they install as a part of a new site and whatever “one click installer”
2017 will end the year with 1731 changesets to trunk. The employer who was most responsible for WordPress commits this year was Yoast!
2017 is coming to a close, and unless someone commits something very soon, WordPress Core development is at rest (since we have an API to do that now). This is the third year I've compiled these stats, see the 2016 committer stats for some of the background information. I'm going to share the stats and then share my reactions to seeing them. An important caveat, in the post I'll mention employers but we need to remember that people change jobs and that not everyone works on donated time. In fact, the vast majority of WordPress core committers are volunteering their time when they review, write, and commit code to WordPress.
2017 will end the year with 1731 changesets to trunk. This is down from 2967 last year. These changesets were committed by 35 individuals, down from 37 in 2016.
2017's most prolific committer was Sergey Biryukov who was responsible for 20.57% of all WordPress commits. He takes this crown from Dominik Schilling. In raw numbers, Dominick had 4 more commits in 2016 than Sergey did in 2017. This is the first time since I started keeping these stats that a non-release lead has had the lead.
Other notable committers (by volume of commits) in 2017 were Weston Ruter (18.14%)