27 open tickets. Last 7 days: +0 tickets
|27 open tickets||defect (bug)||enhancement||feature request|
With the introduction of language packs two years ago (), it’s easier than ever for users to change the main language of their site. However, in some cases a single locale (i.e. the language variant, like Canadian French) is not enough.
Let’s say a site of mine is running German (Switzerland), which there is a language pack for. However, most plugins only have a German (Germany) translation, or perhaps only even a de_DE_formal translation. As a native German speaker, I’d prefer to read a German (Germany) translation instead of English, if a German (Switzerland) version did not exist. Instead of getting translations as I’d wish (as the translations are very similar), WordPress falls back to the original English strings. That’s a poor user experience for many non-English speakers. Now, since the addition of a user-specific language (#29783), this issue is even more important.
There’s been a long discussion about this issue in #28197, where possible solutions have been suggested without any consensus. Instead of directly talking about how this can be technically implemented, we should first explore the actual user experience problems and see what’s possible and how it might look.
For this, I began researching how other software approach this problem. Those of us interested in this problem can learn from existing solutions and proceed from there.
These screenshots should give you a better understanding of what I’m talking about:
As you can see, these software products create a “fallback chain” for the user’s preferred languages. In theory, I could also set my preferred languages to es_ES -> de_DE -> en_GB -> en_US, if that was the order in which I preferred translations.
To keep momentum and continue thinking through this problem, I want to kick off a feature project, about improving the experience for WordPress users who use the product in non-English languages, of which multiple locales may exist.
Your feedback is incredibly important to ensuring we get this right. Leave any thoughts in the comments below. Would you like to help out? Awesome. Let’s have an initial chat on Wednesday, 26 October 2016, 17:00 UTC in the #core-i18n Slack channel and go from there.
I’ve set up a GitHub repository that can be used as a playground for discussions, prototypes, and eventually a working solution. For this, design and accessibility feedback would be very helpful. I’m confident that we can build something that we can propose for inclusion in a future WordPress release!
It’s that time again: time to build a new default theme for WordPress!
WordPress 4.7 will launch with a brand new theme – Twenty Seventeen. Designed by Mel Choyce (@melchoyce), Twenty Seventeen sports a modern look and will make a good base for any business website or product showcase.
Check out the gallery below to preview our next default theme at full-size:
In addition to having a wide appeal, Twenty Seventeen will focus on providing a seamless initial theme setup so anyone can set up a website for themselves or their business with minimal hassle.
Twenty Seventeen aims to show off some new core features and enhancements, such as:
Mel will keep an eye on all things design during the creation of Twenty Seventeen. Laurel Fulford (@laurelfulford) and David Kennedy (@davidakennedy) will assist her, leading the theme’s development. Lots of opportunities exist this year for getting involved with Twenty Seventeen – we need your help, and lots of it! 🙏🏽
Backing up the Twenty Seventeen team will be a team focusing on the core Themes API. This team is looking for new and experienced core developers with theme experience to help lead and contribute to specific features.
Similar to feature projects, the initial development of the theme will be on GitHub. Once it’s usable and stable, the theme will be merged into core and the GitHub repo will be deprecated. After it’s merged, all issues should be reported to Trac.
Twenty Seventeen will also use plain CSS — it won’t use preprocessors in the development of the theme. This will keep it simple, making the theme easier for everyone to understand, quicker for anyone to modify and better to maintain in the long run.
Throughout the process of building Twenty Seventeen, the team will be collaborating with the Theme Review Team and the core development team to make sure it is up to core standards.
There will be weekly meetings every Friday at 18:00 UTC in #core-themes starting today. During that time, the focus will be on the theme itself. If you are interested in contributing, keep an eye out here for updates or join us in #core-themes in Slack.
If you have some early thoughts on what would make this a great WordPress experience, or if you’re generally interested in participating, sound off in the comments. Please hold any design feedback for Friday’s meeting. where we can have a conversation about it in greater depth.
Here are some links where you can find out more about past default themes:
We’re planning to have weekly meetings in the #core-images Slack channel throughout the 4.7 release cycle. The kickoff meeting is set for today, August 26, at 19:00 UTC. We will use these meetings to keep projects moving forward and to discuss any priority tickets that require discussion.
The main purpose of the kickoff meeting is to identify the priority projects for 4.7 and to determine who is available to work on those projects. We will also review the current meeting schedule to see if a different time would be better for those wanting to be involved.
Additional issues that were mentioned in the comments of the 4.7 wishlist post include:
wp_ajax_save_attachment()for additional attachment fields (#23148)
Welcome back the latest issue of Week in Core, covering changes [38274-38345]. Here are the highlights:
Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.
.nav-tab-wrapperclass to be used on elements other than
h3to increase flexibility for custom settings pages.  #37257
wp_doing_ajax(), which can replace… (wait for it…)
DOING_AJAXchecks via the constant.  #25669
$cache_missesis public, but
$cache_hitsis private. They should both be
public, because they’re useful for debugging purposes.  #37726
$_wp_unfiltered_html_commentis passed as part of
$comment_data, but is not used locally.  #37771
continueif there is an empty array in the loop.  #37416
count()in the first
forexpression so that it does not run on each iteration.  #37416
wpdb::_escape(), thus requiring it to be
public. It previously had no access modifier.
_at the beginning of a method, believe it or not, does not enforce visibility constraints.  #37771
customize-nav-menus.jsto remove references to Menu Customizer plugin. Also fix
updateAssignedLocationsInSectionTitle.  #37520
WP_Customize_Manager::validate_setting_values()to reflect changes in .  #37247, #37759
wpdb::prepare(), which should not be called statically.  #37744
load_plugin_textdomain()parameter description.  #37318
get_oembed_endpoint_url(), avoid inadvertent stomping of the
$formatparameter passed to
oembed_endpoint_urlfilter.  #37751
$headerswere swapped. Let us correct this.  #37771
wp-includes/functions.wp-scripts.php.  #37803
wp-includes/functions.php.  #37802
wp-includes/deprecated.php.  #37797
wp-includes/class-walker-comment.php.  #37796
wp-includes/author-template.php.  #37795
wp-includes/admin-bar.php.  #37794
wp_post_revision_title_expanded().  #37781
wp_post_revision_title_expanded().  #37778
%s Sitesstring in
network_step1().  #37777
%s KBstring on Network Settings screen.  #37496
Edit Site: %sstring in network admin.  #37776
wp-mail.phpshould return a
403 Forbiddenstatus code instead if
500 Internal Server Error.  #37572
_load_image_to_edit_path().  #37681
gallery_shortcode().  #37771
wp_get_additional_image_sizes(), that wraps the retrieval of the global
$_wp_additional_image_sizes. Removes 6 global imports.  #37699
get_post_meta()where appropriate.  #36246
wp_get_attachment_link()fails to output text for non-images if the attachment post doesn’t have a title and
$text(argument #5) was not passed to the func. In this case, use the filename.  #5, #37343
pathinfo(), also pass a
PATHINFO_*constant to avoid array notices for unset keys.  #37608
media-gallery.jsRIP.  #37717
WP_Site_Query.  #37621
WP_Date_Query, removes need to import
global $wpdbin multiple methods.  #37699
WP_Query, removes need to import
global $wpdbin multiple methods.  #37699
$db, (composition, as it were) to
WP_*_Queryclasses to hold the value for the database abstraction, instead of importing the
global $wpdbinto every method that uses it. Reduces the number of global imports by 32.  #37699
get_terms(), do not assume that legacy args are being passed when the only params are top-level
meta_*values. Add keys in
WP_Term_Query::__construct(). Adds unit tests.  #37568
WP_Term::__get().  #37771
is_object_in_term(), return error object rather than caching it.  #32044, #36814, #37721
create()method should match signature of other
create()methods. Legacy argument format continues to be accepted.  #37630
db. Casting to
arrayis not the most elegant thing here, and various versions of PHP key protected/private fields differently when objects are cast.  #37699
get_attachment_taxonomies().  #37368
get_object_taxonomies().  #37368
@propertyannotation, instead of a
publicfield.  #37771
$user_levelhas been publicly-accessed on instances of
WP_Usersince version 2.0, but is has never been declared.  #37771
$alt_option_namehave been used as members ever since
WP_Widgetbecame an object in 2.8, but never declared.  #37771
Thanks to @afercia, @Akeif, @azaozz, @bcole808, @boonebgorges, @Clorith, @codemovementpk, @danhgilmore, @danielbachhuber, @dd32, @deremohan, @dlh, @DrewAPicture, @flixos90, @fomenkoandrey, @Frank, @gma992, @henrywright, @iandunn, @imath, @JaworskiMatt, @jipmoors, @Jonnyauk, @jorbin, @JorritSchippers, @Klein, @kouratoras, @Mte90, @Presskopp, @ramiy, @rpayne7264, @sebastianpisula, @SergeyBiryukov, @swissspidy, @tivnet, @TJNowell, @tomdxw, @vishalkakadiya, @westonruter, and @wonderboymusic for their contributions!
Trunk has been open for 4.7 commits for a couple weeks now, with 4.7 formally kicking off next week – more on that to come shortly. To help get an understanding of what people want to see in 4.7 (and beyond), chime in below with pet tickets, projects, and other wishlist items‡. If you’re able to work on your suggestion, please also indicate that. As both the release lead and a lead developer, I have plenty of thoughts of my own, but right now I want to hear yours.
‡ Disclaimer: Comments do not constitute binding contracts. 🙂
wpview editor plugin (that is responsible for showing gallery, video, audio, and oEmbed previews) was updated to use the TinyMCE API for non-editable elements. This brought some small changes and improvements in the UI, for example “views” are draggable now. On the back-end the
wp-mce-view-unbind event was removed as it doesn’t exist in the API. It was intended for cleanup/unloading but was never very reliable. If a plugin needs to unload instance dependent scripts, it can use mutation observer to monitor when the view node is deleted. See #36434 for more information.
wpview remains an experimental API, though with each iteration it is getting closer to being finalized. As an experimental API, breaking changes are expected. As always, please test your plugin now if it modifies or depends on the editor, especially if you use experimental features like
When WordPress switched to Open Sans in version 3.8 at the end of 2013, the state of typography on the web was just beginning to evolve. Before, our choices for typefaces were limited to a small subset of fonts reliably installed on most major operating systems. And, in some cases, those fonts were optimized for print, not the web. Open Sans is optimized for the screen, has generous character support, and, best of all, is open source. For these reasons, it was a better option for a modern web app than the system fonts of that time.
Today, the landscape has changed. The majority of our users are now on devices that use great system fonts for their user interface. System fonts load more quickly, have better language support, and make web apps look more like native apps. By using the same font that the user’s device does, WordPress looks more familiar as a result. This change prioritizes consistency from the user’s perspective over consistency in branding. And while typography does play a role in the WordPress brand, the use of color, iconography, and information architecture still feels very much like WordPress.
Safari, Chrome, and Firefox on iOS and macOS have new CSS values that return the current system UI font, but on other platforms, the font has to be declared by name. As such, the font stack includes the following:
-apple-systemfor Safari (iOS & macOS) and Firefox macOS
BlinkMacSystemFontfor Chrome macOS
Segoe UIfor Windows
Robotofor Android and Chrome OS
Helvetica Neuefor versions of macOS prior to 10.11
sans-serif, the standard fallback
The complete CSS declaration:
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
The operating system’s UI font is used for any text that’s part of the WordPress user interface. In other contexts, like the Editor, we continue to use a serif system typeface, Georgia. This creates a clear typographic distinction between text that is part of the interface, and text that is part of the user’s content.
Not all system fonts provide the same range of weights that Open Sans did. We recommend using only the 400 and 600 weights, which will display most consistently across all platforms. I’ve created a test page that shows the difference between Open Sans and your current device’s system font at every available weight. (A collection of screenshots of that test page is also available).
The order in which they’re called is important, because we want the user’s system font to be the first available font in the stack. For example: if Roboto were listed ahead of Segoe UI, Windows developers who have installed the Roboto font for Android development would see it instead of their native system font. There may be edge cases if users have manually installed these fonts on their machines, but this order should work best for the majority of users.
When using this font stack, it must be called using the
font-family property, and not the
font shorthand. This works around an issue in Microsoft Edge.
All screenshots were taken on a retina (2dppx) device. If you’re reviewing screenshots on a non-retina display, check out this Cloudup gallery of 1x screenshots.
A few days ago an ImageMagick vulnerability was disclosed dubbed “ImageTragick” that affects WordPress websites whose host has ImageMagick installed. If you control your own hosting for your WordPress site, you should look to implement the following fix(es) immediately.
The full effect of this issue is still unfolding and it’s not clear what the full impact will be; however, there are mitigation steps that should keep you safe with the known exploits so far. This vulnerability is already being exploited in the wild, and proof of concepts are being published.
Uploaded images to the WordPress admin that contain malicious data can perform a number of exploits via the underlying ImageMagick library. Uploads are available to all users who have the
upload_files capability. By default that’s authors, editors, and administrators; contributors, subscribers, and anonymous users do not have that capability. This issue is still developing; however, it should be noted that if un-patched, this exploit allows for Remote Code Execution (RCE).
The exploit is in the Imagick PHP extension, not WordPress itself (or any library that is shipped with WordPress). The WordPress Security Team is exploring ways to help mitigate this exploit due to the wide usage of ImageMagick in the WordPress ecosystem; however, this exploit is best handled at the hosting level (instructions below).
If you do not control your own hosting environment then it’s likely that your host is taking steps to fix the issue. We recommend you reach out to your hosting provider to verify they are handling the “ImageTragick (CVE-2016-3714, CVE-2016-3718 and CVE-2016-3715)” exploit.
Only WordPress sites that have the PHP Imagick extension installed are vulnerable to this exploit. If you don’t know if your server has this PHP extension, there are a few ways to identify this:
phpinfo()function for “Imagick”.
php -m | grep imagickon the command line.
Currently the best known fix is to add a
policy.xml file to your ImageMagick installation to limit the delegates that ImageMagick will use. Due to the ongoing nature of this issue, we recommend you refer to and follow https://imagetragick.com/ for instructions on how to handle the problem.
ImageMagick released an update on 2016-05-03 to fix this issue; however, there are questions around whether this update provides a complete fix. At the time of writing it should be presumed version 6.9.3-10 does not fix the issues completely and you should take steps to patch the issue via the
More information and updates on this exploit can be found at https://imagetragick.com/. We recommend you keep an eye out for updates to this issue, as the full extent of problem is still being discovered.
Documentation on the
policy.xml file can be found at https://www.imagemagick.org/script/resources.php.
Note: This project is currently a Trac ticket that has been committed for 4.6 (#36753) and is available for testing in trunk/nightlies.
When a visual and small screen admin refresh was introduced in 3.8 (by way of the feature plugin MP6), the admin font was changed to Open Sans to better complement the redesigned vector iconography. This change was not without its bumps or controversy, notably around extended character sets and that it is loaded from Google Fonts for a variety of reasons.
Instead of relying on an external resource, Font Natively moves the WordPress admin back to system fonts. This leads to faster load times, especially when working offline, a removal of a third-party dependency, and a more native-feeling experience as the lines between web experiences and apps continue to blur.
Documentation & Testing – This needs to be tested for any misalignments or other issues when switching to system fonts.