28 Comments

  1. Weston Ruter

    I think one of the goals this year for customizer will be for there to be a unification of the things you can do in the editor (for post content) vs the things you can do in the customizer (outside of post content). My hope is that this proposed next generation of widgets, JS Widgets, can serve as a foundation for powering a common Content Blocks interface that can appear as shortcodes in post content or as widgets in the sidebar. Nav menu items should also be unified with widgets so that whether you have a nav menu location, a dynamic sidebar, or post content—all of these areas are just containers for Content Blocks. This being the case, I think that Content Blocks is an excellent are of overlap between the editor and the customizer which can be worked on concurrently. I think the Shortcake plugin provides an excellent starting point for Content Blocks in the editor, and I want to start integrating JS Widgets as Post Elements so that widgets can seamlessly be used in post content.

    Report

  2. Weston Ruter

    He believes the best approach is to create the new editor within the Customize API, giving it live previews from the start.

    I think that Nick isn’t saying we need a new editor but rather a new editor experience. I interpret this to mean that I think that the more we can treat “the Editor” as a component rather than the admin screen the better. We should be able to instantiate a TinyMCE editor anywhere to manipulate content and content blocks, whether this be on the admin screen or in the customizer. For example since Shortcake integrates with the TinyMCE editor then the Post Elements interfaces it provides then (mostly) automatically become available to the TinyMCE editor embedded in the customizer via the Customize Posts plugin.

    So the Editor component should be appear on the admin screen and on the frontend (with customizer bootstrapped). When you do “Preview” from the edit post screen this should take you to the frontend with the customizer bootstrapped so that not only can you preview the changes you made on the edit post screen but you can also continue to edit changes in that context and see the additional changes live. This is implemented today in Customize Posts.

    Report

    • Weston Ruter

      It will be interesting to see what direction Mullenweg and the leads decide to take in the foundational task of architecting the new editing experience. Mullenweg made it clear in the State of the Word address that he would like to see Calypso or a similar interface replace wp-admin in the future. However, Calypso was not built using the Customize API, WordPress’ own single page application admin interface that plugins and themes already widely support. …“But I do believe the future of a great wp-admin experience is JavaScript – probably React, talking to APIs, super fast, and maybe even working offline”

      As I’ve written before, the customizer is already a modern JavaScript single-page application. We can definitely iterate on the customizer UI to make use of React but this would be an incremental (2x) improvement over the current customizer, whereas the technical improvements of Calypso over the WP Admin are much greater (likely on an order of magnitude). In either case, however, I think that the future admin should be built on top of the Customize API so that every change can be previewed, drafted, batched with other changes, and scheduled. Building on top of the Customize API certainly doesn’t exclude building on top of the REST API. In fact, as of 4.7 the two are designed to work together so that you can apply the customized state to REST API responses. And as demonstrated in Bridging the Customizer and the WP REST API, REST API schemas make it possible to automatically add new resources to be edited and previewed in the customizer for free.

      Report

    • Nick Halsey

      Correct. If the editor itself is more modular and built in a way that it can work within the frontend context, it would be easier to include in places like the customize preview and integrate with the customize API that way. I’d certainly use a live-preview-based editor much more than something in a distinct “admin” context, but it’s probably necessary to keep both at least in the near future.

      Report

  3. Garikai Dzoma

    So basically they are turning away from a predictable Ubuntu like release cycle to a Debian like cycle. I am not sure this will be a good thing at all

    Report

  4. Pete

    Seriously WordPress core has screwed priorities.

    Instead of building a better engine they are trying to improve the dashboard.

    Report

    • Jonathan Wold

      What makes you think that, Pete? What would “building a better” engine look like to you?

      Report

    • Michael Mizner

      Isn’t improving the engine what the REST API was ultimately trying to improve?

      Like, since that is now in core: it’s time to fix the user experience?

      Maybe I’m interpreting it wrong.

      Report

    • Linda van Schoonhoven

      It would seem odd for me to have a content management system run an engine, but if WordPress can be used for weapons systems, I guess it could be used for anything.

      Report

  5. Pete

    Some “engine” based improvements would include:

    Improve db schema, make widgets posts (maybe this has been done), custom post statuses, post to post relationships, custom email statuses, user taxonomy support, a messenging queue, better cron, and that is just a start.

    Report

    • Weston Ruter

      A new iteration on widgets is a top priority for me in 2017. This includes the work to store widgets in a custom post type instead of options (see #35669), and also to provide REST API endpoints for widgets (see #35574 and #28093).

      Report

      • mark k.

        It will break backward compatibility so I don’t expect it to happen.

        Anyway, (almost) anything will be better than what is there today, but widgets are not content and don’t belong into the posts table. Anew table or two are needed for widgets and sidebars.. There is no reason to make content retrieval slower because someone added a widget.

        Report

        • Weston Ruter

          @mark It needn’t break back-compat. The feature plugin (Customize Widgets Plus) that implements Widget Posts maintains back-compat.

          Also, there’s nothing that says that “content” is reserved for the posts table (though I’m not sure what content means)—the posts table is an objects table. Nav menu items are in the posts table and widgets are conceptually very similar. In 4.7 new post types were created for custom CSS and customize changesets.

          Lastly I’m sure that we can store widgets in posts without a degredation to performance if we employ caching.

          Report

        • mark k.

          @weston since accessing the options directly to have access to some of the widgets information was a necessity, moving that information to another place will break all the code that assume the data is in the options. How many sites will be impacted? from my personal knowledge at least 40k.

          As for posts table being used for non content… well maybe it is time to start treating it like it should be treated and just create new tables if options are bad place for the data.
          In the post table, since there is no autoloading, assuming you have two sidebars, you will need extra 2 (probably 3) DB queries per page load.

          This will bring wordpress into “must have some caching on by default” which should have been part of core long time ago, but it should be implemented before having an architecture which will increase the number of requests.

          Report

        • Peter Knight (@peterrknight)

          @mark k.

          Impact on performance is negligible if non-existent (vs splitting into separate tables). Widgets can share many features that (custom) posts have such as authorship, edit lock, status, scheduling, revisions, api actions etc. As long as the objects take advantage of the same kinds of features, there’s no reason not to use the posts table.

          Built-in caching negates the database query performance penalty. Same should happen for menu items and menus.

          Report

        • mark k.

          @peter, this discussion is about “should any hack be used till it reaches its useful limit before proper restructuring is done”.

          The idea of using the post tables for all CPTs proven to be non scalable, especially where meta is concerned. In retrospect each CPT should have had its own table and than build views or stored procedures or whatever to handle cross CPT queries. Putting more data into what is already a non scalable place is just a bad idea…. you are likely to just shift the scalability problem from one place to another.

          As for caching, hopefully you are not referring to transients as this will basically pollute the options table and you will end with the same problem you wanted to avoid.

          Report

        • Weston Ruter

          @mark If you look at the Widget Posts module of the Customize Widgets Plus plugin you can see that the way it works is by hooking into the options API to swap out where the data is coming from. As such, if you call get_option( ‘widget_text’ ) the return value will be sourced from posts and not from options, and plugins that filter options should still apply as expected.

          Report

        • mark k.

          @weston, Yes I saw it, and it is a hack that should not be in core. get_option is defined to get data from the option table, if it doesn’t, it makes the code harder to read. Tools that have expectations about the actual data structure in the DB will fail.

          More hidden failures will obviously be performance related, as the change is “transparent” code wise, plugin and theme developers will not know that those APIs might be more expensive to use, and will have no reason to fix bad code. (how many queries will be required to do is_active_widget?).

          When speaking about backward compatibility there is a lot to learn from microsoft. For them backward compatibility means that you keep the bugs as well, and if you don’t want them you don’t claim BC.

          You think the current implementation suck? I mostly agree, but the way forward is by deprecating the old code base as it has some core design problems and letting developers to opt in into the new implementation. Current APIs can be extended to support both models, and people that want to access the DB directly will get access to only part of the widgets.

          Report

  6. Pete

    I am not saying that the customizer and editor don’t need resources. Just they would not be my priority.

    One point though is that given the current goals are mainly front end in theory they should not block back end work being done concurrently

    Report

  7. Central Geek

    The new approach to releases shifts WordPress from the familiar time-based release cycle to one that is more project-based. The idea is that design and user testing will lead the way and upcoming releases will ship when significant user-facing improvements are ready.

    Thank you.

    Report

  8. Harrison Uhl

    Regarding where to store widgets (Options, Posts, or a new table): This looks like a good opportunity to use an Object Relational Mapping (ORM) pattern to forever hide these low level schema alternatives from higher level code.

    When the schema and/or higher level object model changes, the Object Relational Mapper(s) would be updated. By this changes in the schema or object models don’t affect the other — but only the mapper in between needs to be updated, thereby greatly localizing (potentially) breaking changes.

    While there are fancy/high price ORM packages, I’ve had great success just hard coding the mappers. While it might be a bit more manual (grunt) work, it’s easy, and the mapping remains performant.

    Report

    • mark k.

      Actually, no. ORM is not a solution as anything that requires knowledge of a schema is just wrong. There should just be a set of good APIs which eliminate the need for such knowledge from anyone which is not a DB admin or need to figure out obscure scaling problem.

      Report

      • Luke Cavanagh

        WC will have CRUD classes in core, so in that use case customers, orders and products can use custom db tables. Then you remove the issue at scale since it is not using posts, postmeta, users and usermeta.

        Report

        • mark k.

          That is very good news. hopefully this means that wordpress.com VIP no longer objects to creating new tables and will eliminate the need of EDD to store data as comments (I asked Pippin once about it and he gave wordpress.com limitations as the reason)

          Report

  9. Michael Justice

    I would like to see the ability to delete posts across the network that have the same name. It would also be nice to be able to change other elements like category and possibly content within post.
    Is any of these features especially the first mentioned a possibility within the WPMU platform?

    Report

Comments are closed.

%d bloggers like this: