Make WordPress Core

Tagged: themes Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling (ocean90) 5:41 pm on July 30, 2015 Permalink |
    Tags: , , themes   

    Legacy Theme Preview Removed in 4.3 

    This release we removed the old code for the Legacy Theme Preview, which hasn’t been maintained since the introduction of the customizer in WordPress 3.5. Recently, we noticed that the theme preview no longer works when using a static front page. We kept the old theme preview for no-JS and some browsers that were less capable. But since browsers are doing a better job today we don’t need to continue fixing/shipping this legacy code. That’s why we removed it. See [33492].

  • Aaron Jorbin 7:34 pm on July 6, 2015 Permalink |
    Tags: , , , themes   

    Singular.php: New Theme Template in WordPress 4.3 

    A new theme template has been added to the theme hierarchy as of r32846: singular.php.  This template follows the rules of is_singular and is used for a single post, irregardless of post type.  It comes in the hierarchy after single.php, page.php, and the variations of each. Themes that used the same code for both of those files (or included one in the other) can now simplify down to the one template.

  • Derek Herman 8:00 pm on March 11, 2015 Permalink
    Tags: , , themes,   

    HTML5 Widgets in WordPress 4.2 

    Note: HTML5 widgets theme support in 4.2 has been reverted pending a decision about the correct container to use

    With the upcoming WordPress 4.2 release, widgets have been added to the growing list of HTML5 supported markup. Once you’ve added HTML5 support for widgets, WordPress will use the <aside> element, instead of the generic list markup.

    To declare that your theme supports HTML5 widgets, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

    add_theme_support( 'html5', array( 'widgets' ) );

    For forward compatibility reasons, the second argument cannot be omitted when registering support. Otherwise, a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking it visually.

    If there are any questions about the current implementation, feel free to leave a comment below.

  • Nick Halsey 11:00 pm on February 11, 2015 Permalink
    Tags: , , , , , , themes   

    Customizer Theme Switcher Feature Plugin Merge Proposal 

    Ticket: #31303

    Customizer Theme Switcher brings theme-browsing and theme-switching functionality into the Customizer. By integrating themes directly into the Customizer, live-previewing workflows are greatly simplified, and the relationship between themes and theme/site options is clarified for the user.

    This plugin represents a significant step in moving all “Appearance” functionality into the Customizer, following Widgets. The future roadmap includes Menus, Theme-Install, and iterations on widgets that would allow the Customizer to entirely replace those admin screens for most users. Because the Customizer Theme Switcher plugin does not address theme-install, the admin page (themes.php) is fully intended to remain in use for now. We are proposing to redirect the front-end “Themes” link (in the admin bar) to the Customizer, as was done for widgets in 4.1.

    Technical Overview

    Customizer Theme Switcher is primarily about adding new UI for existing functionality using existing APIs, rather than introducing new functionality. The plugin operates entirely off of the WordPress 4.1 Customizer API, leveraging the new JavaScript API in particular. Themes is a custom section (that acts kind of like a panel). Each theme is a custom Customizer control.

    The code is heavily Backbone.js-inspired, leveraging JS-heavy portions of the Customizer API to do things like underscore JS templates for rendering theme data. Most of the code is directly adapted from the Backbone-driven themes.php system (and the theme data is retrieved with existing functions), but things like the search/filter are written from the ground up to leverage the Customizer API (in that case, conditionally activating/deactivating controls).

    In keeping with the goal to avoid back-end functionality changes, theme-switches are accomplished simply by leveraging the existing ability to pass a theme as a URL query arg when loading the Customizer; ie, the Customizer is simply reloaded to preview a different theme. Loading overlays are leveraged to make this process seem more instant. Unrelated 4.2 core work around Customizer Transactions could potentially improve how this works.

    Core Changes & Merge Implementation Details

    As outlined in the plugin’s readme there are several proposed technical and user-oriented changes that are best done as core patches (mostly in the merge patch):


    • Remove #customize-info for theme previews.
    • Change front-end admin bar Themes link to point to themes in the Customizer (deep-linked).
    • When a new theme is activated, go to the home page (front end), not the themes admin.
    • If user doesn’t confirm that they want to leave unsaved changes, remove the customize-loading body class (requires core patch).


    • Move custom section and control to class-wp-customize-control|section.php in wp-includes.
    • Merge all CSS into customize-controls.css, scope to .wp-customizer.
    • Move .themes-panel-back to the Customizer header, adjust JS accordingly.
    • Merge JS into customizer-controls.js, after the respective object types.
    • Merge customize_themes_template() into wp-admin/includes/theme.php, at the very end. Make sure that this file is included at the appropriate time as needed when adding the Customizer controls.
    • Merge remaining PHP (all in Customize Register callback) into register_controls() in class-wp-customize-manager.php.

    User Testing

    @designsimply has run four usertesting.com tests (see links in #core-customize), and we haven’t really seen any ongoing issues with the actual theme switcher. It has been difficult to get users to follow our instructions, but when they have used the themes-in-Customizer UI, the interactions have been fairly seamless and as-intended. Further testing could be beneficial after merge, but we think that in-person testing and feedback is generally going to be more effective for this particular plugin.

    Outstanding Issues

    The exact handling of the themes header display still needs some work – the backwards-sliding works well but the arrows to indicate it don’t. @folletto opened a ticket on core trac to work through some alternative options. Most of the accessibility issues have been fixed as well (@afercia please let me know if I’ve missed any), with the exception of the Themes section header, which will happen along with the UI changes there for everyone.

    Future Plans

    A future phase of this project will explore integrating theme-install in the Customizer and minimizing the distinction between installed and available themes. Due to the larger UI and UX changes proposed with that effort, we’ve decided to hold off on theme-install for now so that the basic theme-switching functionality could be built on a reasonable timeline for 4.2. This is similar to the manner in which the “THX” feature plugin team re-did themes in 3.8 and theme-install in 3.9.

    • codeinwp 9:10 pm on February 12, 2015 Permalink | Log in to Reply

      Looks really cool!

    • Andrea Fercia 1:52 pm on February 12, 2015 Permalink | Log in to Reply

      Thanks very much Nick and great job :) will review all your feedback on the accessibility issues list and will let you know.

    • bellfalasch 9:31 am on February 12, 2015 Permalink | Log in to Reply

      Looks good =) I personally would love something like a top positioned overlay with short text “You are previewing Theme X – [activate theme] – [cancel]”. Or wouldn’t that make sense in the customizer?

  • Nick Halsey 12:46 am on February 3, 2015 Permalink
    Tags: , , themes   

    Customizer Theme Switcher Update – 2/2 

    We’ve made lots of progress in the past week and will be holding another meeting tomorrow, Tuesday February 3 2015 16:00 UTC, in #core-customize Slack. The accessibility team did an extensive review and we’ve addressed nearly all of the issues that can be fixed in the plugin (big props to @afercia especially for reviewing and patching some of the issues). I made several core tickets (some with patches, some good-first-bugs) for some of the other issues that came up during the review.

    @designsimply and @vizkr have been working on formal and informal user tests as well. It’s been a little tricky to try to nudge users in the direction of the Theme Switcher in the Customizer without explicitly asking them to change the theme, but they haven’t had any negative feedback or expressed that having themes in the Customizer felt at all out of place. We’ve made a couple of minor adjustments both to the plugin (improving the filter to search for tags without hyphens) and the prompts, and additional tests are in-progress. We’d like to encourage anyone that can to do informal in-person testing, asking for feedback on the workflows and/or comparing the themes admin screen to themes in the Customizer.

    Our biggest remaining decision is whether to change the title of the “themes” section in the Customizer. Currently, it’s “Theme: Current Theme”. Open to suggestions here; we’ll tweak it for screen readers regardless if it works for everyone else as-is, but I’m not convinced that it’s the most discoverable option currently.

    Here’s an agenda for the meeting:

    • Usertesting.com testing update – @designsimply
    • Theme section heading title discussion
    • Informal testing/feedback updates – anyone
    • Accessibility updates: ready for (or do we need) another round of testing for the plugin? – @afercia
    • Outstanding issues – anyone
    • Final proposal and core patch/merge plan and timing – @MarkJaquith, me, @DrewAPicture
  • Nick Halsey 8:11 am on January 26, 2015 Permalink
    Tags: , , themes,   

    Customizer Theme Switcher Update 

    The Customizer Theme Switcher feature-plugin brings theme switching into the Customizer. This project aims to clarify the relationship between themes and theme options by introducing a themes “panel” (it’s actually a custom section since it contains controls, not a multi-level hierarchy of sections and controls) to the Customizer. The themes panel slides in from the left instead of the right, implying a hierarchy of:

    1. Themes – change the entire layout of the site
    2. Theme/site options – tweak various options (default view)
    3. Panels – edit larger groups of site appearance options, such as Widgets and Menus

    Essentially, the phase of the project proposed for WordPress 4.2 (and that exists in the plugin currently) brings the “THX38” theme browsing experience into the Customizer. Installed themes are browse-able directly in the Customizer controls panel, and have a details modal like the admin page. Functionally, theme-switching is accomplished by reloading the Customizer to live-preview a different theme. @westonruter is working on several related improvements that could further streamlining the experience from a technical perspective, but this feature plugin is focusing on the switching UI, with other improvements considered “nice to have”. @folletto and I have also started planning a second phase of the project for a future release that would also address installing new themes, and simplifying the distinction between installed and available themes. @designsimply is currently in the process of user-testing the plugin.

    Get Involved

    We’ll hold a meeting in #core-customize Slack to discuss the progress of the plugin this Tuesday, January 27, 2015 16:00 UTC, and continue at that time weekly as needed at that time. Development is happening directly in the WordPress.org plugins repo – I’ll give commit access to anyone interested in contributing code. Outstanding issues are noted below, but the plugin is generally ready for review of code, inline-docs, design, and accessibility (with each of those being theoretically good-to-go in the plugin). Note that the plugin can’t really work on mobile because the Customizer doesn’t really work on mobile, see #28784 (great 4.2 candidate if it gets a patch).

    Known issues (see also a list of core merge notes in the plugin’s readme):

    • Devin Price 12:04 am on February 5, 2015 Permalink | Log in to Reply

      Hi Nick. Great work on this. A couple thoughts:

      I might recommend is that the theme panel stays open (retains focus) after switching. If someone is testing the look of a few different themes, it might be annoying to have to open that panel again each time and lose context.

      I’m not sure if the theme switcher should have such a high priority (in terms of order). I feel like switching themes has a lot of ramifications, and perhaps shouldn’t be the first option. I’d probably hook it in below the “widgets” (just a personal feeling though).

      Also, looks like the open/close arrows for the panel are pointing the wrong way.

      Maybe you’re already working through some of those. Just wanted to add my 2 cents.

    • Rian Rietveld 7:40 am on January 31, 2015 Permalink | Log in to Reply

    • Weston Ruter 9:53 pm on January 29, 2015 Permalink | Log in to Reply

      PostMessage setting transport may not be working immediately after switching themes, cause unknown

      I can’t reproduce this. See Slack conversation.

  • Konstantin Obenland 5:50 am on January 26, 2015 Permalink
    Tags: , themes   

    Support for Screen Reader Text in Themes.

  • Konstantin Obenland 8:04 pm on December 4, 2014 Permalink
    Tags: , , , themes,   

    New Template Tags in 4.1 

    Working on a new default theme is always an opportunity to improve core’s Theme APIs too. With the release of Twenty Fifteen there are quite a few improvements that made it in:

    Archive Template Tags

    Theme authors get to use four new functions to use in their archive templates:

    • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
    • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.

    They are especially handy when a theme doesn’t have dedicated templates for taxonomy or date archives, but can essentially be used in all archive templates. The description functions only display term descriptions, since no other archive type really offers descriptions.

    Worked on in #21995 and then introduced in r30223.

    Navigation Template Tags

    Core has provided template tags for links between posts and pages of posts for a long time. Now theme authors can resort to higher-level template tags to display an entire navigation snippet. If you’ve built your themes off of recent default themes, or created child themes from them, these should look very familiar. As a heads up: Since default themes have been developed in HTML5 for five years now, there is no HTML4 version of these tags.

    • get_the_post_navigation() and the_post_navigation() for navigation to the next and previous post.
    • get_the_posts_navigation() and the_posts_navigation() for navigation to the next and previous page of posts.
    • get_the_posts_pagination() and the_posts_pagination() for paginated navigation between pages of posts. (Updated for 4.1 RC1, see this post)

    All functions use the same wrapping markup with semantic class names, so it’s easy to style them in one go. The navigation functions accept custom link texts and screen-reader-texts, in case the defaults are not applicable. The pagination functions even accept all arguments that paginate_links() does, too! (Except for the 'type' argument, we need that to be plain so the template tag doesn’t break 😉 )

    Worked on in #29808, introduced in r30065, improved in r30457.

    Also in 4.1:

    Theme Support for Title Tags

    I’ve written about title tags before and will refer to that post for more information about the groundbreaking changes that happened here.

    Page Template Body Classes

    They got a minor update that simplifies those class names and allows theme authors to target folders of page templates. With this /page-templates/full-width.php will produce page-templatepage-template-page-templates, page-template-full-width and page-template-page-templatesfull-width-php. Worked on in #23470 and then introduced in r30100.

  • Konstantin Obenland 10:57 pm on October 29, 2014 Permalink
    Tags: , , , themes,   

    Title Tags in 4.1 

    For over three years we have been trying to make it easier for plugins and themes to manage the document title. Kubrick didn’t necessarily set a great example to theme authors by appending the blog name to wp_title(), a practice we have been trying to correct ever since.

    #18548 was created to find a solution to that problem, but after initial excitement hasn’t seen any noteworthy action until a few weeks ago. Yesterday @johnbillion committed a first step towards a brighter future in [30074], introducing a forward compatible way to make document titles fully customizable.

    Adding titles to themes

    Starting with 4.1 and Twenty Fifteen, the recommended way for themes to display titles is by adding theme support like this:

    function theme_slug_setup() {
       add_theme_support( 'title-tag' );
    add_action( 'after_setup_theme', 'theme_slug_setup' );

    Support should be added on the after_setup_theme or init action, but no later than that. It does not accept any further arguments.

    By declaring support like this, themes acknowledge that they are not defining titles on their own and WordPress can add it safely without duplication.

    To maintain full forward compatibility, plugins can not check for theme support of title tags, and are discouraged from building functionality around it just yet. The long term plan is to enable users to manage document titles from their admin, independent of which theme they’re using. At that time it will also become more plugin friendly. To make sure this can be achieved however, it was important to rule out backwards compatibility concerns as much as possible.

    While there is no consensus on how the final implementation will look like yet, this should be a good way to get themes started to opt into a more user friendly way. It will also make any future changes that much more impactful when the final version ships.

    Backwards compatibility

    To enable support in existing themes without breaking backwards compatibility, theme authors can check if the callback function exists, and add a shiv in case it does not:

    if ( ! function_exists( '_wp_render_title_tag' ) ) :
    	function theme_slug_render_title() {
    <title><?php wp_title( '|', true, 'right' ); ?></title>
    	add_action( 'wp_head', 'theme_slug_render_title' );

    This would also be the place to optionally add a filter to enhance the document title, along the lines of what recent default themes have been doing.

  • Andrew Nacin 7:24 pm on October 8, 2014 Permalink
    Tags: , themes,   

    Ideas for plugin/theme install/update UIs 

    In the last few releases, the theme and plugin installers received new UI. But the actual procedure of installing a plugin or theme is still old-school: a JavaScript alert confirms you actually did want to install something, then you get taken an ugly screen that prints out sentences of “Downloading package,” etc. If there is an error, everything stops. If it succeeds, you can activate what you just installed or go back to where you came from.

    To say this is not the best experience is an understatement. We can streamline this entire flow while also adding some new functionality. Here’s the goal: Installing or updating a plugin or theme should not block you from continuing what you were doing. Secondarily: unnecessary and sub-par user interfaces should be eliminated.

    Some ideas:

    • You should be able to install a plugin/theme without leaving the installer screens.
    • You should be able to continue searching and browsing for other plugins (or themes).
    • Multiple plugins/themes should be able to be queued for installation at once.
    • Progress is shown directly inside the installer. Details are only shown if there is an error.

    How are we going to do this?

    • Once an install starts for an item, we can “lock” that item to the top left of the results, even if the user keeps browsing or searching for other things.
    • The plugin installer is not yet dynamic, so we’ll need to add infinite scroll and such to allow for continuous browsing (something we avoided doing in 4.0 due to time constraints).
    • We’ll need to come up with a UI for installing a plugin, such as a card-flip, a subtle progress bar, or button changes (“Install” “Installing…” “Installed!”).
    • Updating plugins, themes, and core (from the Dashboard → Updates, Plugins, and Themes screens) should be seamless and happen inline, which will be a completely different UI from installing.
    • We must make sure a user abort (leaving the page) is prevented and/or doesn’t stop the update. We must probably make sure that updates are queued (only one actually happening at once), as we have to take into account maintenance mode, conflicts, I/O operations, and such.
    • If the user is forced to enter FTP credentials, we can request it once in a modal, then send it with each Ajax request — much nicer experience.

    The tracking ticket is #29820. Thoughts, ideas, challenges, suggestions, questions welcome.

    • owcv 8:40 am on October 14, 2014 Permalink | Log in to Reply

      Besides these layout changes, there are more essential questions I think.
      The plugin and theme installer of the future, should be able to completely deinstall a plugin or theme, not only the data on the webspace, but first and foremost all the stuff in the database (e.g. wp-options).
      In my opionion, this is a major problem of the plugin/theme-installer, because it can harm your wordpress site by bloating it with relics of deleted plugins/themes.

      • Timothy Bowers 12:46 pm on October 14, 2014 Permalink | Log in to Reply

        I’ve always been torn on this, whilst I’m favour of a better way to remove unneeded stuff from the DB, I’d worry about it’s use on the uninstaller where people simply deactivate, perhaps whilst testing for potential conflicts for example.

        I think if it’s implemented then it’s important to ensure it’s a conscious choice, something that forces the the user to acknowledge it’s irreversible. The number of times over the years I’ve seen users delete something that isn’t backed up, is custom, and they can’t get it back, even when a prompt asked “Are you sure?” and possibly even stated they can’t undo this action.

        With great power comes great responsibility. :)

        • owcv 3:27 pm on October 15, 2014 Permalink | Log in to Reply

          Of course and I’m very cautious when installing new plugins (testing them before and so on), but over the years, some times you change plugins for some reason and in worst cases you can’t ged rid of the old stuff. That’s why I think it would be great to have an app-like plugin and theme installer in WordPress.

    • Matthew 1:06 pm on October 11, 2014 Permalink | Log in to Reply

      Add folders in the Media section.

    • Graham Armfield 6:37 am on October 11, 2014 Permalink | Log in to Reply

      Some ambitious changes and additions to functionality listed here. Please can I ask that during the design and functional design stage that thought is given to how we can make this accessible.

      Every time there’s a change on the screen we need to be thinking about what feedback that screen reader users are getting. It’s important also to ensure that everything can be operated just by using a keyboard, and obviously that keyboard focus is always visible and that the tab order is logical.

      Thinking about accessibility at the design stage is a key step in ensuring that everyone can use the functionalty.

    • Josh Visick 8:48 pm on October 10, 2014 Permalink | Log in to Reply

      I think improving the experience and options available when something goes wrong with plugin updates is important. I’ve been thinking if it makes sense to have an easy revert to last installed version for plugin updates that happen to break a site. That could also possibly tie into an automatic support ticket for the plugin.

    • AMEEKER 11:56 pm on October 9, 2014 Permalink | Log in to Reply

      I don’t know if this is the right place to put this or not, but it’s related to the searching for plugins. When you type in or paste in a plugin name or query in the plugin search box, you have to hit ENTER to actually perform the search. There is no search icon anymore that allows you to click to complete the search. Can we add that back?

    • alexis_hancock 7:22 pm on October 9, 2014 Permalink | Log in to Reply

      I would really like to see some prompts around the errors that occur when a plug-in is unsuccessful. It’s very vague on what exactly went wrong and if error messages are provided, and sometimes they are, it would be nice to see prompts on how to debug for that message.

    • Hugh Lashbrooke 6:59 pm on October 9, 2014 Permalink | Log in to Reply

      Something that’s always stuck out in my mind is the fact that there are two separate actions for getting a new plugin running on your site: install & activate. In almost all cases, I would say that plugins are activated immediately after installing. To non-technical users, the differentiation probably doesn’t even make all that much sense.

      My thought is to rename the ‘install’ button and turn it into a 1-click ‘activate’ button. That way, after searching for a plugin, users simply click one button and the plugin downloads, unzips and activates. This gives the impression that WordPress and the plugin repo are all one cohesive system, instead of the segmented systems that they really are. Technical users would still know what’s going on of course, but the average user really wouldn’t care that now there is a new folder on their server with the plugin files in it – they just want it to work.

      Along with that and 1-click delete action like @radices suggested above – together that would go a long way to giving a much more cohesive and stable feel to WordPress itself and the plugin repo.

    • Cliff Seal 11:50 am on October 9, 2014 Permalink | Log in to Reply

      This isn’t fleshed out, but reading this brought at least one quick interaction to mind.

      Clicking the {refresh icon}{number} area in the admin bar could dropdown to show basic information:

      Plugin Name
      Current Version -> Available Version

      There could be a link to see details (where the user could choose what plugins to update, read descriptions, etc.) along with a link to just ‘Update All’. You could set the entire updating process in motion without leaving changing screens or anything else like that. And, instead of a fugly JS alert, you could add a cancellation timer: “Updating all in 10 seconds… [cancel]”

    • Primoz Cigler 9:34 am on October 9, 2014 Permalink | Log in to Reply

      Maybe we could consider implementing the plugins/themes/core updates/installs utilizing the Web Workers (at least progressively enhance the experience for the users that use browsers that support that): https://developer.mozilla.org/en/docs/Web/Guide/Performance/Using_web_workers

      To be honest, I am not super familiar with the Web Workers, but I have a feeling that they would fit perfectly for that task being discussed. The support is very good among the browsers as well: http://caniuse.com/#feat=webworkers

      • Primoz Cigler 9:38 am on October 9, 2014 Permalink | Log in to Reply

        The main benefit would be (at least how I understand the web workers) that the user could even leave the install/update screen (for instance go wiring a new post) while the process will not be interrupted.

    • daveshine (David Decker) 7:43 am on October 9, 2014 Permalink | Log in to Reply

      Just yesterday, I released this plugin: https://wordpress.org/plugins/cleaner-plugin-installer/screenshots/

      I mostly tweaks the start page of the install admin page (?tab=featured) and replaced its content with a large search input field, among other little tweaks.

      Already got lots of feedback, that other developer & users like the approach of starting with a search box.

      • Netzialist 7:59 am on October 14, 2014 Permalink | Log in to Reply

        Thank you for this, David!
        I felt completely lost the first time I saw the new interface. I had a certain plugin in mind, but there was no searchbox. Instead I saw big bold icons cluttering my browser window. Stuff I didn’t need and I didn’t look for.
        From a usabilty point of view I consider the new interface as a big step back. WordPress desparately needs to become simpler. Much more simple as it is now.

        • virgodesign 10:57 pm on October 19, 2014 Permalink | Log in to Reply

          Plugins has grown so much in the years, and sometimes you can install and manage dozens. I would love the ability to group installed plugins using categories, just like posts with taxonomy. This will help admins having a better organized plugins page

    • MRWweb 10:24 pm on October 8, 2014 Permalink | Log in to Reply

      While maybe the user-facing feature doesn’t make it into this work, I would hope that the technical foundation could be laid for the update-by-zip-upload feature as described in #9757. This seems like the right time to consider it again since it was first opened 5 years ago!

    • WPMUDEV 8:43 pm on October 8, 2014 Permalink | Log in to Reply

      At WCEU there was a talk about options, and how each option is a decision that has to be made.

      Apologies if this has been covered before, one feature/update I’d love to see is getting rid of the separate theme and plugin upload area (not where you search for themes or plugins), the number of times I’ve seen end users complain that their theme doesn’t install and they get “The package could not be installed. No valid plugins were found.” or that their plugin doesn’t install and they get “The package could not be installed. The theme is missing the style.css stylesheet.” and that has been down to them using the wrong area.

      Those two upload areas are like options, it’s a decision on where to go and one a user has to make, to a new user they don’t always read the labels or know what theme or plugin is and how they differ. Seasoned users may roll their eyes when they see people make this mistake, and then we happily set them on track but this situation and choice could be avoided by having a single smarter upload that basically says:

      • This is a theme, unpack it in the themes folder.
      • This is a plugin, unpack it in the plugins folder.

      This way it’s one upload area, no confusion.

      Not sure how many times other companies see this, but we get this question in both emails and our own support forums a bunch of times each month.

      Thanks for reading :)

      • Captain Theme 2:19 am on October 9, 2014 Permalink | Log in to Reply

        Strongly agree. In a support position I’ve seen this done countless times and it’s a very unpleasant experience for the user.

        Not sure the best way to approach it but even keeping things the way they are now but doing a check for if it’s a theme/plugin and then moving it to the appropriate location, etc. would be a huge improvement.

        • Timothy Bowers 12:35 pm on October 10, 2014 Permalink | Log in to Reply


          You’re right, it is an unpleasant experience for end users, and the warning they get is also so meaningless, all they know is something isn’t working and in most cases I’ve seen them blame the plugin/theme developer.

          The main path to get there is the add button within the theme or plugin admin area, and from the menu. I was thinking it would be a case of changing those links to direct to one upload area that handles this but your idea would work just as well so it detects and passes it off as needed.

      • Timothy Bowers 8:46 pm on October 8, 2014 Permalink | Log in to Reply

        Sorry, I intended to post this under my own account rather than the company one. :)

    • Rene Hermenau 8:18 pm on October 8, 2014 Permalink | Log in to Reply

      > Multiple plugins/themes should be able to be queued for installation at once.

      Nice feature but could be dangerous for newbies who install all end everything. If only one plugin breaks the site, user do not know which one causes the issue.

    • Radices 7:57 pm on October 8, 2014 Permalink | Log in to Reply

      I’d like to see the ability to delete plugins without having to deactivate them first (auto deactivate when deleting). I’d also like to be able to delete themes from the main screen without having to go into the details screen first.

    • demoman2k10 7:47 pm on October 8, 2014 Permalink | Log in to Reply

      Replacing the Install display with a progress bar, or changes should also include an option to debug the install incase of error’s as well. So one does not end up with a Plugin that hasn’t installed and no details as to what went wrong and where to start working to fix it.

    • Rafael Ehlers 7:29 pm on October 8, 2014 Permalink | Log in to Reply

      Can we also please add Drag’n’Drop to the installer (upload case): https://core.trac.wordpress.org/ticket/24579

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar