Notes from Eliminating Pain when Changing Themes discussion

One of those frustrating issues. 1) Target the problems and 2) propose solutions.

Nothing works when installing a new theme. Doesn’t look like the picture. Takes time (a couple of hours even) to get it set up. How can the theme switch be minimized so that the new theme contains the old site content without any additional work?

Chris: Problem is assumptions. The assumptions we make only fit to a certain category of themes. Inconsistincies crop up and bad things happen then. There’s not an ability for an admin to change something and not modify the front end for visitors. A theme “trial run”. Customizer does this a bit, but not to a great extent. This wouldn’t work for Chris’s complex theme.

Chris: If there was a way to start up a trial run, and then push it live when it’s ready.

Clay: Widgets are the biggest issue. Switching themes puts all the widgets in the unused widgets section and scatters them.

IDEA: Storing groups of widgets to allow for dropping them in after changing themes.

Michael: Allowing a theme to define a primary widget area. Most themes will have that in the sidebar, but in some cases could be a footer or otherwise. Skip the step for at least one widget area.

Clay: Might not need much of a new UI, really.

Now discussing menus and how they behave. Builder, for instance, can have many layouts and change things. Since changes in recent versions, child theme changes when using the same sidebar IDs scatters widget setups.

“Every widget be shufflin’”

Moving away from widgets. What about when a featured image call is made and there isn’t a featured image set? What should we do?

IDEA: A fallback, designed specifically for those cases. Apparently Genesis does something similar by declaring a fallback image in the theme folder. To avoid including multiple sizes, Michael suggests using media sideload to move the image over into the WordPress media section so resizing can happen natively.

Chris: iThemes did an editor-only thumbnail image that tells them there is no image there, but they can add one if they want. And that they are the only ones to see the image.

Michael: A user suggested a UI for quickly adding featured images to posts. Could be plugin territory.

Problems so far boil down to widgets and featured images.

Syed: Moving from a framework theme to a dot org theme will confuse people. From many things/screens to something simpler.

Chris: We have pressure from customers to do that kind of stuff.

Syed: WooDojo, for instance, solves the problem of duplicating lots of code in a bunch of themes. Or at least, allowing users to swap themes and keep core functionality.

Ryan: TGM Plugin Activiation class, dropping notices within statuses.

Michael: I hate when themes put the home page template in the page template. For one thing, which theme screenshot do you display if you have a front page and a blog page? Two screenshots? Multiple image UI? Or on that page, since the dashboard knows the setting that is chosen, just display the one that’s selected. So, include two screenshots, one for each type. Naming convention maybe?

Chris: We’ve trained people that themes are easier than plugins. It’s understood that plugins are a bit more work. But for themes the expectations are different.

Michael: JUX is a publishing platform on the front end that loads content on the get-go every time. He doesn’t like it, but it’s kind of neat he says.

Chris: Perhaps multiple screenshots showing different possible setups is one way to approach the problem.

Is there any way that we can track statistics for how widgets are used?

Action Items

  • Start a ticket for the issue when widgets are scattered after a child theme is modified, when using the same sidebar IDs.
  • Start a trac ticket for grouping widgets to make swapping them between themes after switching themes.
  • Start a discussion around a plugin for quickly adding featured images to a bunch of posts.