Disruptive Conversations

As of today, May 1, 2023, 43% of web sites will no longer be able to easily auto-share posts to Twitter. I’m referring, of course, to WordPress, which W3Techs shows as powering around 43% of all sites they scan.

Due to the continued incomprehensible decisions being made by Twitter’s new management, the company behind WordPress, Automattic, has stated that they have discontinued the easy auto-sharing of posts through their hosted WordPress.com service, and also through the Jetpack Social service used by many people (myself included) who operate their own WordPress instances.

The issue is that Twitter decided to start charging for API access, and as Automattic notes:

The cost increase is prohibitive for us to absorb without passing a significant price increase along to you, and we don’t see that as an option. We have attempted to negotiate a path forward, but haven’t been able to reach an agreement in time for Twitter’s May 1 cutoff. 

When you publish a new post on WordPress.com or any WordPress site using Jetpack, it will no longer be automatically shared out to Twitter. You can, of course, manually copy and paste the URL from your site over into Twitter. And you can potentially use some other auto-sharing plugin that has decided to pay Twitter’s API fees. 

Now of course all 43% of web sites using WordPress did NOT use this auto-sharing capability. Many sites did not, but many did - and this allowed Twitter to be the place where you could be notified when someone you followed published something new.

Of all the many ridiculous decisions Twitter’s management has made in the past six months, this excessive changing for API access seems to me to be one of the MOST short-sighted decisions.

One of the reasons I used Twitter was to get the latest news and content. Now Twitter is reducing the amount of content that will be shared.  The API limits are expected to affect public service announcements - and now will affect the sharing of blog posts.

I get that Twitter’s new owners desperately need to figure out ways to make money, but this doesn’t seem to be the right one.

In my mind, if you want your social service to be THE place for people to go for the latest news and content, then you want to reduce any friction involved with posting content INTO your service. 

The reality is that you (Twitter) need that content far more than the content providers need you!

The Good News

There was some good news in the post from Automattic - specifically that they will soon be adding Mastodon auto-sharing, as well as Instagram:

However, we’re adding Instagram and Mastodon very soon. In the meantime, auto-sharing to Tumblr, Facebook, and LinkedIn still works as expected

I don’t personally care as much about the IG linkage, but the Mastodon auto-sharing will be hugely helpful, as that is where I am spending most of my social time these days. There are no API fees there, and content can be shared in many ways. 

You can already do this auto-sharing to Mastodon using ActivityPub plugins, but this announcement indicates it will be brought more into the main WordPress / Jetpack functionality, which will make it that much easier for people to use.

I look forward to trying the Mastodon sharing out when it becomes available!

Meanwhile… this announcement means there are even fewer reasons for me to be checking Twitter anymore. Sad to see the continued decline. 🙁

Just as Twitter is killing off it’s Revue newsletter service, Automattic is promoting their hosted WordPress.com service for newsletters - and providing some new tools to make that easier. In their announcement blog post, they note that WordPress.com has already had the features to email posts out automatically. This “newsletter” functionality has been there for quite some time. What they’ve done now, though, is to bring those newsletter features together in a new theme - and they’ve also simplified the process of setting up a newsletter site.

[NOTE - this feature is part of the WordPress.*COM* hosted service, not part of the WordPress software (sometimes referred to as "WordPress.ORG”) that you can install on your own servers. However, they indicate that the theme used for this newsletter feature will be made more widely available in the future.]

In the announcement, they mention these features:

•     Add unlimited email subscribers
•     Import subscribers from other platforms
•     Launch with a beautiful, ready-made theme or customize every detail with a myriad of Block Patterns 
•     Stylize your newsletter with a background image, site icon, and accent color 
•     Schedule email publishing
•     Monetize your site (stay tuned for more paid subscription features)
•     Use a free .blog subdomain or connect a custom domain with one of our paid plans
•     Publish on the go with Post by Email – making writing a newsletter as simple as sending an email

They also mention that you can start up a new newsletter or add the features to an existing hosted blog.

Giving It A Try

Naturally, I had to try it out. 😀 I started by going to the newsletter page and simply choosing the link “Start building your newsletter”. I logged in with my existing WordPress.com account and was brought to a page to set up my newsletter:

This was simple and easy. After I took the screenshot I added a logo, which needed to be circular. 

Here is one place Automattic will monetize - the “Favorite color” allowed me to use blue for free. Several other colors are available as part of a premium upgrade.

Next they prompt you to set up a custom domain, and offer you some options while allowing for more. You can, of course, skip this (I did in my test) and just use the free default domain they give you.

As I noted, I skipped this part and just moved on to the new screen where I was asked to choose a plan - or start with a free plan.

I chose for the moment to stick with the free plan for this test. After clicking that link, I had one more screen where I could add some initial email addresses and then… ta da… I was at a screen to start publishing

What Do I Think?

First, to be clear, there is not really any dramatically new functionality here. This is how WordPress has worked for quite some time. Even the field for someone to subscribe has been there as part of the “Subscribe Block”.

All that’s really new is this “Newsletter” theme and some of the onboarding screens.

Having said that… I think it can be a great way to get started with a newsletter!

You have all the power of WordPress editing. You can run it on your own domain. You can use it on your laptop or mobile device.

It’s WordPress!

Now, it’s not clear to me that you will get the kind of statistics that you will get from a Substack, Revue or other newsletter platform. I couldn’t see any way to find, for instance, the open rate, or to know how many people clicked which links. Maybe it’s there and I’ve just missed it. Or maybe there is the expectation that you might use Google Analytics for that as part of a paid plan.

I don’t know… and it doesn’t really matter for me, personally. But I could see people who want to use this as a newsletter platform wanting that kind of information.

My one criticism was with the information about the plans. I couldn’t find any easy matrix showing what I get on the free plan versus the paid plans. I could see the features across all the paid plans… but not how that compared to the free plan. It would be helpful to understand as it might cause me to jump into a paid plan.

All in all I think it is a very useful reminder that WordPress can support these kind of interactions over email.

I may consider moving an older newsletter over to this platform and trying it out in 2023.

What do you think about this news?

Tonight in Nashville, Matt Mullenweg delivered his "State of the Word" presentation at WordCamp US. Not being there in person, I watched the live stream. The recorded stream has about 28 minutes of various quotes that were displayed. Matt starts at shortly after the 28-minute mark:

He shows some very cool ways that Gutenberg can work. Starting at around 54 minutes, Matt moves into showing what the next phases of Gutenberg will be. In a "Phase 2" during 2019, more of the admin interface will be moved into blocks. Phase 3 (2020 at the earliest) will be about collaboration, multiuser editing and workflows. Phase 4 (later) will be about having an official multilingual interface.

And then around the 1:12:00 mark, he mentions a fantastic statistic that over 57% of WordPress sites were using HTTPS (i.e. TLS):

Matt goes on with much more information about the WordPress community, more developements - and then finally concludes "The State of The Word" at around the 1:21:00 mark and moves into questions... of which there was about another 45 minutes of long discussions and questions.

Yesterday (Dec 6, 2018) was TheBigDay when WordPress 5.0 with the Gutenberg block-based editor landed in all of our WordPress sites for upgrade. Some of the places to learn more about the launch include:

• WordPress 5.0 launch announcement (with videos)
• WordPress 5.0 Field Guide
• Gutenberg information
• Twenty Nineteen theme info

Changing the core editor over to Gutenberg was a massive effort over the past two years - and the launch this week was both an amazing accomplishment... and a very divisive event within the WordPress community.

I was very much hoping to be down in Nashville for WordCamp US this weekend, where parts of the community will be gathering. I expect it will be quite a passionate weekend! (Unfortunately some family medical issues kept me closer to home.)

I *really* like Gutenberg...

My initial reaction was... I really LIKE Gutenberg!

Now, I've been playing with it for much of the last year, and the more I work with it, the more I like it.

It really DOES enable more beautiful and powerful publishing with great ease.

I'm looking forward to doing even MORE with it and learning how far we can go with using Gutenberg.

... but it needs to work! :-(

However, after the upgrade to WordPress 5.0, the Gutenberg editor didn't work on all my sites. For several of my sites, I had NO PROBLEM after the update. It "just worked." I was immediately able to go in and start editing with Gutenberg.

But on a couple of other sites, when I went in to edit an existing page or post - or to create a new one - I made all my changes and pressed the "Update" or "Publish" button and...

"Updating failed" in a big red bar across the top of the screen!

Amusingly to me, some searching on the web brought me back to a Github issue I had opened back in August 2017.

All I had to do to "fix" the issue was this:

1. Go to Settings -> Permalinks, and change it from "Month and name" to "Day and name" and press "Save changes". I received the message "Permalink structure updated."
2. Change it from "Day and name" back to "Month and name" and press "Save changes". I received the message "Permalink structure updated."
3. Switch back to the tab where I was editing the post and had the error message. Pressed "Update" and.. ta da... the updating worked perfectly fine.

I had to do this on two different WordPress sites (both running on the same WordPress multisite server). Strangely, other sites on the multisite server were fine.

While the fix was easy, it concerns me that I had to do this and that I didn't really do anything. But somehow my act of changing the Permalink Settings did SOMETHING internally to make things work.

That concerns me.

Now, someone in that ticket or elsewhere suggested that this particular issue was NOT a Gutenberg issue, but rather an issue with the REST API, which Gutenberg uses.

Regardless, my point was that I couldn't use the editor to make changes on my site.

And beyond my own issue, I see many other Gutenberg issues piling up on Github. Now, yes, these may be initial launch pains for launching such a massive change.

But I do hope the team of developers can fix these in the 5.0.1 release that I'm sure will come quickly.

I really DO like the Gutenberg editor - and I look forward to seeing all we collectively can do with it!

P.S. This post was NOT written using Gutenberg because this Disruptive Conversations site is sadly still over on TypePad. I look forward to migrating it some day so that I can use Gutenberg!

The news out of Matt Mullenweg last night was...

THURSDAY!

That day, December 6 (2018), is the next target release date for WordPress 5.0.

If you have been paying attention to WordPress, or listening to any of my reports into the For Immediate Release (FIR) podcast over the last, say, year or so, you would know that WordPress 5.0 is a huge departure from all previous WordPress releases. The big change is the replacement of the default text editor with the new "Gutenberg" block-based editor.

Personally, I'm rather excited about the change. I've been using Gutenberg on a number of my sites and really like how much you can do with it.

But... reaction within the WordPress community and ecosystem has been decidedly mixed.

Matt's post has more info.

We'll see if it happens! But if you are a WordPress site operator, get ready! 5.0 is coming soon!

The good folks over at WordPress.com are doing something interesting - they are giving free .blog subdomains for any new sites created on WordPress.com.

Now, to be clear, this is not ANY subdomain under .blog. For instance, I was immediately curious if I could get “danyork.blog”, but no, they are giving away for free third-level subdomains under the following second-level domains:

• art.blog
• business.blog
• car.blog
• code.blog
• data.blog
• design.blog
• family.blog
• fashion.blog
• finance.blog
• fitness.blog
• food.blog
• game.blog
• health.blog
• home.blog
• law.blog
• movie.blog
• music.blog
• news.blog
• photo.blog
• poetry.blog
• politics.blog
• school.blog
• science.blog
• sport.blog
• tech.blog
• travel.blog
• video.blog
• water.blog

So I could possibly get “danyork.tech.blog”, “danyork.news.blog”, “york.family.blog”, or “Vermont.travel.blog”. Basically, a free domain underneath that set of domains.

When you create a NEW site (and that is important because this is currently NOT available to existing WordPress.com sites), you will have a chance to claim one of these subdomains in this process.

Now, for most of us who are more serious about this, we may already have a domain. Or at least will want to get our own.

But for someone just starting out, I could see this being a useful way to get started without having to buy a domain, get it set up, etc.  Cool move by the Automattic team behind WordPress.com!

Here is a quick 3-step process for launching WordPress in a Docker container. You can use this to easily launch a new WordPress instance on your local system to test out new versions, new plugins or anything else.

First, though, you need to have Docker installed on your system. The simplest way for Mac and Windows users is to install Docker Desktop. This desktop download also gives you Docker Compose, which you will need. If you are running Docker on a Linux system, you will need to manually install Docker and Docker Compose.

To run WordPress, you also need a database running. The steps here use Docker Compose to launch TWO containers: one for WordPress and one for MySQL.

Three steps

Step 1 - Create a directory (a.k.a. "folder") and install the docker-compose.yaml file found in this Github repository. You can get the file three ways:

• using git: git clone https://github.com/danyork/wordpress-basic-docker.git
• direct download: https://raw.githubusercontent.com/danyork/wordpress-basic-docker/master/docker-compose.yaml
• copy / paste the text into your own file named docker-compose.yaml

The key is to have this all in a separate directory because your WordPress installation will store some plugins there (see the notes below).

Step 2 - In a terminal window[1] type 'docker-compose up’

This will launch the two containers and link them together. You will see logging to your terminal window. You can press Ctrl+C to stop the containers and get your command prompt back. To launch the containers in the background add a "-d" option:

docker-compose up -d

Step 3 - Connect to your new WordPress server at http://localhost:8080/

That's it!

Now you simply go through the normal WordPress installation process and within a few screens your new site will be fully active.

Next you can update WordPress to the latest version, install whatever plugins you want, etc.

For example, I installed the WordPress Beta Tester plugin, went into its settings and turned on "Bleeding edge nightlies", performed an upgrade... and now I'm running the very latest WordPress 5.0 build. Perfect for the testing I want to do.

Credit for the simplicity of this approach is due to Github user "wglambert" who answered a request I made about help using the WordPress Docker container. Thank you!

Notes

• Stopping the containers - do 'docker-compose stop'. This will stop the containers from running. Doing 'docker-compose start' will start them up again.
• A 'wp-content' directory is created is created inside the directory in which you put the docker-compose.yaml file. Any plugins or themes you add will be stored here. This allows you to do a reinstallation and have all the plugins and themes available.
• WHEN YOU ARE DONE and want all this to go away, just type 'docker-compose down' and the services will be stopped and the containers removed.

There are many more things you can do with docker-compose. The command-line documentation can help you learn more.

Next parts

I labeled this as "Part 1" because I'm planning to write about my own ongoing testing with Docker and WordPress. In future parts of this series, I intend to cover:

• How to load in an existing site for testing
• How to save your changes in a Dockerfile (so you don't have to start at the very basic installation each time)
• ... and other things I learn along the way.

I also expect I may update THIS article over time as I do more with using WordPress and Docker.

I hope you found this helpful. Please feel free to leave comments here (unfortunately I have to moderate due to spam, and so comments will not appear immediately).

I also welcome pointers to other "WordPress and Docker" tutorials that people have found helpful. If you want to follow along with some of my other experiments with Docker and containers in general, I'll be writing about that over on Code.DanYork.com.

[1] or "command shell" or "powershell" or whatever you call it...

If any of you will be at WordCamp Europe 2018 this week in Belgrade, Serbia, please do say hello. I'll be there starting this afternoon and am greatly looking forward to learning from many of the people involved deeply in the WordPress community.

In particular I'm looking forward to the Developing for Privacy and Data Protection session. Based on the work done in the community to help website operators comply with the European Union's General Data Protection Regulation (GDPR), this workshop will look at what comes next. I'm personally very interested to see where this will go.

I'll also be going to some accessibility workshops and checking in on topics such as caching, security and mobility that are always of interest. I also have some meetings with partners and others.

Anyway, if you're there at WCEU 2018, feel free to drop me a note.

For those of us experimenting with "360-degree photos", last week's announcement of Jetpack 4.5 had a hidden but awesome feature: you can use a shortcode to embed your 360 photo or video into ANY WordPress site (that uses the Jetpack plugin).

Here is why this is so huge - up until last month, the only sites that would display 360 photos were either:

• Facebook
• Google StreetView

That was it. Two effectively closed walled gardens of content.

As I mentioned in my reports into a couple of For Immediate Release podcast episodes, my concern was that only Facebook users would really get this benefit. I wanted the ability to display 360 photos on any website.

On December 15, 2016, WordPress.com announced that all hosted sites could embed 360 photos or videos. This was a great step forward in bringing 360 photos out to more sites.

Then just last week version 4.5 of the JetPack plugin was released and, somewhat bizarrely, while the announcement contains no mention of this awesome new feature, an Automattic staff person confirmed the inclusion of the support in a comment.

You can read all about this new capability here:

• Embedding 360° photos and Virtual Reality (VR) Content

Now, since this Disruptive Conversations site is sadly NOT on WordPress, I can't show you the features directly here. However, I've gone ahead and embedded 360 photos on two WordPress sites I have:

• a church in Helsinki, Finland
• a mountain top in the French Alps

Those were both taken using the Google Street View application on iOS. (And yes, sometime I need to write or record a tutorial about how to do this.)

I have included the shortcodes in the blog posts so that you can see how easy this is to do. You just:

1. Take the 360 photo using the Google Street View app on your smartphone. (This will save it to your camera roll on an iPhone.)
2. Upload the image to your WordPress site.
3. Use the appropriate shortcode in your blog post.

That's it!

Of course, you need the Jetpack plugin installed in your site, but that's all.

Many thanks to Automattic's Jetpack team for bringing out this capability so that we could set our 360 photos free of the walled gardens and bring them to any WordPress site!

What do you think about this? Will you try some 360 photos now?

Fascinating news out of W3Techs earlier this month that WordPress now powers over 25% of the Alexa top 10 million websites. The next closest content management systems (CMS) are Joomla at 2.8% and Drupal at 2.1%.

The full stats are found here:

http://w3techs.com/technologies/overview/content_management/all

And a quick view of the top of the chart shows more data:

Note the very top line - and this one is extremely important:

57.2% of the top 10 million sites do NOT use an identifiable CMS.

Either those sites use custom software or somehow strip off identification so that the tools W3Techs uses cannot detect the type of CMS that is being used by that site.

This leaves 42.8% of the top 10 million websites that DO use a CMS.

If you look at the chart:

• the grey bars indicate the CMS' percentage across all Alexa 10 million sites
• the green bars indicate the CMS' percentage within sites that use a CMS

So the net is:

• 25.1% of the top 10 million sites use WordPress
• Of the 42.8% of sites that use a CMS, 58.7% of those use WordPress

And of course all of this data is only on the Alexa Top 10 million sites. There are then millions more sites using various CMS' - and some % of those will be using WordPress.

Still, the Alexa Top 10 million is one set to use - and W3Techs has now been doing these measurements for years.

One interesting note out of the W3CTechs blog post about this milestone is what happens when you move from looking at the Top 10 million to the Top 1000:

When we split up all websites by traffic level, we see that WordPress is leading at all levels, but the market share among the top 1000 sites is significantly lower at 30.3%. Drupal (19.7%) and Adobe Experience Manager (11.8%) are the other dominant systems in that section. Note, however, that using a standard CMS is not very common among the top 1000 sites, more than 90% of them are custom developments.

The article also has some interesting stats on usage by language. It also has this note:

WordPress is not only the most popular CMS, it is also the fastest growing system: every 74 seconds a site within the top 10 million starts using WordPress. Compare this with Shopify, the second-fastest growing CMS, which is gaining a new site every 22 minutes.

WordPress' Matt Mullenweg chimed in with a post "Seventy-Five to Go" noting that the goal now was much of that remaining 75%, particularly the 57% who do not use any CMS right now.

He may be on to something there. If you look over at W3Techs historical yearly trends in CMS usage, you can see the rise of WordPress, but also the decline of "None" from 76.4% in 2011 to 57.2% most recently:

So does all this mean that you should ditch your other CMS' and move to WordPress? Or that you should use WordPress for your next project?

Not necessarily.

I'm a firm believer that you need to use the right tool for the right job and the choice of CMS can depend upon many factors related to your individual site and needs. And while I use WordPress as the CMS for almost all of my newer sites, I also use other platforms for other sites.

And... from a security point of view, I do like a diversity of different systems out there - and I like the fact that there is competition and choice among open source CMS'.

However, the report certainly shows the robust and continued growth in the WordPress platform and the strength of the overall WordPress ecosystem. And it bodes well for the future of WordPress.

Congratulations to the team at Automattic and all the MANY people contributing as part of the much broader WordPress ecosystem!

P.S. I first heard about this statistic on the WordPress Weekly podcast epidode 212. If you are interested in WordPress, I find this podcast useful.

P.P.S. There's an irony, of course, that I'm writing this on a blog hosted on TypePad... I keep thinking that some year I'll move it to WordPress, but the effort involved is huge...