Robert Anderson 1:31 am on August 15, 2024
Tags: 6-7 ( 75 ), core-media, dev-notes ( 597 ), dev-notes-6-7 ( 15 )

Automatic conversion of HEIC images to JPEG in WordPress 6.7

In WordPress 6.7, HEIC image uploads will be automatically converted to JPEG on the server when possible.

This allows you to view HEIC images in WP Adminadmin (and super admin) and use them in posts
and pages regardless of whether a visitor’s browser supports HEIC. Browser support for HEIC is low while the occurrence of HEIC images is common as they are the default storage format used by Apple devices.

The original HEIC image can be downloaded via a link on the attachment page.

Conversion is only done if the server has a version of Imagick that supports HEIC. You can see whether a server supports HEIC in Tools → Site Health → Info → Media Handling → ImageMagick supported file formats.

If conversion is not possible, a warning is displayed to the user encouraging them to manually convert the image to JPEG. This was the default behaviour prior to WordPress 6.7.

Automatic conversion of HEIC images to JPEG can be disabled using the image_editor_output_format filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..

add_filter( 'image_editor_output_format', function( $output_format ) {
    unset( $output_format['image/heic'] );
    return $output_format;
} );

#6-7 #core-media #dev-note #dev-notes #dev-notes-6-7

Anthony Burchell 11:48 pm on February 6, 2024
Tags: agenda ( 1,109 ), core-media, meeting ( 405 )

Phase 3 Media Meeting Agenda – February 7, 2024

The Phase 3 Media Meeting is scheduled for Thursday February 8, 2024 at 00:00 UTC in the core-media channel on Make WordPress Slack. This is a follow up to the post announcing this meeting that can be found here. If you have any topics you’d like to add to this agenda, please add them in the comments below.

Meeting agenda:

Below is an outline to drive discussion for the meeting. We will approach these topics broadly and get a sense

Quick round of intros.
Overview of the objectives for Phase 3 Media
Discussion on alignment of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Media focus to help the process
Discuss communication channels and checkpoints to be used for regular updates
Media Library
- At a high level let’s discuss what the future of the Media Library looks like.
- More global insight into media usage at the attachment level
  - Where is a media being used if at all
  - What alt attributes are being defined for it in its usage
  - Duplicate detection
Discuss the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor’s role in editing media.
Back-compat relative to existing Media Library, Uploads, and Third party plugins
- Discuss the transition process from the existing media library to the future media library. What does that look like?
- What are the intermediary steps between where we are now and a new, fully integrated media library?
- Will the new media library be available outside of the editor?
Update from William Bay on his Media Library experimentation, where Will can share some thoughts on sorting, filtering, and basic functionalities being tested in his experimental media library project.
Discuss the feasibility and desirability of using the Block Editor as the primary interface for media attachment editing.
- Can we in a future state use the Block Editor as the attachment image editor using a Media Attachment Block that gives editing capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). of the image block but updating the source image or creating new attachments.
Review of Phase-3-Triage Tickets
Open Floor for Questions and General Discussion
Opportunity for attendees to bring up topics not covered on the agenda, share updates, or ask questions.

This meeting happens in the #core-media channel. To join the meeting, you’ll need an account on the Make WordPress Slack. Props @joedolson for helping prepare and proofread this post.

#agenda, #core-media, #meeting

Emily Clarke 4:03 pm on April 25, 2023
Tags: core-media, core-performance ( 134 ), performance ( 399 ), performance-chat ( 327 ), summary ( 961 )

Performance Chat Summary: 25 April 2023

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

Updated the cadence of 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. scrubs to be every 2 weeks – next one scheduled for April 26, 2023 at 15:00 UTC.
@flixos90 Also briefly sharing that I just published a performance retrospective post on WP 6.2 that I had been working on over the past few weeks: https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/ It highlights some of the key aspects which changed in 6.2 in how we dealt with performance and also summarizes high level numbers. It can be seen as somewhat complementing https://make.wordpress.org/core/2023/04/05/wordpress-6-2-performance-improvements-for-all-themes/, at a higher level however without looking as much at specific improvements.
Discussion regarding the decoupling of the SQLite 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 from the performance lab work. In reference to this conversation that came up in a previous performance chat. Would love to have an open discussion about peoples preferences here and whether we do decouple this?
- @olliejones I favor that approach. It will usually be deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. independently of the stuff in PL.
- @10upsimon I tend to lean more toward an agreement with @rmccue in that SQLite is not necessarily performance improvements focused (or at least that is not the primary goal), and probably belongs outside of the realm of the performance lab work.
- @spacedmonkey To be clear, I think that performance team should continue to support SQlite getting into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., to much sure it done in a performant way. But SQlite is not a performance benefit on the face of it, so it is confusing why we part of performance lab plugin.
- @rmccue Yeah, that was basically my thought; I think it’s beneficial all-round to separate it out (but with performance still consulting as @spacedmonkey says)
- @olliejones yes, having SQLite headed for core is good. I believe the issue is about monorepo and multifunction plugins on the one hand and a separate repo and plugin on the other.
- @aristath I agree with what was mentioned above 100%. SQLite can be related to performance, but is not in itself a “performance” module/plugin. It should be developed in collaboration with the performance team since it can have a big impact, but I’d vote to decouple it from the performance-lab plugin
- @olliejones Maybe in a parallel universe or another year, there can be a separate database team. But for now the perf. team has the talent.
- @spacedmonkey If you want to setup a meeting for a database team, that could work. Many component meetings have less than 5 people.
- @flixos90 To clarify, this conversation is slightly different and mostly unrelated to the “unbundling Performance Lab plugin” effort. While we are publishing other PL modules as standalone plugins, those standalone plugins will still be directly associated with the performance team, developed in the monorepo, referenced from the PL main plugin etc. Removing / decoupling SQLite from PL would be different: We would still support getting the plugin towards WP core of course, but it wouldn’t be in any way connected to PL anymore. Maybe that was clear, but just in case.
- Next steps clarification:
  - @aristath I think the only thing to do here would be to remove the module from PL, and add a notice so in case the user previously had the module activated, they’ll be prompted to install the standalone plugin
  - @joemcgill I assume we’ll remove the module from the performance lab plugin in the same release where we remove other modules. How we handle the transition so as to not break any active sites, is not clear to me at the moment.
  - @olliejones Do we have any usage telemetry to help guide that decision?
  - @flixos90 Potentially. As mentioned, I think this conversation is decoupled from the general PL unbundling effort, so we could do it at the same time, but also sooner. I would love to find a way to make the transition smooth though. For sites that already have the SQLite module active, we should probably recommend activating the SQLite plugin before deactivating the feature.
  - @aristath That’s a good idea…
  - @flixos90 Has anyone tried yet to activate the SQLite standalone plugin on a site where the PL SQLite module is already active? We need to make sure it doesn’t throw fatal errors
    - @aristath Adding it on my TODO list for tomorrow, though from what I recall I tried it last month and I there were no issues. I’ll need to test that again just to be sure, it’s been a long time
  - @10upsimon I feel strongly about not intentionally breaking users sites, however few are using it. Perhaps we need to defer the removal to 2 versions from now, and raise a notice or similar in the adminadmin (and super admin) making it very clear that from version n it will no longer be supported as a core PL module.
    - @flixos90 agreed @10upsimon adding though that for a smooth transition the plugin should be activated before deactivating the PL module, so we have to make sure that that is actually possible
  - @joemcgill A similar transition plan will be good for all of the modules, to be honest, even though SQLite is the most critical due to potential breakage.
  - @flixos90 @joemcgill I think for the other modules we’ll handle that in a central effort as part of unbundling, but with SQLite it will now be bit different, since that plugin will not be referenced directly from PL in the future. But I agree it’s most critical there to have a smooth transition since switching back to a MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. / MariaDB database accidentally will break any site that actually relies on SQLite right now

Welcome!

Communication

Meeting agenda:

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Priority Projects

Server Response Time

Database Optimization

Images

Measurement

Ecosystem Tools

Creating Standalone Plugins

New Projects / Proposals

Open Floor

Announcements

Focus area updates

Images

Feedback requested

Object Cache

Feedback requested

Measurement