In what has become a nearly annual tradition, WordPress has released yet another update that broke thousands of plugins across the Internet. As usual, they claim this is in the best interest of security. Thus the breaking change was done with ZERO notification to developers. It was also forced onto most sites as a “security patch release” which will update any site that does not forcibly stop automatic updates.
Communication From WordPress Core Is Horrid
While I don’t have an issue with breaking changes for true security issues, what IS a problem is pushing out a change with almost ZERO testing to millions of websites with ZERO communication. They gave absolutely no warning to thousands of sites that this “update version” was coming and that it would knowingly break things. They did not communicate to site owners so they could block updates. They did not communicate to plugin or theme developers so they could come up with new releases.
Should you update to WordPress 5? This is a question that has been asked thousands of times in the past week. I have been asked at least a dozen times and every time my answer is the same. NO.
Unless WordPress automatically updates your site and it is more difficult to restore the prior 4.X release , then WAIT.
While the WordPress 5.0 editor, the most obvious updated to WordPress in the 5 release, is definitely a step in the right direction it is not a compelling reason to upgrade. Not too mention it is different. That means the content writing process you’ve gotten used to, including all the quirks inherent in WordPress, is going to have to be re-learned.
This is not an in-depth article — have too much going on these days for that. It is a more a short-hand techie crib sheet of how I got a deployment repo to auto-pull the latest changes to its develop branch over to my staging server automatically. This is pulling down a fully software environment to a directory on the server.
Microsoft Teams is a mixed blessing. Like most Microsoft products it starts off with a great idea, does some of it exceptionally well and the rest of it is half-baked. Microsoft Teams Wiki Export is a perfect example. There is no readily-apparent and easy way to get your data OUT of a Wiki page you’ve created in Teams. It is stuck there forever with no way to Print, Archive, or Export the content.
This is a typical Microsoft maneuver designed to generate disdain for non-Microsoft-centric tools and boost vendor lock-in. But there is a usable, if completely convoluted, workaround. It turns out that most of these Teams-based Wiki pages that you added to your Teams tabs because it seemed like the “simple and easy” solution can be retrieved. They happen to end up in Sharepoint. Just make sure you remember the very first original name you gave the tab because any renaming of tabs is done with magical pixie dust sprinkled on a circle of leprechauns all playing the telephone game. If you have more than a few Wiki pages good luck guessing which one is the one you want if the name does not match.
Here is how I found the “magical mystery file” using the browser-based version of Microsoft Teams: