Author Archives: John Blackbourn

John Blackbourn 9:24 pm on April 8, 2024
Tags: ,   

Dropping support for PHP 7.0 and 7.1

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 7.0 or greater. The minimum supported version was last adjusted in WordPress 6.3 in August 2023, and since then usage of PHP 7.0 and 7.1 has dropped to a combined 2.45% of monitored WordPress installations as of April 2024.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 7.0 and 7.1 combined is well below that at 2.45%, the process to increase the minimum supported PHP version in this release can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the 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 and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is compatible with PHP 8.0 and 8.1 with exceptions. Support for PHP 8.2 and PHP 8.3 is considered 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. since WordPress 6.4. Please see the PHP Compatibility and WordPress Versions page in the handbook for full information.

What about security support?

Sites that are running PHP 7.0 or 7.1 will remain on the 6.5 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about the 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/ plugin?

The Gutenberg plugin, which is used for development of 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, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. The Gutenberg development team will likely also increase the minimum supported version of PHP to 7.2 in time for WordPress 6.6. See this issue on the Gutenberg repo for when this was last changed in WordPress 6.3.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of April 2024 look like this:

  • 8.3: 1.20%
  • 8.2: 12.07%
  • 8.1: 16.34%
  • 8.0: 12.25%
  • 7.4: 42.80%
  • 7.3: 4.79%
  • 7.2: 3.80%
  • 7.1: 0.95%
  • 7.0: 1.50%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to @chanthaboune for feedback and proof-reading this post.

#6-6, #php

John Blackbourn 5:45 pm on July 5, 2023
Tags:   

Dropping support for PHP 5

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5 will be dropped in WordPress 6.3, scheduled for release on August 8th 2023. The new minimum supported version of PHP will be 7.0.0. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 5.6.20 or greater. The minimum supported version was last adjusted in WordPress 5.2 in 2019, and since then usage of PHP 5.6 has dropped to 3.9% of monitored WordPress installations as of July 2023.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 5.6 is well below that at 3.9% and dropping by around 0.1% every few weeks, plans to increase the minimum supported PHP version can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the 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 and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

Support for PHP 8.0, 8.1, and 8.2 in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is very good, and a proposal for the criteria for removing the “beta” support label for each new PHP version has been published.

What about security support?

Sites that are running PHP 5.6 will remain on the 6.2 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about the 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/ plugin?

The Gutenberg plugin, which is used for development of 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, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. This means that the Gutenberg plugin will continue to support PHP 5.6 for the time being, most likely until WordPress 6.4 is released. See this issue on the Gutenberg repo for further information.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of July 2023 look like this:

  • 8.2: 2.11%
  • 8.1: 9.37%
  • 8.0: 14.05%
  • 7.4: 51.13%
  • 7.3: 7.92%
  • 7.2: 6.29%
  • 7.1: 1.38%
  • 7.0: 2.05%
  • 5.6: 3.93%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to those who provided feedback and proof-reading of this post: @azaozz @chanthaboune @flixos90 @hellofromtonya @javiercasares @joemcgill @jorbin @jrf @peterwilsoncc @sergeybiryukov

#php

John Blackbourn 6:16 pm on November 28, 2017
Tags:   

WordPress 4.9.1 beta

As mentioned earlier today, WordPress 4.9.1 has been scheduled for release tomorrow, November 29th, 20:00 UTC. Please have a read of that post for details of the fixes.

The beta package for 4.9.1 is now ready for testing. Please help us by testing this 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. to ensure 4.9.1 fixes the reported issues and doesn’t introduce any new ones.

#4-9-1

John Blackbourn 3:53 pm on November 28, 2017
Tags:   

WordPress 4.9.1 scheduled for November 29th

WordPress 4.9 has been downloaded over 6 million times since its release two weeks ago.

A small number of bugs have been identified which are impactful enough that the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team has decided to release 4.9.1 with fixes for those issues. The release is scheduled for tomorrow, November 29th, 20:00 UTC. A 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. release will be packaged later today and made available for testing.

The issues that have been fixed are:

  • #42573: File caching affecting users’ ability to use the 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 and theme file editors.
  • #42574: MediaElement upgrade causing JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. errors when certain languages are in use.
  • #42579: Incorrect logic in extract_from_markers().
  • #42454: Unable to translate Codex URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in theme editor.
  • #42609: Theme editor cannot edit files when running on a Windows server.
  • #42628: flatten_dirlist() doesn’t play nice with folders with numeric names.
  • #42634: DB_HOST socket paths with colons not parsed correctly.
  • #42641: On multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site upgrade the wp_blog_versions table doesn’t get updated
  • #42673: Themes page throws console error when there is only one installed theme.

In addition, one fix for a 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. introduced in WordPress 4.7 will be included in 4.9.1:

  • #42242: lang attribute in the adminadmin (and super admin) area doesn’t reflect a user’s language setting.

Stay tuned for the announcement of a beta package.

#4-9-1

John Blackbourn 7:50 pm on October 13, 2017
Tags: ,   

Account Security Improvements in WordPress 4.9

A few account security enhancements have gone into WordPress 4.9. The intention is to make it more difficult for an attacker to take over a user account or a site by changing the email address associated with the user or the site, and also to reduce the chance of a mistaken or erroneous change causing you to get locked out.

  • In order to change your user account email address, the site adminadmin (and super admin) email address, or the networknetwork (versus site, blog) admin email address on Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, a link now needs to be clicked in a confirmation email that gets sent to the new email address. This behaviour has existed for years on sites within a Multisite network — the functionality has now been ported to single site installations too. See #16470, #39118, and #39119.
  • The old site admin email address now gets notified of a change to the address (this includes the network admin email address on Multisite too). See #39117.
  • The email that’s sent to a user’s old email address when their email address is changed now includes the new email address. See #39112.

#4-9, #dev-notes

John Blackbourn 7:45 pm on May 25, 2017  

HHVM no longer part of WordPress core’s testing infrastructure

WordPress has never officially supported HHVM, but since WordPress 4.0 it has been compatible, largely thanks to the efforts of @wonderboymusic in #27881 and other tickets.

Many large scale sites which switched to HHVM around 2014 have since switched to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7, and usage numbers of HHVM according to the 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/ update statistics indicate that HHVM powers only several dozen WordPress websites as of April 2017.

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite when run on HHVM never actually passed (this may not be completely accurate, memories are hazy), often errored completely, and was always marked as an allowed failure. All of this, coupled with the disproportionately high amount of effort required to maintain the test and CI infrastructure for HHVM, means that WordPress core is no longer tested on HHVM as part of the Travis CI build. See #40548 for details.

If you’re running a WordPress website on HHVM, you should consider switching to PHP 7+ which is far more widely supported and tested, and offers all of the memory and performance benefits that HHVM pushed forward.

John Blackbourn 11:16 pm on April 23, 2017
Tags:   

Recent updates to the unit testing infrastructure

Several changes have made their way into WordPress’ unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite and its infrastructure recently. If you maintain a WordPress project (such as 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 or website) that has its own test coverage, you may be interested in porting some of these changes to your test suite too. Here’s a round-up:

  • Tests which require Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site to be enabled, or tests which should be excluded from running when Multisite is enabled, can now be placed into the new ms-required and ms-excluded groups to skip them automatically when the test requires Multisite to be in use, or when it requires Multisite to not be in use, respectively. In addition, the default configuration in phpunit.xml now excludes such test groups as appropriate without them being marked as skipped, which removes unwanted noise from PHPUnit’s reporting when run in verbose mode. See #40531.

Please note that this usage example has been updated from a previous version of this post.

Example usage:

/**
 * @group ms-required
 */
function test_something_on_multisite() {
	// Run your Multisite-only assertions here
}

/**
 * @group ms-excluded
 */
function test_something_without_multisite() {
	// Run your single-site-only assertions here
}
  • XDebug is now disabled when running tests on Travis in order to speed up the builds. This resulted in a huge reduction in build times, up to 40% in some cases. See #39978.
  • The PHPUnit version used when running tests on Travis is now explicitly coupled to the PHP version in order to avoid incompatibilities such as the one caused when PHPUnit 6 was rolled out. See [40269] for the main change and #40100 and #40086 for more info.
  • A compatibility shim for PHPUnit 6+ has been added, which means the test suite will no longer cause fatal errors if you want to update to PHPUnit 6+ locally or, for example, you want to require it through a Composer dependency. See #39822.
  • Several tests which were previously skipped when the environment wasn’t suitable will now cause failures, for example tests which depend on constants such as DISALLOW_FILE_MODS not being set. This is to avoid hiding tests that never run and therefore never fail if the assertions contained within them would otherwise fail. If the core test suite begins failing on your local environment as a result, you should address the cause. See #40533.
  • The number of PHP versions which older branches are tested against on Travis has been significantly reduced in order to speed up build times for patch releases. This is most beneficial when security fixes are released and backported. As a general rule, branch builds except the latest branch are now only tested on the oldest supported version (5.2), the latest in the 5.x branch, and the latest in the 7.x branch. See #40407.

#dev-notes

John Blackbourn 10:54 am on October 28, 2016
Tags: ,   

Fine grained capabilities for taxonomy terms in 4.7

WordPress 4.7 introduces new capabilities for individual taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. terms, allowing developers to implement more fine grained control over management of terms (including categories, tags, and custom taxonomy terms). The new capabilities are 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. capabilities that ultimately map back to existing capabilities, so there is no change in behaviour for existing functionality and users.

New Singular Capabilities

  • edit_term
  • delete_term
  • assign_term
In the same way that capabilities such as edit_post and delete_user are used to check that a user can perform the action for a specific post or user, these new capabilities can be used to check that a user can perform the action for a specific term. If you’re currently checking the edit_terms, delete_terms, and assign_terms capabilities, you can switch these over to the singular form and include the term ID as the second parameter. Example: 
if ( current_user_can( 'edit_term', $term_id ) ) {
	printf( '<a href="%s">Edit This</a>', get_edit_term_link( $term_id ) );
}
The new capabilities are meta capabilities — which means they ultimately map back to the existing manage_categories capability by default, or whichever capability has been specified in the corresponding capability arguments when registering the taxonomy. The actual required capabilities can be filtered using the map_meta_cap 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. like so: 
add_filter( 'map_meta_cap', function( $required_caps, $cap, $user_id, $args ) {
	switch ( $cap ) {

		case 'delete_term':
			$term_id = $args[0];
			// Prevent a "protected" term from being deleted:
			if ( get_term_meta( $term_id, 'protected', true ) ) {
				$required_caps[] = 'do_not_allow';
			}
			break;

		case 'edit_term':
			// Introduce some anarchy:
			if ( rand( 1, 6 ) == 3 ) {
				$required_caps[] = 'do_not_allow';
			}
			break;

	}

	return $required_caps;
}, 10, 4 );

Separate Capabilities for Tags and Categories

A related change is that the post tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) taxonomy now uses separate capabilities from the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. taxonomy by default (it previously used the same capabilities as the category taxonomy). This doesn’t alter existing behaviour (custom or otherwise), but it does mean that you can target capabilities for tags separately from categories. Example: 
add_filter( 'map_meta_cap', function( $required_caps, $cap, $user_id, $args ) {
	switch ( $cap ) {

		case 'manage_post_tags':
		case 'edit_post_tags':
		case 'delete_post_tags':
		case 'assign_post_tags':
			// Allow Authors to manage tags:
			$required_caps = array(
				'publish_posts',
			);
			break;

	}

	return $required_caps;
}, 10, 4 );
See TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #35614 for more information.

#4-7, #dev-notes

John Blackbourn 6:04 pm on October 3, 2016
Tags: ,   

Feature Project Proposal: Notifications API

Most of the situations where WordPress sends an outgoing email can be classified as a notification. X just happened on your website and you should be aware of it.

Back when WordPress was a youngster, the only way to reliably notify a user was via email. In 2016 we have many more options, including push notifications to mobile platforms, desktop notifications to browsers, messages to chat apps, endless services via webhooks, SMS messages, or even notifications in the WordPress adminadmin (and super admin) area. The list goes on. For many users, email is no longer the optimal delivery mechanism for ephemeral notifications.

To that end, let’s think about replacing wp_mail() with a modern 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. that allows developers to route notifications to services other than email, allow them to better modify notifications and the way in which they’re formatted, and allow them to do so without stepping on each others’ toes.

The current lack of a notifications API (or even an email sending API) can be easily summed up:

Problem: 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 A wants to provide HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. emails, and Plugin B wants to send emails via an email delivery service such as Mandrill. Plugin C wants to disregard emails and send 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/. notifications. It’s very difficult for these to co-exist.

Notification Destinations

There are only two types of destination for a notification in WordPress. Most notifications are actually notifications to a user account that get delivered via email because it’s the only contact information available for every user account. The remaining notifications are explicitly notifications to an email address rather than a user account (or not yet attached to a user account), such as when a user signs up for a blogblog (versus network, site) and needs to click a confirmation link before their user account gets created.

With this in mind, you might be able to imagine a notification class in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that defaults to delivering notifications via email, but which can be extended by a plugin on a per-user and per-notification basis to deliver notifications via any of the means listed above. WordPress core would support delivery via email and provide the API that allows plugins to implement delivery via other means.

With a well-designed API, multiple plugins can co-exist in order to deliver different notifications via different mechanisms, format email notifications as HTML, easily disable notifications, change the delivery mechanism for email notifications, or provide a UIUI User interface for users to manage their notification preferences and destinations.

Planning a Notifications API

I’d like to begin work on a feature project with the intent of designing and implementing such an API. I’d like to get input from authors of existing plugins that provide functionality such as delivering notifications via a service other than email, that override the default email delivery mechanism, or that implement extra notifications (such as e-commerce sale notifications), in order that the API can be backwards compatible and that we can get some plugin implementations built during the API’s development.

I already have some technical ideas regarding how the API might look, but I’m conscious that such an API needs to be well-designed before anyone jumps into writing code. Maybe we can even try some test-driven development? Who knows.

In addition, consultation and involvement with the team that are working on the two-factor authentication feature project is important as it implements several delivery mechanisms for 2FA codes that could potentially be made simpler with a notifications API.

Get Involved

Feedback is most welcome in the comments. Would you like to help out? Yes? Great. Let’s plan a date and time for a meeting in Slack and go from there.

Finally, a reminder that feature projects are not tied to a specific release of WordPress. This won’t make 4.7. It would be great if it was mature enough for 4.8, but we won’t be aiming for a particular release just yet.

#feature-plugins, #notifications

John Blackbourn 8:30 am on September 29, 2016
Tags:   

Reminder: HTTPS meeting tomorrow

The weekly meetings about HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. improvements in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will resume tomorrow at 16:00 UTC (Friday, September 30, 2016, 16:00 UTC) in the #core-http channel on 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/.. See you there!

#https