Justin Ahinon 8:59 pm on October 9, 2019
Tags: , ,   

Introducing handling of big images in WordPress 5.3

The way WordPress handles large images has always been a topic of discussion for users and developers.

There are generally two types of images that are uploaded:

  • Images that have been edited or created in an image editing application.
  • Photos that are uploaded either directly from the camera or haven’t been edited.

In the first case, the images are usually “web-ready”. They may have been scaled down to an appropriate size and optimized.

In the second case, the images are usually much bigger than needed and are not optimized for web use. A photo taken with an average modern smartphone is easily over 5MB in file size. Photos taken with a good quality camera can be much larger.

WordPress 5.3 introduces a new way to manage these images by detecting big images and generating a “web-optimized maximum size” of them.

How does it work?

When a new image is uploaded, WordPress will detect if it is a “big” image by checking if its height or its width is above a big_image threshold. The default threshold value is 2560px, filterable with the new big_image_size_threshold filter.

If an image height or width is above this threshold, it will be scaled down, with the threshold being used as max-height and max-width value. The scaled-down image will be used as the largest available size.

In this case, the original image file is stored in the uploads directory and its name is stored in another array key in the image meta array: original_image. To be able to always get the path to an originally uploaded image a new function wp_get_original_image_path() was introduced.

Disabling the scaling

The scaling is controlled by the big_image_size_threshold filter. Returning false from the filter callback will disable it.

add_filter( 'big_image_size_threshold', '__return_false' );

For reference on this change, see Trac ticket #47873 and changesets [46076] and [46353].

#5-3, #core-media, #dev-notes

Mervin Hernandez 7:55 am on January 22, 2020
Tags: , ,   

WP Notify Meeting Recap – January 20 2020

This is a recap of the WP Notify meeting held on Monday, January 20, 2020, 14:00 UTC. You can read the meeting discussion here.

Based on feedback received at meetings and comments, we focused on making the Objectives section in the requirements document more concise.

We also added a Use Cases section, based on feedback from the previous meeting recap post.

Use Cases

This is the excerpt of the “Use Cases” section as compiled by @folletto and @psykro.

Section 2. Use Cases
1. Action required: the plugin wants the user to take a decision, i.e. “you got a comment” (action, notification)
2. Onboarding: the plugin wants to provide guidance on a specific feature, i.e. “try this feature” (action, on-page/notification)
3. Informative: the plugin wants to inform the user about something, i.e. “backup completed” (no action, notification)
4. State: the plugin changes its state, i.e. “settings saved” (no action, on-page)
5. Marketing: the plugins wants to advertise something or suggest an upgrade, i.e. “buy an upgrade!” (action, on-page)

Requesting Feedback

  • Should we address possible unintended uses (example: Notifications of subscribe/unsubscribe from site which may include a profane username?) @folletto
  • For implementation, should we port notifications (such as marketing notes) only to the user who activated the plugin? @m1tk00
  • Further comments / remarks on the 📄 Requirement Document are welcome, and we added appendix references of related projects for inspiration (https://docs.google.com/document/d/1SoIaFqXkXiVzq5mizbZQafMfL36bD0WKj8iwYM823MI/edit#)

Next Slack Meeting

📅 Monday, January 27 @ 14:00 UTC

A note about how we hope to advance the project forward at a steady pace: by working together on the requirements document during meetings, and as time allows in between with comments and channel talks. Once we gather feedback on our goals and actionable steps in the best interest of a merge-able project, then we will progress with next sections of the document and work. @psykro @hrmervin

#feature-plugins, #feature-notifications, #summary

Francesca Marano 8:11 pm on January 22, 2020
Tags:   

Release Model Working Group – Kickoff, January 29, 2020

Thank you for your patience, it took longer than I predicted to kick off this working group, but here we are!

On Wednesday, January 29th let’s have the first meeting for the Release Model Working Group at 19:00 UTC. It’s the same time slot as the New Contributors Meeting and we can alternate meetings with them.

The problem we are trying to solve

Many fixes and enhancements are made continuously in WordPress core, the Gutenberg block editor, and third-party libraries, but everyone has to wait up to four months to see these due to the cycle of three or four major releases per year. This has a negative impact on both end-users and developers.

What will the Release Model Working Group do?

This working group will spend some time during the 5.4 release cycle to:

  • Evaluate the technical changes needed to speed up the release process
  • Evaluate if those changes are doable with the existing resources and tools

The group will also document the existing release process in order to achieve the above.

The end result will be a few factual, non-opinionated documents which outline the above.

Why do we need a working group?

A working group is a bit of a fancy name for a group of people who come together to spend time focused on a particular problem – in this case, the issues caused by the current release cadence – and identify potential solutions and their feasibility.

We need this because increasing the rate at which new versions of WordPress are released has a big impact not only on end-users but on those involved in the release.

When

A meeting can be held in the #core Slack channel every two weeks, alternating with the New Contributors chat, and it will be mostly a status report so everyone is aware of what the findings are so far, and what everyone is doing.

How will the group work?

The group is self-organising based on experience, skills, and interest. Team members should commit to one of the above-mentioned areas.

Which approach to use for the research and which tool to use for collecting the results has to be determined: please leave your comments below, so by next Thursday we will have a few ideas to pick from.

I can take on the role of facilitator, with main tasks being:

  • Pinging people to remind them of their commitment and deadlines 😉
  • Remove blockers if necessary
  • Check overall progress

Who is the team made of

Many people raised their hands in the call for volunteers post. Thank you for your enthusiasm and generosity!

I am spending the next few days reaching out to each one of you to see how your experience and expectations, together with the capability of being self-organised, aligns with the group.

The chats will be public, so everyone can see what is being discussed.

Initial research: The different aspects of a release

I took some time to explore all the aspects involved in releasing a new version of WordPress and divided them into macro areas. The list is not exhaustive but a starting point. At this point it’s not necessary to go too granular, that’s what the working group is for.

This list should give the working group a starting point of areas to focus on.

Stages of the release cycle

  • Alpha
  • Beta
  • Release Candidate
  • General release

Issue tracking

  • Bug reporting
  • Bug gardening
  • Code writing
  • Testing
  • Committing

Planning and coordinating

  • Scoping the release
  • Putting together a release team
  • Scrubs scheduling
  • Collecting feedback and status reports from everyone involved

Communication of the release

  • Blog posts in /news for each stage
  • About page
  • Dev notes
  • Field guide
  • Bug scrubs (schedule and hosting them)
  • Dev chats (agenda and hosting them)

The people involved in releasing

  • Coordinator
  • Mission control
  • Core committers
  • Security team
  • Systems

Thank you for making WordPress!

#release-process

Ella van Durpe 4:44 pm on January 22, 2020
Tags: , ,   

What’s new in Gutenberg? (22 January)

The second Gutenberg release of 2020 includes 159 PRs by 56 contributors!

The navigation block received again quite a few improvements this release. You now have the ability to set text and background colours!

Screen Shot 2020-01-10 at 6 36 18 PM
New colour options fo the navigation block.

This release we’ve also made some considerable performance improvements. The average time of an input event has almost been reduced by half (47.76%) and the loading time of a fairly large post by 29.25%! This is the result of making the block DOM tree lighter, meaning taking the block controls out of the block rendering and DOM tree and removing div element wrappers.

There’s a new block collections API which can be used to group blocks in the block inserter.

registerBlockCollection( namespace, { title, icon } );

Included are also new post layout blocks (author, date and excerpt) and improvements for the site editing experiment.

7.3 🇬🇷

Enhancements

  • Add border to table header & footer 19450
  • Add the new replace flow to the cover 19583, media text 19198, file 19174, audio 19158 and video 19162 block.
  • Components: improve ToolbarButton 18931
  • Sibling inserter: fix dead zone between blocks 19719 19729
  • Top toolbar: adjust tab order 19623
  • Regions: position publish region after sidebar 19427
  • Better accessibility labels for blocks 18132
  • Breadcrumb: add accessibility label 19597
  • Navigation: add background color 19108

Performance

  • Lighter block DOM:
    • Put sibling inserter in popover 19456
    • Remove extra div wrapper 19010
    • Remove inner div wrapper 19593
    • Split out toolbar rendering 19564
    • Put side inserter in Popover 19406
    • Rewrite drop zone with hooks (useDropZone) 19514
    • Merge effects 19617
    • Fix alignments 19704
    • Clean up after control removal 19618
    • Reposition tabbable inserter 19596
  • Avoid rerendering every block when caret moves in and out of formatting 19524

Bug Fixes

  • Navigation:
    • Format the allowed styles 19477
    • Show recent pages as default suggestions when creating Nav Links 19458
    • Define allowedFormats option for NavigationLink 19507
    • Rename the LinkControl’s edit button title 19505
    • Use underline instead of bottom border for nav links 19538
    • Do not output navigation links with empty labels 19652
    • Remove draggable from all navigation-link blocks 19648
    • Remove duplicate CSS from Navigation that is aleady in Navigation Link CSS 19540
    • Remove the text color button double border on the navigation block toolbar 19567
    • Replace, on editing a navigation link, the current label with the title of page or post 19461
    • Add description for the Link Settings Description in the Link Block settings 19508
    • Fix Navigation Link url escaping 19679
    • Fix alignment on left border between menu navigation controls and menu item 19511
    • Styling fixes after navigation feature merge 19455
  • Add support for align wide to deprecated versions of gallery block 19522
  • Block top toolbar: fix mover direction 19574
  • Editor keyboard shortcuts: fix Toggle Sidebar 19605
  • Editor: Fix Block Embed Input size 19438
  • Fix ServerSideRender component showing className 19555
  • Fix writing flow focus capturing 19621
  • Fix small visual select glitch 19590
  • Fix the height of the tags tokens 19592
  • Fix buttons block Link shortcut not working with multiple buttons 19492
  • Disable HTML on navigation link 19483
  • Fix managing page break in the block manager 19303
  • Show predefined colors in the navigation block 19493
  • Update CSS rule on the widgets screen required for drag & drop 19428
  • Multi block selection: fix tabbing 19700
  • Multi block selection: set focus back after attempt 19720
  • RichText: don’t set focus when applying format 19536
  • Writing Flow: fix list selection 19721
  • Fix Color Picker Format Toggle placement 19607
  • Fix Columns block pattern picker item margin. 19494
  • Fix block styles for More block 19745
  • Block: fix hasMovers BlockList setting for top toolbar 19619

New APIs

  • Components: add ImageSizeControl component 17148
  • Add block collections 17609
  • Add Text component 18495
  • Add warning package 19317
  • Components: add isFocusable state to Button 19337

Experiments

  • Edit Site:
    • Add a Post Author block 19576
    • Add a Post Date block 19578
    • Add a Post Excerpt block 19579
    • Implement Template Part block editing 2 19203
    • Add template loading 19081
  • Block Directory:
    • Change ‘update’ icon to text to be more communicative 19451
    • Update the action button label to read ‘Add block’ 19412
  • useColors:
    • Fix contrast check 19500
    • Directly pass ref for color detecting 19474
  • InnerBlocks: Fix toolbar capturing 19530

Documentation

  • Add js syntax highlighting to documentation 19467
  • Add lint-md section to scripts readme 19716
  • Add linting of source in markdown files 19518
  • Document packages-update wp-scripts command 19711
  • Linting Documentation 19543
  • More visibility to the theme opt-in styles documentation 19463
  • Remove spaces in title for consistency with other components and docs 19466 19464
  • Update block-filters.md 19595 19684
  • Update contributors guide with docker-compose info 19362
  • Add js syntax highlighting to documentation 19465
  • Use import statement instead of deconstruction in docs 19469 19471
  • Fix Navigable Container component usage code 19615

Various

  • Block Editor: Remove (more) legacy “editor-” class name compatibility 19489
  • Block toolbar: rewrite toolbar forcing 19527
  • Breadcrumb: isolate logic 19573
  • Contain selection logic in useMultiSelection 19529
  • Move navigation and selection logic to WritingFlow 19397
  • LinkControl
    • Refactor LinkControl API 19396
    • Remove Popover from LinkControl component 19638
    • Add search results label for initial suggestions 19665
    • Prevent space being reserved for scrollbar when items fit box 19633
    • Remove non-public fetchSearchSuggestions from LinkControl documentation 19710
    • Update Nav Block to use new showInitialSuggestions prop on LinkControl 19667
    • Flatten LinkControl components by mocking useSelect for tests 19705
  • Remove core editor usage from block editor rich text 18789
  • Add script to automatically update core packages 19448
  • Adds tests for horizontal mover descriptions 19549
  • Remove: Gradient Picker from cover block placeholder 19712
  • Add SVGR support to wp-scripts 18243
  • Add storybook for Panel component 18541
  • Add supports html: false to new website blocks. 19646
  • Add: Block editor keyboard shortcuts on the widgets screen 19432
  • Added 8px padding to search input block. 19452
  • Adds a “(no title)” label to links to pages or posts with no title 19528
  • Array type attribute source query comma missing 19717
  • Block Editor: Make initial inner blocks non-dirtying. 19521
  • Block Popover: editor canvas as boundary 19322
  • Check for existing of avatar_urls array before trying to return the avatar img part of user autocomplete fragment 18259
  • Update downshift dependency to v4.0.5 19661
  • Components: replace console.warn with wordpress/warning 19687
  • DOM: Mark stripHTML as unstable 19725
  • Decode HTML entities for publish link 19517
  • Expose custom gradient picker 19480
  • Gallerys ids are saved as numbers 19163
  • Media & Text: Remove “Insert from URL” from the replacement flow. 19606
  • Page template previews 19106
  • Post-Author: Move HTML tags outside of the translatable string 19675
  • Priority Queue: Invoke callback when flushing queue 19282
  • RichText: split out inline warning 19545
  • Storybook: Update to latest 5.3 19599
  • Update npm-package-json-lint-config docs 19584
  • Update the float on the Spinner to none 19338
  • Wrap color palette in fieldset with label inside of a legend 19546
  • Check Symbol.iterator not Symbol.toStringTag (redux-routine) 19666
  • Skip intermittent end to end test on the button block 19653
  • Fix e2e test failures via console log exception to handle temp wpnonce error 19532
  • Packages: Mark build-styles as side-effectful 19535
  • docgen: Omit unknown type tag from Markdown format output 19571
  • Build Tooling: Skip package for build if package.json unreadable 19439

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 7.3.0 4.550s 33.8ms
Gutenberg 7.2.0 6.431s 64.7ms
WordPress 5.3 6.481s 69.865ms

#core-editor, #editor, #gutenberg

Paal Joachim Romdahl 9:24 am on January 21, 2020  

Editor Chat Agenda: 22nd January, 2020

Note taker: @jorgefilipecosta

This is the agenda for the weekly editor chat scheduled for 2020-01-22 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Gutenberg 7.3.0
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #editor-chat

Justin Ahinon 9:52 am on October 10, 2019
Tags: ,   

WordPress 5.3 adds a “Show” button next to the password field on the login screen

Many web services today display a Show button next to the password fields. The purpose being to help the user ensure that the password entered is correct.

Note that a button already exists to show/hide the password in the New User, Edit User and Reset Password pages. This functionality is now available with WordPress 5.3 on the login screen.

Here’s a quick view of the behavior of the button.

For more information on this feature, check ticket #42888 on Trac and changesets [46256] and [46372].

#5-3, #dev-notes

Andrey "Rarst" Savchenko 11:38 am on September 23, 2019
Tags: ,   

Date/Time component improvements in WordPress 5.3

Date/Time component encompasses all input, output, and storage of time and date information. Its code dates back to PHP 4 implementation in an early version and went through partial PHP 5 retrofit.

For over a year and several WP releases, we ran a project dubbed “wp_date” to fix and improve the component. Final parts of this effort will ship with WordPress 5.3.

  1. All existing code will have more correct and reliable operation. We fixed bugs, added unit tests, and corrected inline documentation for many functions.
  2. WP 5.3+ code will get access to the new API functions, for convenience and PHP interoperability.

New API functions

We improved the component’s API, made possible by raising the required PHP version to 5.6 in the core.

Unified time zone retrieval

  • wp_timezone_string() a single way to retrieve site time zone, regardless of settings (timezone_string/gmt_offset options). Might return Region/Location string or ±NN:NN offset. Both are now valid inputs for PHP versions supported by core.
  • wp_timezone() retrieves site time zone as DateTimeZone object.

New date localization

  • titular wp_date() is a ground–up rewrite of date localization with WordPress locale. It works with Unix timestamps and PHP time zone objects.
    • date_i18n() function is now a legacy wrapper around wp_date().

PHP interoperability

  • current_datetime() retrieves current moment of time as DateTimeImmutable object.
  • get_post_datetime() retrieves post time as DateTimeImmutable object.
  • get_post_timestamp() retrieves post time as Unix timestamp.

Phasing out WP timestamps

Date/Time component relied on so–called “WordPress timestamp” — a sum of Unix timestamp with a time zone offset. This was causing many bugs and lack of interoperability with upstream PHP or any external systems. Inline documentation erroneously referred to these as Unix timestamps.

It is impossible to remove WP timestamps without backwards compatibility break. But we made significant progress to:

  • cut their use in core;
  • correct invalid inline documentation;
  • offer new API using real Unix timestamps.

Not recommended

  • don’t retrieve time as WP timestamp:
  • don’t localize time based on WP timestamp:
    • date_i18n( DATE_RFC3339, $timestamp + $offset )
  • don’t store WP timestamps persistently;
  • don’t compare WP timestamps;
  • don’t change PHP time zone with date_default_timezone_set() (this one is hard requirement for correct core operation!)

Recommended

  • retrieve time as Unix timestamp or DateTimeImmutable object:
    • time()
    • current_datetime()
    • get_post_datetime()
    • get_post_timestamp()
  • localize time based on Unix timestamp:
    • wp_date( DATE_RFC3339, $timestamp )
  • store Unix timestamps or formats that are precise moment in time, such as DATE_RFC3339;
  • compare Unix timestamps, DateTimeInterface objects, or string–comparable dates in same time zone;
  • use DateTimeZone and DateTimeImmutable objects (with wp_date() for localization), if you need to operate with different time zones.

Summary

Date/Time core component had received much–needed fixes and a set of improvements. Code on WordPress platform will be more convenient and reliable with times and dates.

If you have questions about the improvements or component in general feel free to drop by #core-datetime channel in WordPress Slack.

#5-3, #dev-notes

Francesca Marano 5:04 pm on December 20, 2019
Tags:   

Call for volunteers: Release Model Working Group

The topic of the release cadence has been brought up multiple times over the past year:

  1. The original post about Major and Minor Version Release Cadence – February 27, 2019
  2. Recap of Devchat after the hour: November 20 – November 20, 2019
  3. Tentative Release Calendar 2020-2021 – November 21, 2019

There seems to be a strong will to increase the number of releases per year and some exploratory work has been already done by multiple sources. Now it’s time to put it all together and move forward with a plan of action.

What problem needs to be solved

WordPress releases involve quite a lot of manual labor and testing so the releases right now can’t be more than 3, 4 per year. Core contributors are eager to move to a more frequent cadence.

Scope of the Working Group

To evaluate what is needed to change the Core release model in terms of procedures, cadence, resources and produce a report that will:

  1. Document the existing release process
  2. Evaluate the technical changes needed to speed up the release process
  3. Evaluate if those changes are doable with the existing resources and tools

What has been done so far

A few people have already done some research and told their experience during dev chats or in the above-mentioned posts, including in the comments.

In particular, some blockers have been identified and the working group aims to document all of them and find reasonable and feasible solutions. Here is a nonexhaustive list of things that have been mentioned:

  • scoping the release
  • putting together a release team
  • the process itself: automated, semi-automated, manual tasks
  • supporting fewer PHP versions
  • supporting fewer WP versions (for security and other things)
  • better E2E tests and vuln tests
  • Tide support
  • writing the announcements
  • writing the dev notes
  • writing the field guide

Prerequisites

The team needs people with different skills and levels of expertise

  • A project manager/coordinator to make sure work gets done
  • People with commit and mission control experience to document the process of the release itself
  • People able to write E2E and vuln tests
  • People that worked in previous released and are familiar with the coordination part: from scope to release.
  • Historians! People that have been contributing for a while and are able to provide some background and context.
  • Anyone who is willing to help 🙂

Time commitment and frame

Between 2 and 3 hours a week, more if you want to!

By the end of 5.4 release the group should produce:

  1. A research of the various steps of the release
  2. An evaluation of the technical changes needed
  3. A draft of the feasible proposed changes

Communication and project management

I propose the group meets weekly in #Core and adopts a project management tool for the research phase – Trello would be my suggestion. Once it moves to build solutions (hopefully!) Trac or GitHub can be used.

Who is in?

Please drop your name, WordPress.org and Slack username in the comments if you are interested and how you think you can help.

Deadline: January 5. Hopefully, work will start on January 7th or 8th

Mervin Hernandez 4:54 pm on January 14, 2020
Tags: , ,   

WP Notify Meeting Recap – January 13 2020

This is a recap of the WP Notify meeting held on Monday, January 13, 2020, 14:00 UTC. You can read the meeting discussion here.

We’re resuming our work on the WP Notify project with better focus on actionable ways to address the challenge of notifications in WordPress.

We started by answering more pointed questions as to what the solution must address, and whether a temporary alternative should be entertained at all.

Temporary Solution

@psykro suggested to post a separate trac ticket, to improve the current admin_notices implementation, with sample code from @apedog

The benefit to this is that, as a team, we get something into core that improves users lives and we gain some real world experience of how the process could be improved by the final solution.

The negative is that it would mean this code is likely to be eventually replaced by our final, better solution. This very discussion, is the reason we want to present this concept to the community, for feedback on whether to a) expand admin_notices, or b) affirm the need for an entirely new replacement solution altogether, and what are the critical elements of that new approach

@schlessera is of the opinion, and rightly so, that any work done to improve the current admin_notices functionality is not worth the time. We should rather work on a solid, scalable and manageable solution for notification channels.

Permanent Solution (From The Onset)

A few of the very direct questions we must address for the replacement solution as suggested by @folleto are

  • What are we replacing? (if anything)
  • What kind of backward compatibility do we need?
  • What’s the minimal API and UI we need to build for a v1?

As we answer these questions, we’re keeping in mind the end-user experience together with the API required. For example, a notifications menu will need a completely new way of handling notifications in WordPress API through use of the database and rendering those messages.

As @schlessera pointed out “The initial UI should satisfy the 80% need of letting Core/plugins/themes communicate platform state changes within the admin dashboard in a scalable way where the user/user group keeps control.”

Meeting time

During the course of the meeting it became somewhat clear that the time of the meeting might be causing some problems for folks in different time zones. Conversation in the meeting became much more active after the first hour. Therefore we would like to know if the current meeting time is suitable, or if we should consider an alternative?

Next-Steps

Please comment with your thoughts below. You can also add comments your comments in the WP Notifications Project Google Doc under Section 1. “Objectives”

Next Slack Meeting

📅 Monday, January 20 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary