Your published pages are fine. Find which theme or plugin added each missing button, update or replace it on a test copy first, and list the shortcodes staff can type by hand meanwhile.

The buttons that were there last week

Someone in the office opens a page in WordPress to add this month's prices, and the toolbar has changed. The button that inserted two columns has gone, and the one that built tables opens an empty window.

The conclusion is that the site is broken, and the email to whoever looks after it says so. Yet the public pages look exactly as they did yesterday.

What changed was the editor. WordPress 3.9, released on April 16, rebuilt the editing box on a new major version of its software, and some buttons added by themes and plugins did not survive.

What changed in version 3.9

The box where pages and posts are written is an open-source editor that WordPress includes, and version 3.9 moved to its next major release.

Most of what came with it is welcome: images dragged straight into a post, galleries shown as a grid while you edit, cleaner pasting from word processors.

A new major version also changes the rules for anything added to the toolbar. Buttons written for the old one relied on parts that were rewritten, and their authors had to update them.

What staff may notice

None of this touches the published pages. Columns and tables already on the site stay as they were, because the button only wrote them into the page; the theme or plugin still displays them.

Shortcodes still work without the button

Many of these buttons only type a shortcode for you: a short instruction in square brackets that the theme or plugin turns into columns or a styled box when the page is displayed.

Typed by hand, the instruction still works. Staff who know the codes can carry on while the button is fixed, so a one-page list of them is worth keeping.

Finding the add-on responsible

Every button beyond the standard set came from the theme or a plugin, and the first job is to work out which.

The label is often a clue. A button carrying a theme's name, or a list of codes matching a plugin's instructions, points straight to its source.

When it is not obvious, turn the plugins off one at a time and then switch to a default WordPress theme, watching the toolbar after each change. That belongs on a test copy, never on the live site.

The browser's error console helps a developer too. A failing button usually leaves a message there naming a script file, and the folder that file sits in names the plugin or theme.

Updates, replacements and abandoned add-ons

Once the source is known, check whether it has an update. Many authors released versions for 3.9 around the release date, and the Updates screen in WordPress lists any that are waiting.

Read the add-on's notes before updating. Authors usually say which WordPress version they have tested against, and whether anything staff use will look different.

An add-on with no update in a year or more may not be maintained at all. The missing button is only the first sign; a later release may break something more important.

That is the time to plan a replacement, with a developer who can move whatever the add-on controls without disturbing pages already published.

A worked example

A running club with a few hundred members posts race results, training schedules and club news on a WordPress site kept up by four volunteers.

Results went into tables made with a plugin's button, and the training page used two columns from a menu the theme had added. One volunteer pressed Update the day WordPress offered 3.9.

That Sunday the results volunteer found no table button and wrote to the club's executive that the website was broken.

The developer who helps the club found two causes. The table plugin already had an update for 3.9; installing it on a test copy the developer set up, then on the live site, brought its button back.

The theme's columns menu had no update; the theme had not changed in two years. The column codes went into the volunteers' instructions, and a new theme went on the club's plans for the fall.

Why major updates belong on a test copy

A test copy lives at a separate address the public never sees, and holds the same theme, plugins and content as the live site.

Running an update there first shows what breaks before staff meet it. Someone opens the editor, writes a sample post using every button, and checks the forms and the most important pages.

Since version 3.7, WordPress installs small maintenance and security releases by default. Major versions such as 3.9 wait for someone to start them, and that pause is the moment to test.

A backup and a note before every update

A test copy catches most surprises; a backup taken just before the live update is still the safety net, with both the files and the database, and someone who can restore it.

Keep a short record as well: the date, what was updated, and who did it. When a button disappears, that record answers the first question anyone asks.

The counter-case

A site using only WordPress's standard toolbar, with no buttons added by its theme or plugins, may have noticed nothing in 3.9 except the improvements.

A small site with one careful editor and a short list of well-kept plugins can sometimes update directly, with a backup ready, and lose little if something goes wrong.

But where several people edit, or layouts depend on a theme's own buttons, a test copy and one person responsible for updates are worth having. Major versions arrive two or three times a year.

Getting the toolbar back

  1. Tell staff the published pages are unaffected.
  2. List the buttons that are missing or misbehaving.
  3. Write down the shortcodes those buttons inserted.
  4. Make a test copy of the site.
  5. Trace each button to its theme or plugin.
  6. Update or replace each add-on on the copy first.
  7. Repeat on the live site after a fresh backup.

Step four matters beyond this update. A copy kept in place gives every later major version somewhere to be tried before anyone on staff opens the editor.

Why fewer plugins also make the admin screens quicker for the people who keep the site current is covered in a WordPress dashboard that takes a minute to open.

Frequently asked questions

Is the website broken after the 3.9 update?

Usually not. Published pages keep their columns and tables. What changed is the editing toolbar, where some buttons added by themes and plugins stopped working.

Why did only some buttons disappear?

WordPress's own buttons were updated along with the editor. Buttons added by themes and plugins depended on their authors releasing new versions, and some had not yet done so.

How do I find which add-on a button came from?

Check its label and the add-on's instructions first. Otherwise turn plugins off one at a time on a test copy, then try a default theme, watching the toolbar.

Can staff keep working while it is fixed?

Often, yes. Many of these buttons only insert a shortcode in square brackets, and the same code typed by hand still produces the columns or the styled box.

What is a test copy?

A second version of the site, hidden from the public, with the same theme, plugins and content, where updates are tried before the live site gets them.

Does WordPress update itself?

Since version 3.7 it installs small maintenance and security releases by default. Major versions such as 3.9 wait for someone to start them, which is the moment to test.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Editor buttons gone since the update?

Send us a list of the missing buttons, and we will trace each one to its source on a test copy of your site.

Start a Conversation