Outcomes from the last WP Notify feedback post

A month ago I posted an update post for WP Notify, in order to start planning for the next phase of this project.

This post includes a short review of the feedback from that post, as well as the outcomes/next steps.

Feedback

  • Generally the feedback on the post and the requirements document was good. It was also pleasing that more new contributors were made aware of the project, and left their comments on the document.
  • It was generally agreed that a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository makes the most sense as a central location for all work to be done.
  • There was no general consensus around the weekly meetings.

Outcomes

The GitHub repository has been created. We need to decide if we’re going to start building using existing code, or completely from scratch.

We also need to start designing the user interfaces. There are already designs from @hedgefield on the original trac ticket, but those designs may need a refresh based on our current requirements document.

And finally, I’ll be resurrecting the weekly meetings in the #feature-notifications channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. These meetings will however switch to an office hours format, without an informal agenda. These office hours will take place on Mondays at 14:00 UTC. Due to time constraints on my side, the first open office hours will be on Monday, August 17, 2020, 14:00 UTC.

I invite all interested parties to join me in our first office hours on the 17th of August 2020, as we start implementing the project we’ve all been planning for the past year.

#feature-plugins, #feature-notifications, #team-update

Completing the implementation of metadata registration with the REST API

A priority of the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. team for the upcoming 5.0 release is to finally enhance WordPress metadata registration so that it can cover common APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. use-cases. This will help with adaptation of the REST API by making management of custom metadata in existing content endpoints easier, which should in turn also benefit any metadata-related work in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. This post provides some insight into the surrounding issues, shows the current progress of the improvements, and highlights what still needs to be discussed.

A little history on register_meta()

The register_meta() function has been around since 3.3, but did not attract much attention with developers until WordPress 4.6 introduced enhancements to permit metadata registration for use within the REST API. As with other metadata functions, an object type (by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. definitions either a “post”, “term”, “comment”, or “user”) needs to be passed to the function, alongside the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. key to register and the arguments for its behavior.

However, metadata in WordPress is often used only for a subset of one of the above four types. When dealing with post meta in a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for example, that post metadata commonly only applies to one or more specific post types – not to all posts of any post type. That is what currently makes register_meta( $object_type, $meta_key, $args ) unusable for the majority of REST API-related cases. Before the enhanced version was introduced in 4.6 many thoughts were put into this concern, with a subtype-aware implementation even being merged into core. That implementation was reverted before the release because it was unclear how to handle conflicts (more on that below). The ticketticket Created for both bug reports and feature development on the bug tracker. where all those changes were discussed is #35658.

Misconceptions about register_meta()

The improvements and their documentation caused developers to listen up, but unfortunately since the concept of an object type is rarely exposed in high-level WordPress APIs, many people misunderstood the first parameter as requiring a post type because post meta is the most common kind of metadata used by plugin developers. Some developers started using the function to register post type-specific meta keys without that function actually supporting that, as shown in this example:

Note:

This does not do what you may think it does:

register_meta( 'book', 'isbn', array( ... ) );

The code above will not register an ISBN number meta key for a “book” post type. It will register that key for a custom object type “book”—which probably doesn’t exist, unless a whole custom meta database table, a custom object database table, and surrounding setup has been implemented.

Those function calls fortunately don’t cause any harm in most cases since WordPress only contains four object types that use metadata (ignoring multisite). It becomes problematic though if the function is used to register metadata for the “post” post type.

Note:

This also does not do what you may think it does:

register_meta( 'post', 'some_meta_key', array( ... ) );

Since the “postpost type shares a name with the “postobject type, and since, again, the first parameter of register_meta() is for object type and not for a post type, register_meta() will register that meta key and arguments passed for all posts of any subtype (post type).

If you’re reading this and have used register_meta() in a way where you assumed it could register metadata for a single post type or taxonomy, at present we recommend you switch to using register_rest_field(), which is currently the only (however a little more involved) way to achieve this.

Adding subtype support for metadata behavior

A follow-up ticket #38323 aims to finally implement this missing functionality to register_meta() so that there’s an easy-to-use API to handle subtype-specific metadata in the REST API. It picks up the approach used before, where an additional object_subtype argument in the $args parameter can be used to specify the subtype the meta key should be registered with. Picking up the aforementioned example, you could register the ISBN for a “book” post type via the following code:

register_meta( 'post', 'isbn', array(
	'object_subtype' => 'book',
	...
) );

Open questions regarding subtype handling

Implementing meta registration for subtypes and modifying existing behavior to account for it is rather straightforward, and there is a patch available to experiment with the current approach. There are a couple things that need to be discussed though:

  • How should we deal with or prevent conflicts between meta keys of the same name and object type? The method currently allows to register metadata for an entire object type of course, so we cannot simply change that now and prevent those calls entirely. It appears we have four alternatives here:
    1. Allow meta keys of the same name and object type to be registered in any way. In case a meta key is registered for the current subtype, but also more generally for the object type, the behavior registered for the subtype takes precedence. Meta keys are internally stored nested under their object type and object subtype ($wp_meta_keys[ $object_type ][ $object_subtype ][ $meta_key ]). This is how the current patch on the ticket works, mainly because it is the most straightforward and flexible approach (it was also how the original code from #35658 worked). However it doesn’t deal with conflicts at all, so it is likely not preferable. An issue would be that on every update of a value, sanitization would happen for both behaviors, easily resulting in invalid data and unexpected errors. Throwing notices would be an option – but it would only help preventing conflicts, not actually prevent them.
    2. Allow meta keys of the same name and object type to be registered either per subtype OR for the entire object type. It would be based on whoever comes first takes priority. Meta keys are internally stored nested under their object type and object subtype ($wp_meta_keys[ $object_type ][ $object_subtype ][ $meta_key ]). If someone registers a meta key for an object type after someone else already registered the same meta key for a subtype of that object type, the process should be rejected and fail. If someone registers a meta key for an entire object type without the same meta key already being registered for a subtype of that object type, afterwards all meta keys for a subtype of that object type would be rejected. This prevents all possible conflicts since meta keys will only exist once per object type/object subtype combination, but still provides the flexibility of having multiple meta keys of the same name for different object subtypes. The implementation to prevent the conflicts during meta registration would be a little more involved though.
    3. Allow meta keys of the same name and object type to be registered only once in total. It would be based on whoever comes first takes priority. Meta keys are internally stored nested under their object type only, without an additional level for their object subtype ($wp_meta_keys[ $object_type ][ $meta_key ]). Whoever comes first, can register their meta key, every following request to add the same meta key for the same object type afterwards will be rejected. This prevents all possible conflicts since the data structure alone makes it impossible for two meta keys of the same name and object type to be registered. The approach generally appears to not be flexible enough: For example if two different post types were using a meta key of the same name, they wouldn’t be able to co-exist. However, based on the assumption that developers prefix all their metadata (which is probably not taught often enough), this option could very well work and be a straightforward solution.
    4. Allow meta keys of the same name and object type to be registered in any way, but use the behavior registered for the entire object type as a fallback only. In other words, if the same meta key exists with a subtype, only run that logic – for all subtypes where there is no specific behavior available, fall back to the behavior registered on the entire object type. To be precise, the difference between this approach and the first one is that in the first one the behavior (like sanitization and auth) would be executed for both, while here it only happens for the object subtype or the object type when no subtype-specific handling is registered. This is a conflict-free approach that at the same time doesn’t require any restrictions where calls to register_meta() would need to be rejected. The idea of using meta keys registered for an entire object type as fallback is slightly different from the other variants, but it seems to work well. It should still be highlighted that meta keys should be prefixed, but if that is a given, this implementation would even allow an individual plugin to provide more flexible logic for its metadata that may be needed for all post types (general behavior as fallback, subtype-specific behavior where needed).
  • Should we introduce easy-to-use wrapper functions like register_post_meta( $post_type, $meta_key, $args ) and register_term_meta( $taxonomy, $meta_key, $args ) which wrap register_meta() appropriately? The reason those might be useful is that the concept of object types and object subtypes is not commonly exposed in core’s documentation & high-level APIs (think about *_post_meta(), *_term_meta(), *_comment_meta() and *_user_meta() all wrapping the respective lower-level *_metadata() function). By adding these methods we would then recommend to only use those, and never recommend the use of register_meta() itself (as registering metadata for an entire object type is probably not desired). The only downside would be that comments and users don’t really have subtypes, so those two functions would either have a redundant first parameter or not have that parameter at all (which wouldn’t be future-proof).
  • A more specific issue: Should a comment’s comment_type value be considered a subtype? While one could argue that they are subtypes, they are treated entirely differently and do not really define how that comment works or how it can be edited. There’s also no flexible API around it to register additional comment types, and in the REST API there are no individual controllers per comment type. Currently, the patch ignores comment types, but this is still open for discussion.

Upcoming Meeting

The above items will be discussed in next week’s upcoming REST API meeting which will take place at the regular meeting time, Thursday, May 3rd, 2018 at 17:00 UTC in the #core-restapi channel. If you’re interested, please attend this meeting so that we can move forward with this ticket, as it should be included in WordPress 5.0. Also feel free to review the latest patch on #38323 and leave a comment on the ticket. While it is unlikely that this is the final implementation, a lot of it would not need to be adjusted regardless of the outcome for the above questions.

Extra credit goes to @kadamwhite for proofreading and several improvements.

#agenda, #rest-api, #team-update

API Team Update

APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. Team Update Sept. 27 2016

The API team met yesterday on slack for our weekly update, which this week was predominately focused on follow-up from last Thursday’s comprehensive GitHub issues scrub.

Since the previous API team update the group has been making steady progress through the gameplan outlined in that post. To give a quick update on a few key “quirky” issues that had been identified:

Password-Protected Posts

As noted in last week’s dev chat, password-protected posts will be included in collections with their content set to '', and the content can be viewed by passing ?password=XXXXX as a query or GET parameter when querying for a specific post. Query parameters are not an ideal solution: Authorization headers are out because you can’t have multiple authorization schemes in one request; cookies don’t afford enough control to browser clients, and custom headers aren’t respected by caches. See GH issue #2701 for more background, and check out the open pull request to review the specifics of the implementation.

Sticky Posts

After much debate there is now a path forward for handling sticky posts as well. Following this open pull request, sticky posts are included in the /wp/v2/posts collection, but are not given special treatment in terms of ordering—a sticky post will, by default, be displayed ordered by date or whatever orderby has been set for the request. The parameter ?sticky=true may be passed to return only sticky posts; ?sticky=false may be passed to exclude sticky posts from the response.

There is ongoing discussion around how the API could surface posts in the “normal loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. order,” with stickies on top, followed by non-sticky posts. @jorbin will propose a follow-up enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. that could be added in to the API in a later cycle. See GH issue #2210 and associated slack discussion for more commentary.

MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Support

A pull request is open on the API meta endpoints repository to add support for registering meta with the API using the main register_meta function. This PR includes a comprehensive readme explaining how meta handling works. Once merged & reviewed, this functionality will be PR’d against the primary REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party repository.

Site Settings (Options) Support

A pull request has merged into the API site endpoints repository which adds support for accessing and manipulating site settings through the API. These endpoints will be PR’d against the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. REST API plugin repository this week.

Discussion items for 9/28 dev chat

This project is not quite done yet, and in tomorrow’s dev chat the API team will be looking to the broader WordPress team for input on three priority issues that need a decision:

Upcoming Meetings

Please join us in #core-restapi on chat.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ for our next two group meetings:

#4-7, #rest-api, #team-update

Metadata API project reborn: The new Fields API project

Many of you will remember that a couple of years ago, @ericlewis and a group of us set out to start a project to make sense of all of the different APIs that arose from third party plugins and themes to build custom fieldCustom Field Custom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. solutions on top of WordPress. That project was nicknamed “Metamorphosis” and subsequently went by the “Metadata UIUI User interface/APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.” project. As pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors dealing with and using custom fields and content types, we had been tackling the issues of developing for multiple object types in WordPress for years prior to getting together.

Now, @helen and I are pleased to (re)introduce to you what we’re hoping to be the fruits of all of this labor: Meet the new Fields API project.

function fields_api_example_post_field_register( $wp_fields ) {

   // 1. Define a new section (meta box) for fields to appear in
   $wp_fields->add_section( 'post_type', 'my_cpt', 'my_meta_box',
      array(
         // Visible title of section
         'title'       => __( 'My Meta Box', 'mytheme' ),

         // Determines what order this appears in
         'priority'    => 'high',

         // Determines what order this appears in
         'context'     => 'side',

         // Capability needed to tweak
         'capability'  => 'my_custom_capability'
      )
   );

   // 2. Register new fields
   $wp_fields->add_field( 'post_type', 'my_cpt', 'my_custom_field',
      array(
         // Default field/value to save
         'default'    => 'All about that post',

         // Optional. Special permissions for accessing this field.
         'capability' => 'my_custom_capability',

         // Optional. Add an associated control (otherwise it won't show up in the UI)
         'control' => array(
            // Don't set 'id' and it will automatically be generated for you as
            'id' => 'mysite_my_custom_field',

            // Admin-visible name of the control
            'label'   => __( 'My Custom Field', 'mytheme' ),

            // ID of the section this control should render in (can be one of yours, or a WordPress default section)
            'section' => 'my_meta_box',

            // Control type
            'type'    => 'text'
         )
      )
   );

}
add_action( 'fields_register', 'fields_api_example_post_field_register' );

(Please note: The code above may not be the same as the final implementation, it will especially change over the next few weeks)

First of all, we split off the UI side of the project to focus solely on the API. This way, we’re not held up by anything as we move towards implementation inside of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. We can tackle each UI separately and that helps us keep the project nimble and on track.

The goals of this new API proposal will be to be implemented across WordPress objects as an API to register fields and sections for. We aim to cover these objects (not necessarily in this order):

  • CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. (retrofitting it beneath the existing Customizer API)
  • User profile screen
  • Post editor
  • Settings screens (retrofitting it beneath the existing Settings API)
  • And other areas in the future (Comment editor, Networknetwork (versus site, blog) Settings screens [see #15691], Media modals, etc)

This API offers a great deal of standardization across all of WordPress and code reusability. It’s paramount for third-party developers, who will be able to utilize these structures in their own plugins and themes, build apps and give access to other developers so they can contextually see what a site really contains. I see the biggest use-case being able to expose the entirety of WordPress to the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. and giving apps like the WordPress iOSiOS The operating system used on iPhones and iPads. app access to metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes and custom fields to display real editor screens with field inputs based on the control types natively.

Areas we need help currently:

  • Examples and use cases for Customizer, User profile screen, Post editor, and Settings screens (submit issues in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ with your ideas, coordinate with us to refine them if you want)
  • Unit tests for core
  • Testing Customizer implementation, you’ll find the core files to replace under the /implementations/ folder in the repo
  • Brainstorming implementation classes for other object types to implement in the UI, starting with User profile screen

If you’re interested in joining our merry crew which includes @helen and a few of us, hop into SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. #core-fields and join our weekly meetings every Monday (Monday 20:00 UTC 2015). You can check out the Fields API and submit PRs on GitHub, or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” us in #core-fields throughout the week with questions or concerns.

#customize, #fields-api, #options-meta, #team-update

Autosave and Post Locking Update

Today we had our first scheduled meeting.

Consensus was, for a first pass:

  • Display a simple lock/padlock icon next to locked posts within the post list screen, leaving the “Request Lock” button for the post edit screens.
  • When a post is locked, hide the Quick Edit link, and disable batch edit for the post
  • To unlock a post, the user will enter the post edit screen, then click a button to request a lock. This will trigger a request to appear for the user with the current lock, where they can decide whether or not to allow the new lock.

As far as development tasks go, @azaozz is planning on finishing a first run at the “Heartbeat” APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to be committed before the end of the week. I’ll begin working on the list table changes for post listings. We’re currently looking for volunteers to aid, as there’s plenty of room for help! Additional tasks will include the UIUI User interface for handling post lock requests and auto-save to local storage.

We’ll certainly chat more about this tomorrow in dev chat, and are planning another meeting this Friday (2013–01–25), at 21:00 UTC (the same time as dev chat), unless this doesn’t work for many of you looking to help. Please post here, or come to the chats if you’re interested in helping with this project, and we’ll get in touch with you for further details!

#3-6, #autosave-and-post-locking, #team-update

Team Update XML RPC on behalf of westi…

Team Update: XML-RPC (on behalf of westi)

In our second cycle, the primary focus was CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) methods for taxonomies. The work was tracked in #18438, and covers both the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. implementation and the unit tests.

We also spent more time refining the cycle 1 work (CRUD for all post types), tracked in #18429. This included fixing some date bugs (related to #15098), adding support for getting/setting post thumbnails (related to #15098), and writing unit tests.

After using the posts methods from cycle 1, it became clear that the post type information methods from #18436 were highly desirable. The old patches on that ticketticket Created for both bug reports and feature development on the bug tracker. were updated and aligned with the rest of the XML-RPC work for this release.

westi was not available for much of this cycle, so Marko and I worked on our own; he is now reviewing our final patches and will comment or commit shortly. In the meantime, I’m finishing up work on XML-RPC documentation for the codex, which should be ready by betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Marko and I will also continue to expand the XML-RPC unit tests suite (now around 75 tests).

#team-update, #xml-rpc

Team Update: Browsing Buddies

@getsource and I did some in-person hacking at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Phoenix over the weekend. New patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. on #19816 for multiple screenshots that seems good to go in as a first pass after a JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. sanity check and probably an update to using .data() instead of .attr() tomorrow before dev chat. Will definitely need some UIUI User interface/UXUX User experience once that’s in, and will also likely need a little update for whatever the .org APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. response will be.

There is also a new patch on #19815 that adds a class member variable and removes a global (yay!) and passes data via JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. instead of parseQuery. Eyes also welcome on that.

#browsing-buddies, #team-update

We’re digging in full bore to get things…

We’re digging in full bore to get things done by freeze. #19978 is the primary ticketticket Created for both bug reports and feature development on the bug tracker..

Tasks that need to happen by Wed Feb 29:

  • Finish the styling (Drew)
  • CSSCSS Cascading Style Sheets. file cleanup (Lance)
  • RTL stylesheet
  • Editor stylesheet

The last big missing piece for styling is post formats.

Update Wed Feb 29: see my comment below.

#bundled-theme, #team-update, #twentytwelve

Team Gandalf Update

Last week marked the end of our second cycle and the beginning of our sprint to get things done. We began by doing just that: last Friday, we merged the theme customizer into core. There’s still quite a bit to do and polish, so please keep that in mind. Development is being tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.(k)ed at #19910.

In the past week, we’ve introduced better JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. APIs, working preview navigation (you can click URLs and it works, hooray), namespaced attributes (which will allow us to enable form submission within previews), and more. We also uncovered and fixed a fairly insane bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. that stemmed from a low-level bug in Opera’s JS engine. Good times.

Moving forward, the main goals are to integrate more setting types (headers, widgets), improve the refreshing process, polish the UIUI User interface, and remove any vestigial pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party cruft. Dominik’s time will be limited over the next few weeks due to exams, so if any of this sounds exciting to you, please let me know.

#customize, #gandalf, #team-update

Team Update Bugs RPC Unfortunately nothing happened for…

Team Update: Bugs-RPC

Unfortunately nothing happened for us this cycle. Since I will be out for awhile starting in a few days it has been proposed that the two XML-RPC teams be merged together.

#team-update