Make WordPress Core

Updates from Aaron Jorbin Toggle Comment Threads | Keyboard Shortcuts

  • Aaron Jorbin 5:15 pm on July 6, 2016 Permalink |
    Tags: , Bootstrap/Load,   

    Bootstrap/Load updates in 4.6 

    Every time WordPress is loaded, it goes through the bootstrap or loading process. In WordPress 4.6, there will be a few changes to the process focused on making pieces available earlier. Many of these changes will have no effect whatsoever on the vast majority of WordPress sites. However, if you are the type that maintains your own advanced-cache.php drop-in, host/run large profile sites, or work on tools that bootstrap WordPress is odd ways than this article is for you!

    Load plugin.php earlier in wp-settings.php

    plugin.php contains the functions such as add_filter() and add_action() that form the foundation of the WordPress plugin system. The file (and thus those functions) are now being loaded earlier in wp-settings.php. This allows for some hooks to be placed earlier, but also for advance-cache.php drop-ins to use the plugins API rather than directly manipulating global variables. For more information, see #36819.

    Reconcile wp-settings-cli.php with wp-settings.php

    Any time WordPress made a change to wp-settings.php, it inevitably broke WP-CLI. In order to allow WP-CLI to no longer need to maintain a custom fork, a handful of new hooks were added to the bootstrap process. These hooks happen before plugins load. They are designed more for non-web uses such as WP-CLI. For more information about these hooks, see #34936.

    is_ssl() is now located in wp-includes/load.php

    Many advanced-cache.php drop-ins duplicate is_ssl(). They will no longer need to do that as it will be available earlier in the bootstrap process. See #35844 for more info on this change.

    ABSPATH can now be safely defined before WordPress is loaded

    Defining ABSPATH in an auto_prepend_file will no longer cause notices to be generated. This can lead to less complexity for some WordPress specific hosts. See #26592 for more info on this change.

    In conclusion

    The bootstrap process provides the foundation for WordPress. It’s not pure, but dang zimit, it works. These changes are all expected to be backward compatible. Please test and report any regressions on Trac.

    Thanks to the following people who contributed to the Bootstrap component this release. @jorbin @danielbachhuber @DrewAPicture @ocean90 @barry @SergeyBiryukov @johnjamesjacoby

  • Aaron Jorbin 8:52 pm on March 30, 2016 Permalink |
    Tags: , ,   

    WordPress 4.5 Field Guide 

    WordPress 4.5 is the next major version of WordPress and with it come some bang bang changes. This guide will describe many of the developer-focused changes to help you test your themes, plugins, and sites. So grab a ☕️ ,🍷,🍵, or 🍺 and get ready for what’s coming soon.

    JavaScript! and CSS!

    Multiple external libraries have been updated with the two that require your attention being Backbone and Underscore. There were some‼️ breaking changes ‼️ with these two libraries, so make sure to test your code if you use either of these.  jQuery and jQuery Migrate have also been updated, please test with the unminified versions in order to ensure future compatibility with WordPress.

    The script loader has been updated with three big changes. The build process no longer creates wp-admin.min.css, wp_add_inline_script() joins the family of functions, and better support for multigenerational dependencies is included.

    Term Edit Page! –‼️ Backward Incompatible change‼️

    The term edit screen has been separated out from the term list screen. This brings greater consistency to how the admin generates screens for terms and posts but at the cost of the need to change how you register scripts and how you detect that you are on a term edit screen.

    Live Preview: Faster, Extensible, More Features!

    Live Preview (also known as “The Customizer”) once again has received attention this release with the addition of new controls, some performance improvements that require your attention to implement, and a two new user-facing features.

    Setting-less Controls, Device Previews, and Selective Refresh are the three biggest changes you’ll find. Setting-less controls make it easier for you to implement complex interfaces. Device Preview is a user facing feature that allows users to adjust the preview to match the screens on various devices.  This feature includes filters to change the devices users can choose. Selective Refresh allows for changes to appear quicker inside the preview, and you can do so with less code than before. Theme authors need to make changes to take advantage of selective refresh. Luckily, the change will generally result in fewer lines of code needed overall ( more 🍎 than 🍏 ).

    One area that selective refresh helps live preview function faster is with widgets.

    ‼️ If you offer sidebars or a widget in your theme or plugin, please update your code to implement selective refreshBoth themes and widgets need to indicate support, so please update your code accordingly.

    The final change to Live Preview involves a control for a new theme feature, and that is Custom Theme Logos.

    Custom Theme Logos!

    Themes can now offer support for custom logos. Custom Logos add an additional way for users to customize their site and theme developers can customize how custom logos are displayed.

    Image Performance!

    Following up on the introduction of responsive images in WordPress 4.4, WordPress 4.5 is making changes to improve image performance including improved compression settings and smarter handling of image metadata.

    Embed Templates! (and other iterations)

    Iterating on embeds has led to the ability to better customize embeds by adding new templates to the template hierarchy for embeds. Embeds have also had some performance improvements for autodiscovery, the ability to embed the front page of a site, and changes to the iframe of embedded content.

    Comments Component!

    The comments component has a few user-facing changes to make comments easier to moderate. For developers, the most notable change is the ability to adjust field lengths for your custom database schema. Additionally, the rel=nofollow attribute and value pair will no longer be added to relative or same domain links within comment_content.


    Multisite once again has seen changes with the addition of new filters around site and user creation, and a WP_Site object.

    And more!

    Overall, 372 bugs have been marked as fixed in WordPress 4.5 (so far). There are also dozens of new hooks and dozens of hooks that have received additional parameters. It’s entirely possible that one or more has caused a regression, so please make sure to test your code deeply and report any issues you find.

  • Aaron Jorbin 9:56 pm on February 23, 2016 Permalink  

    4.5 Enhancements Scrub 

    4.5 beta 1 is scheduled to be released tomorrow. To help facilitate it, we are going to have a scrub VERY SOON of the open enhancements (this list needs to be zero before tomorrow). At 7pm EST today (aka, about 2 hours from this being published), join the #core room on slack to help scrub this list down to nothing.

  • Aaron Jorbin 9:13 pm on January 24, 2016 Permalink  

    Accessibility Coding Standards now in draft and seeking comments. 

    The WordPress Accessibility Team has created draft Accessibility Coding Standards for the core handbook.  These standards will remain in draft format for at least the next two weeks while everyone has an opportunity to review and comment.  If there are significant changes made based on the comments, additional posts here will be made announcing them and seeking further comments.

    Please review the draft standards and leave your comments on this post.

  • Aaron Jorbin 12:17 am on January 5, 2016 Permalink
    Tags: , 4.4.1, ,   

    4.4.1 Release Candidate 

    A Release Candidate for WordPress 4.4.1 is now available. This maintenance release is scheduled for Wednesday, January 6, but first it needs your testing. This release fixes 52 issues reported against 4.4.

    WordPress 4.4 has thus far been downloaded over 7 million times since it’s release on December 8. Please test this release candidate to ensure 4.4.1 fixes the reported issues and doesn’t introduce any new ones.


    A total of 36 contributors have contributed to 4.4.1:

    Compute, DvanKooten, JPr, KrissieV, SergeyBiryukov, ShinichiN, aaroncampbell, afercia, azaozz, boonebgorges, dd32, dossy, eherman24, gblsm, hnle, igmoweb, jadpm, jeff@pyebrook.com, joemcgill, johnbillion, jorbin, meitar, nacin, netweb, obenland, ocean90, pento, peterwilsoncc, redsweater, rmccue, rogerhub, salcode, smerriman, scottbrownconsulting, stephenharris, swissspidy, tharsheblows, tyxla, voldemortensen, webaware, wonderboymusic, wp-architect

    Notable Bug Fixes

    Two severe bugs have been fixed. In some cases, users with an out of date version of OpenSSL being used by PHP were unable to use the HTTP API to communicate with to communicate with some https sites. Additionally, posts that reused a slug (or a part of a slug) would be redirected.
    The polyfill for emoji support has been updated to support Unicode 8.0. This means that diversity emoji, and other new emoji like 🌮 and 🏒 are fully supported. 

    All Changes

    Most components have received at least one change. This is a list of all tickets closed, sorted by component.
    (More …)

  • Aaron Jorbin 4:18 pm on November 11, 2015 Permalink
    Tags: , ,   

    WordPress 4.4: Field Guide 

    WordPress 4.4 is the next major release of WordPress and is shaping up to be an amazing release. While you have likely discovered many of the changes from testing your plugins, themes, and sites (you have been testing, right?), this post highlights some of the exciting 🎉changes developers can look forward to. 💥

    Externally Embeddable

    New Embeds Feature in WordPress 4.4

    Using a handful of filters, you can customize how your site looks when it’s embedded elsewhere. As a part of the work around embeds, there are also a couple of new functions for retrieving and displaying embeddable content. The post above also links to a plugin which will remove the ability to embed your site elsewhere.

    REST API Infrastructure Introduction

    The infrastructure to create a REST API has landed in WordPress core.  Adding your own endpoints (or using the latest version of the REST API plugin) is now even easier.  The new embed feature mentioned above uses this new infrastructure.
    Note: If you are using v1 of the API plugin, it is incompatible with 4.4, however an update is planned before 4.4 ships. The update will not use the new REST API infrastructure, so you’ll want to update your REST API usage eventually. If you are using v2 of the API plugin, be sure you’re on beta 5 or later; previous versions do not support WordPress 4.4.

    Responsive Image Insertion

    Through the use of a display filter, image tags in WordPress now include srcset and sizes.  These two attributes to the <img> tag allow browsers to choose the most appropriate image size and download it, ignoring the others. This can save bandwidth and speed up page load times. There are new functions, filters, and an additional default image size available to help with the creation of responsive images.

    wp_title Deprecation Decision

    Since WordPress 4.1, add_theme_support( 'title-tag' ); has been the recommended way of outputing a title tag for themes.  Now, a year later the wp_title function has been officially deprecated. Take a look at this post if you want to see all the great new filters you can use to modify title tags.

    UPDATE 12 November – wp_title has been reinstated for the time being. It is a zombie function.  add_theme_support( 'title-tag' ); remains the recommended way to insert a title tag into your theme, however there were use cases for wp_title that were not accounted for in the original deprecation decison

    Term Taxonomy Tranquility

    WordPress 4.4 is the latest in a string of releases to feature major updates to the taxonomy system. This release introduces of term meta, a new WP_Term class, and a host of other under the hood changes.

    Comment Component Cultivation

    Comment Object and Query Features in 4.4

    Changes to fields output by comment_form in WordPress 4.4

    Comments received love both on the front end of sites and on the backend. On the front-end, the comment field will always appear first, before the name and email fields. This fixes a longstanding bug where the behavior was different for logged in and logged out users.

    Under the hood, comments are now represented by a WP_Comment class and comment queries are now considerably more powerful.

    Multisite Momentum

    Like taxonomy and comments, the multisite features gains a new class, WP_Network. Additionally, there are now *_network_option functions which make it easier to use multiple networks. The linked post also highlights new hooks, some notable bug fixes, and two newly-deprecated functions. If you use WordPress in a multisite environment, this is a must-read.

    Heading Hierarchy Happiness

    Headings on the admin screens are now more semantic. Be sure to update your custom admin screens to follow the proper heading structure. These changes help users of assistive technologies, such as screen readers.

    Twenty Sixteen

    Each year, WordPress releases a new default theme and this year is no exception. Twenty Sixteen is a brand new theme, bundled with WordPress 4.4. Default themes are incredibly popular; be sure to test your plugins to ensure they function well with Twenty Sixteen.

    Other Notes

    So far, this release has had over two thousand commits. There are many additional changes not outlined above including: the removal of support for my-hacks.php(Update Nov 20th: My Hacks support was added back), giving add_rewrite_rule support for an easier-to-read syntax, support for single-{post_type}-{post_name} in the template hierarchy, pretty permalinks for unattached media, and stronger enforcement of the show_ui argument in custom post types. As with every major update, it is very important to test every feature in your plugins and themes to ensure there are no regressions in their behavior.


    If you haven’t been testing your themes, plugins, and sites with WordPress 4.4, now is a great time to start. You can grab a copy from svn (or git), download the nightly builds, or install it using the Beta Tester Plugin.

    WordPress 4.4 is not recommended for use on production servers until the final release has been announced on the WordPress News blog. The release is currently targeted for December 8, 2015. Get testing today!

    • Xavier Borderie 9:13 am on November 12, 2015 Permalink | Log in to Reply

      Very useful, thanks a lot Aaron!

    • Shah Alom 2:29 pm on November 12, 2015 Permalink | Log in to Reply

      Very helpful on the first look … Thanks!

    • Ahmad Awais 6:50 pm on November 12, 2015 Permalink | Log in to Reply

      Thanks for enlisting everything, Aaron! I’ve been fortunate enough to contribute to the REST API, Headings Hierarchy and Twenty Sixteen theme. Looking forward to WP 4.4 in December.

    • Nisha 12:55 pm on November 13, 2015 Permalink | Log in to Reply

      Thanks for the update Aaron. Looking forward to new features in WP 4.4.

    • jomarlipon 12:10 am on November 19, 2015 Permalink | Log in to Reply

      Looking forward to this update. 🙂

    • dawesi 4:54 am on November 20, 2015 Permalink | Log in to Reply

      So great seeing major breaking changes in a dot release. So glad you’re using professional standards and only releasing breaking changes in major versions… oh wait..

      Too many breaking changes, my clients want out of wordpress. It’s your reputation, 4.3 was the WORST software release of any company in the world in 2015, 4.4 better be PERFECT or you’ll be winning more shonkey awards.

      Our clients want OUT if 4.4 breaks ANYTHING out of the box. (2400 wordpress sites GONE overnight)

      Some great features here that should be in 5.0… goes to show this product is off the rails.

      • Samuel Sidler 3:18 pm on November 20, 2015 Permalink | Log in to Reply


        WordPress 4.4 is considered a major release, just as WordPress 4.3 was considered a major release. WordPress 5.0 will be another major release and no different than WordPress 4.9 or 5.1. More information about our versioning is available in the handbook.

        Regarding quality, note that 4.3 was one of the most solid WordPress releases we’ve had in years, only requiring minor fixes after its release and being adopted at a faster rate than any previous release in recent memory. What issues affected you?

      • demixpress 3:57 pm on November 27, 2015 Permalink | Log in to Reply

        The version numbering of WordPress is great, or it may be another Android in CMS.

    • wpsupporthq 4:06 am on November 29, 2015 Permalink | Log in to Reply

      Thanks Aaron! This is a great rundown of the upcoming changes.

  • Aaron Jorbin 5:25 pm on September 30, 2015 Permalink
    Tags: make/core, , this is so meta   

    Proposal: Make/Core Post Guidelines 

    During the 4.3 retrospective, one commonly mentioned theme was make/core posts and improving their style and language. All active contributors should review this post and comment with your feedback. This is a DRAFT and a PROPOSAL, it is not a whack from above with Mjölnir. After revising, this document will live in the core handbook.


    The Make WordPress Core Blog (make/core) is the official blog of the WordPress core team. It is read by thousands of people, many of which don’t know the intricacies of WordPress core or that don’t fully understand the process of how core is developed. In order to ensure the best experience possible for the developer community, these guidelines are developed with the reader in mind. The goal of most make/core posts is two-fold: to generate feedback from the developer community (including testing) and to ensure developers know about changes and can plan accordingly.

    When to write a post

    All API changes should have a post written on the make/core blog, ideally no later than the first week of the beta period.   Examples of API changes that should be announced include, but are not limited to: new filters, new actions, changed order of hooks, substantial enhancements to queries (The Boone Gorges Rule), Doing a ticket binge on a component, changing the purpose of a parameter in a hook, and new general helper functions.

    Grouping related changes into one post is fine. For example, a single post called “Customizer changes in WordPress 4.2” is fine, rather than individual changes about each commit. If in doubt, discuss your posting plans during the weekly dev chat.

    Changes should be announced as early as feasible. There is almost always more feedback on make/core posts than in Trac tickets. This feedback is important to the development process.

    Peer Review

    It is strongly encouraged to ask a committer to proofread a post before publishing it. This is to ensure that you look your best when publishing a post. Merge Proposals should always be read by the release lead (or a designee) before posting. Release dev notes should be read by the release lead (or a designee) before publishing.

    Style and Substance

    First Person pronouns should be avoided. As the blog is the official voice of the core team, you should keep your personal thoughts out of the body of the post and instead put them in comments.

    In general, the word “We” should be avoided without it being very clear who the group is you are speaking about being a member of.

    Posts that are designed as Requests for Comments or are draft roadmap in nature should make sure to highlight that it is a draft proposal. Highlight this in the title and in the opening paragraph.

    Many people reading make/core don’t speak English as a first language (or in the case of Jorbin, don’t read or write in any known language). Keep that in mind when choosing words. It’s better to keep it simple than it is to sound smart. In general, the tone should be similar to WordPress: Friendly.

    Meeting Announcements

    When announcing a meeting, you should always use the time shortcode so that visitors see when a meeting is in their local time. You should also include what slack channel the meeting will take place in.


    Almost all posts are related to a specific component, please tag them with the component name.
    For announcements related to a specific release, please tag them with the release number.
    For announcements of API changes, including additions, please tag them with dev-notes.
    For posts related individual projects and initiatives, please tag them consistently with a project name.

    • Konstantin Obenland 5:42 pm on September 30, 2015 Permalink | Log in to Reply

      I appreciate your quest for better documentation and an improved experience around dev notes for new releases. However I don’t think that it is feasible or even desirable to have every new filter, action, or function announced here. I fear it will lead to reading fatigue when important posts are buried in minor dev notes and adds a considerable burden to every commit (where these things are already documented) which in return has the potential to further increase the committer bottleneck that we’re trying to remove.

      I’m generally against rules and guidelines and instead rather rely on common sense wherever possible. This seems like a good opportunity to remind people about values and the importance of the points you mentioned, but I would be disappointed if we used it to introduce rules and requirements around posting here.

      • Helen Hou-Sandi 6:15 pm on September 30, 2015 Permalink | Log in to Reply

        I don’t think this is saying that every new thing be documented on Make/Core individually – those are examples of the type of content you might find here. Most of those things (hooks, functions, parameters) are included in the weekly summary posts. The proposal does say “Grouping related changes into one post is fine.” – being related by time seems reasonable to me.

        I think it’s been demonstrated here and elsewhere that “common sense” is not actually “common” (as in shared). There have been numerous very distracting and draining issues stemming from poor communication, most of them avoidable. For instance, the 4.3 retrospective post did not make it clear that the bullet points listed out were direct quotes, not processed or prioritized information, or that the concluding paragraph was a personal note and not a team conclusion, and the few comments that followed reflected that. And those are mild comments.

        You could say that commit message contents are mostly “common sense”, but I was more than happy to write them out, and the commit messages ever since have been much more consistent and helpful. Including more extended information based on guidelines such as including the why/backstory of a change has really helped on many fronts, including easing in the introduction of changes that might otherwise be contentious.

        If we don’t document things like this, we continue to rely on the institutional knowledge of individuals, which is a fragile reliance, constantly shifting based on who’s around at a given moment, and also does not provide any view into the history of how something has evolved. This is a rather general set of guidelines – if nothing else, they’re a good introductory document that we can link to people who are writing on Make/Core for the first time.

      • Aaron Jorbin 7:41 pm on September 30, 2015 Permalink | Log in to Reply

        Thanks for the feedback Konstantin. I agree that reader fatigue is a concern, which is why the suggestion to group related changes into one post. This could be a component summary, or this could be a generalized “Minor API changes you should know about in WordPress 4.4” post.

        It also doesn’t need to be the committer that writes these posts. I am happy to make any regular contributor[s] to WordPress a contributor [role] on this site.

        I also don’t like rules, which is why I didn’t frame these as rules. This isn’t a set of rules that you will be punished if you break them. This is documenting institutional knowledge that we don’t often do a good job of sharing. You and I who have been contributing and writing posts for a while know what we need to. Guidelines makes a lot more sense than “All the advice I have recieved or given”, but if you have a better idea of how to phrase it, I’d love a suggestion.

    • Knut Sparhell 11:06 pm on September 30, 2015 Permalink | Log in to Reply

      1. This seems like a good start for a set of guidelines.

      2. When to post, what to post, who to post this, should be a set of rules or best practices, separate from how to post and the guidelines for the content, tone and language of such a post.

      3. This a core development blog, and the audience is developers (but not only coders). Don’t make it more simple than necessary. Non-developers, end users, will have other sources. See 4. below.

      4. Please avoid acronyms not very common among developers globally. Example: API is ok, SXSW is not.

      5. Important changes in workflow for end users should be announced or proposed on the wordpress.org/news blog (too), may be with a link to a post on this blog. It seems the news blog is only used for release announcements. There’s never anything about what is, or may be, coming in the next release.

    • Ryan McCue 1:00 am on October 1, 2015 Permalink | Log in to Reply

      In general, the word “We” should be avoided without it being very clear who the group is you are speaking about being a member of.

      While I agree in general with the guidelines, I disagree with this part. Generally, I think it’s pretty clear what group you’re part of, and it helps give it a lighter and more conversational tone.

      • Dion Hulse 8:44 am on October 1, 2015 Permalink | Log in to Reply

        Unfortunately it’s often very murky slope though.
        It’s often clear to those of us who are active, but for those who are not, or for whom English is a second (or third) language, it can be difficult to distinguish it from the person or team vs. “WordPress said this” – and that’s what the Guideline is hoping to avoid, cases where something is read out of context.

        Even I trip up on “we” being used elsewhere sometimes, I often don’t know who “we” is until I look up the persons background to work out what group the person is involved with.

        This isn’t designed to outlaw the usage of ‘we’, just to clarify that it should be avoided unless it’s abundantly clear to someone who knows little or nothing about you as to who is included in that we.

      • Samuel Sidler 11:50 am on October 1, 2015 Permalink | Log in to Reply

        What Dion said. 🙂

        I think there are situations when it will make sense to say “we” but it should always be preceded or followed by the group speaking. For example, “we, the Customize component maintainers, discussed…” If you’re referencing a meeting you can avoid “we” altogether with something like “those of us in attendance” and list those who were in attendance at the beginning or end of the post.

    • bobbingwide 9:21 am on October 1, 2015 Permalink | Log in to Reply

      Re: It is strongly encouraged … to proofread.
      Suggest correcting the spelling of Guidelines in the subject.

    • Ryan Boren 2:44 pm on October 2, 2015 Permalink | Log in to Reply

      Most feature plugin merge proposals have these tags. Some of the new posts do not have them.


      Merge proposals could use their own checklist that includes things like a detailed call for testing targeted at beta testing audiences.

  • Aaron Jorbin 9:01 pm on September 25, 2015 Permalink
    Tags: , ,   

    Changes to fields output by comment_form in WordPress 4.4 

    A change in WordPress that just landed in trunk is to move the comment textarea to the top for logged-out users when replying. This is done largely with the goal to improve keyboard/focus navigation, but also aims to make it easier for end users to leave comments on WordPress sites. The change necessitated some filters and actions now being run in a different order. It also means that the HTML output by comment_form will now be different.

    This is what the comment form looked like before

    This is what the comment form looked like before

    This is what the comment form looks like after.

    If you use any of the hooks inside comment_form, but especially comment_form_field_comment and comment_form_after_fields, you are highly encouraged to test your code against the current WordPress nightly and report any issues on ticket #29974 so that any necessary adjustments can be made. Visual records and example code will help ensure everyone is satisfied with the final result.

    • Misplon 9:13 pm on September 25, 2015 Permalink | Log in to Reply

      Thanks for the heads up. Appreciate it.

    • S. Panda 11:43 pm on September 25, 2015 Permalink | Log in to Reply

      Excellent! It’s the little things like this which have such a big impact on ease of use.

    • simonrcodrington 1:04 am on September 26, 2015 Permalink | Log in to Reply

      Thanks for the heads up. I’m all for the comment box being at the top as that is where you naturally expect your comments will be the first thing you write 🙂

    • Piet Bos 2:30 am on September 26, 2015 Permalink | Log in to Reply

      Looks quite nice actually, it will probably be better from usability point of view as the commenter can “dive straight in”. I am running nightly builds over at WP TIPS and it all is looking great: http://wpti.ps/?p=601

    • Sami Keijonen 8:30 am on September 26, 2015 Permalink | Log in to Reply

      Looks weird at first but meaning behind this is big plus.

    • David Bennett 9:00 am on September 26, 2015 Permalink | Log in to Reply

      Has anyone gathered feedback on the psychology of the commenters?

      Without feedback from thousands of commenters and without A/B testing this proposa, itl seems to be based on a notion that could be wrong – namely that a commenter wants to comment first and then claim ownership of the comment.

      An equally valid psychological insight is that commenters want to claim ownership of what they are about to write. The current order of doing things might also be preferred because it gives commenters time to get into the zone for commenting.

      Unless you can A/B test this, If it ain’t broke, don’t fix it.

      • Aaron Jorbin 5:22 pm on September 28, 2015 Permalink | Log in to Reply

        As noted in the ticket, the current form is broken. This is a bugfix. So if it is broken, we should fix it. Clicking reply should take the user to the field they can leave their reply, however for non-logged in users, this means they can miss he other fields, especially if they are no vision users. If you have suggestions for alternative ways to fix this issue, please comment on the ticket.

    • Adam Pery 9:28 am on September 26, 2015 Permalink | Log in to Reply

      Looks much better then old one

    • Justin Tadlock 2:21 pm on September 26, 2015 Permalink | Log in to Reply

      I’m mostly in favor of this change for all the reasons mentioned. However, there are some things we should consider.

      1) The notification of a required name/email (if enabled) is now later in the flow. A potential commenter may write out a comment to only find out later that they can’t anonymously comment.

      2) It doesn’t necessarily address the problem of focusing on the wrong field when replying to a comment. Plugin/theme authors could still add a field earlier in the form via a hook. I’d like to see the JS focus on the first field in the form, regardless of what that field is.

      3) There should be a hook for plugin/theme authors to revert the position change of the comment field. I think this is going to be a welcome change. However, this will absolutely break some theme designs (I just happen to have one on hand). And, some people will simply want the old style back.

      • Aaron Jorbin 5:20 pm on September 28, 2015 Permalink | Log in to Reply

        1) Helen and I were noticing that this exposes some issues with required fields. It may necessitate some other changes there. Certainly open to ideas.

        2) In general, I would discourage plugins and themes from doing this, and perhaps encourage them to create their own reply link handler in those instances (and really think hard about WHY that field is more important than the content of the comment).

        3) I am generally opposed to hooks that have the explicit goal of creating bugs.

    • tweetpressfr 3:26 pm on September 27, 2015 Permalink | Log in to Reply

      Hi, thanks for the update. Is it open to discussion or it will be implemented whatever happens ? I guess it’s already running.

      I’m not in favor of this change. I don’t understand why it ‘s necessary or maybe it’s a cool feature but is it really urgent ? This will break a lot of design and not for a good reason such as security fix or bugfix.

      I mean… why backward compatibility there but not here ?

      Just my opinion, not sayin I’m the truth but I really don’t understand this one.

      • Aaron Jorbin 5:15 pm on September 28, 2015 Permalink | Log in to Reply

        Everything is open to discussion. If you have feedback, it’s best to leave it on ticket #29974.

        As noted in the ticket, the current form is broken. This is a bugfix that is currently targeted for WordPress 4.4. Clicking reply should take the user to the field they can leave their reply, however for non-logged in users, this means they can miss he other fields, especially if they are no vision users. If you have suggestions for alternative ways to fix this issue, please comment on the ticket. Additionally, if you have examples of how this breaks designs, please comment with those on the ticket (it’s best to include some sort of visual record along with example code and/or links).

    • PPNSteve 4:52 pm on September 28, 2015 Permalink | Log in to Reply

      Don’t fix what isn’t broken.

      That said, this goes against some 20+ years of what people see and expect in a form. its always name, contact info, options, txt (comment) field, conditional, submit. Even on paper forms this flow is the norm. not really liking this from a usability stand point. IMO it improves nothing. people already know how to do forms.

      • Aaron Jorbin 5:12 pm on September 28, 2015 Permalink | Log in to Reply

        If you have feedback, it’s best to leave it on ticket #29974. As noted in the ticket, it is broken. Clicking reply should take the user to the field they can leave their reply, however for non-logged in users, this means they can miss he other fields, especially if they are no vision users. If you have suggestions for alternative ways to fix this issue, please comment on the ticket.

      • Helen Hou-Sandi 5:57 pm on September 28, 2015 Permalink | Log in to Reply

        Do you have any data or sources for data on this? I did a fair amount of market research on non-native-WordPress comment form field ordering in order to help support making this kind of change, and an informal majority of them put the comment field first. This notably includes Jetpack comments, which are relatively common on WordPress sites.

    • dpowney 6:06 am on September 29, 2015 Permalink | Log in to Reply

      Why not provide a settings option for users to be able to position the comment form above or below the name, e-mail and website fields?

  • Aaron Jorbin 5:08 pm on September 18, 2015 Permalink
    Tags: , breaking-change, , my-hacks.php   

    my-hacks.php no longer supported 

    A long time ago in a WordPress far, far away sites were customized via the use of a my-hacks.php file. Then 2005 came along and brought with it a new developer feature: Plugins and Themes. For the last ten years, there has been an option to continue using my-hacks.php. Following the WordPress philosophy Decisions, not Options, as of today, WordPress trunk no longer supports the use of a my-hacks.php file. The option has long been removed from the admin and now the file will not be loaded.  This is a breaking change for sites that still use a my-hacks.php file.

    If you are using my-hacks.php, now is a great time to convert that code into a proper plugin. For the last number of years, the file has been loaded just like any other plugin. To change your my-hacks.php file into a plugin you need to do three steps:

    1. Move the file from the root of your install into the plugins folder which defaults to wp-content/plugins
    2. Add the plugin file header comments to the file
    3. Activate your new plugin

    This change is associated with ticket #33741.

    • mrpritchett 5:13 pm on September 18, 2015 Permalink | Log in to Reply

      Well done, good sir!

    • Austin Passy 5:22 pm on September 18, 2015 Permalink | Log in to Reply

      This is great news! Also, didn’t even know about this. 😁

    • Gabriel Reguly 5:23 pm on September 18, 2015 Permalink | Log in to Reply

      What about creating a plugin that will look for my-hacks.php and then load it? 🙂

      Then it could email the site admin about this situation and prompt about doing the proper plugin.

      This way there will be no broken sites.

      Just my $0.02.


      • Aaron Jorbin 5:35 pm on September 18, 2015 Permalink | Log in to Reply

        If a developer wants to make that, they are welcome to. Though converting a my-hacks.php file to a plugin is so easy, it likely makes sense to just do that instead of installing a plugin to load my-hacks.php

        • Gabriel Reguly 5:40 pm on September 18, 2015 Permalink | Log in to Reply

          Sorry, but seems I was not clear.

          I was meaning having a bundled must-use plugin like ‘Hello Dolly’ that would do the trick for a little while.

          Then next version would not have the plugin anymore.

          Think of it more of a smoother transition path. 🙂

        • Gabriel Reguly 5:43 pm on September 18, 2015 Permalink | Log in to Reply

          I do agree that for a developer it would be very easy to convert my-hacks.php file to a plugin.

          But what about the ones who are not developers? And then unexpectedly find their sites broken?

          With that said, it is a shame that someone still relies on my-hacks.php 🙂

          • Ipstenu (Mika Epstein) 6:08 pm on September 18, 2015 Permalink | Log in to Reply

            Considering how someone would have had to install my-hacks in the first place, ( https://codex.wordpress.org/Hacking_WordPress ), the people who might have a problem are likely to be either technical or have had WordPress for a very, very, very, long time. The latter I’m slightly worried about, except that in 8 years, I’ve seen *one* question about this.

            • Gabriel Reguly 6:13 pm on September 18, 2015 Permalink

              Exactly, there could exist sites where people don’t even know that they have my-hacks.php so they don’t ever ask questions about it.

              But since Ipstenu is only sligthly worried, why should I worry? 😉

        • Gabriel Reguly 5:45 pm on September 18, 2015 Permalink | Log in to Reply

          I can code such plugin, even if it will need to be download after sites are broken.

          • Jesse Petersen 5:58 pm on September 18, 2015 Permalink | Log in to Reply

            My guess would be that if someone used this method, the site is so old, it’s been forgotten or that file was edited by a developer, not a user. The same skill set needed to create edits in that file is the same as the one to move it into a plugin, IMO. I can’t imagine the number of active sites running a 2005 version with that file in use is very many at all.

            Any data on that, Aaron?

        • Gabriel Reguly 6:02 pm on September 18, 2015 Permalink | Log in to Reply

          Oh dear, silly me.

          I was so focused on plugins and forgot that it could be a simple core change 🙂

          So instead of removing this now, simply add the ’email to admin’ code and let it get into next release.

          Then at 4.4 do remove ‘my-hacks.php’

          Now it seems a much neat solution, right?

          • FolioVision 3:27 pm on November 7, 2015 Permalink | Log in to Reply

            Gabriel that is a great approach. Pro-actively warn and smoothly transition. Let’s hope this idea gets some traction for future changes. Breaking people’s site on autoupdates is just not cool.

    • Scott Kingsley Clark 6:07 pm on September 18, 2015 Permalink | Log in to Reply

      Or you can move the file to wp-content/mu-plugins/my-hacks.php as a quick fix

      • Gabriel Reguly 6:15 pm on September 18, 2015 Permalink | Log in to Reply

        That is a clever solution.

        But I was worried about not breaking sites, until Ipstenu told that she is only sligthly worried.

    • Gabriel Reguly 6:41 pm on September 18, 2015 Permalink | Log in to Reply

    • Michael Beil 7:09 pm on September 18, 2015 Permalink | Log in to Reply


    • Frozzare 7:32 pm on September 18, 2015 Permalink | Log in to Reply


    • Brian Layman 8:39 pm on September 18, 2015 Permalink | Log in to Reply

      There was a time when I did a good bit of work in my-hacks.php. I still use Sunrise.php for one thing, but that still only works on multisite. If this were mu-plugins, removing it would be a very different story.

      My-Hacks.php almost made it 12 years. Here’s the introduction post:

    • Arnan de Gans 11:22 pm on September 18, 2015 Permalink | Log in to Reply

      A file with 10-12 year old code won’t work on modern PHP anyway… So a rewrite is probably in order 🙂

    • Alex Mills (Viper007Bond) 1:01 am on September 19, 2015 Permalink | Log in to Reply

      Makes sense to see it go but this brings back a flood of memories. I learned PHP by editing my my-hacks.php file way, way back in the day!

    • bobbingwide 10:19 am on September 19, 2015 Permalink | Log in to Reply

      As the instigator of this change I’d just like to point out that I’ve updated the TRAC with my latest opinion


      With regards to the alternative options for those people who have been using my-hacks.php, and ignoring the deprecated notice on every page load,

      I’d suggest that
      a normal plugin is preferable to
      an MU-plugin which is preferable to
      db.php, or any of the other drop-in plugins.


    • Nilambar Sharma 10:49 am on September 22, 2015 Permalink | Log in to Reply

      Did not know there was something like `my-hacks.php`. Feeling newbie in WordPress 😀

    • Mike Little 7:50 am on September 24, 2015 Permalink | Log in to Reply

      So, I searched on my server… and found one! On my I own blog, of course.
      It only contains a couple of functions that used to be called from an old theme. So, I’m good to go 🙂

      However, I agree with the idea of detecting the file and notifying in one release, before removing support in the next. The notification should include a link to a decent codex page specifically for this one issue.

  • Aaron Jorbin 4:04 am on September 10, 2015 Permalink

    WordPress and PHP7 

    For the last few months, WordPress Core has been getting ready for the upcoming release of PHP7. PHP7 is bringing a host of improvements to PHP. One of the most notably is substantial performance improvements.Benchmarks of WordPress using PHP7 are showing a 2-3x speed improvement compared to PHP5.6.

    The first step towards support for PHP7 was to add PHP7 nightlies to the automated test matrix. For six months, WordPress has been testing every commit against PHP7. This helped us uncover a couple of now fixed issues.

    For example, PHP7 deprecates PHP4 style constructors. Therefore, WordPress Core removed them and also added a deprecation notice to all themes and plugins using them to extend core classes. This is done to help ensure that as many themes and plugins as possible are ready for PHP7.

    Next, WordPress Core fixed a small number of issues related to the Uniform Variable Syntax changes in PHP7.  Plugin and Theme authors are strongly encouraged to familiarize themselves with this change and all other backwards incompatible changes.

    PHP7 is currently targeted for release on November 12, 2015. Coincidentally, this is also the date that WordPress intends to officially fully support PHP7. 😃 While WordPress doesn’t officially support unreleased versions of PHP, you are encouraged to test and report any issues you find with PHP7 before the its official release.  PHP7 builds are available for Ubuntu 14.04 and CentOS 7 (and compatible distros) from php7.zend.com.

    Even as WordPress Core continues to expand its support for new versions of PHP, we have no intention of abandoning support for older versions until usage numbers show that the impact on users will be minimal. WordPress will continue to work with hosting providers to encourage them to upgrade their users to a current version of PHP and, when it’s reasonable, we will consider raising our minimum requirements. Regardless, WordPress continues to encourage all users to run the latest and greatest versions of PHP, including PHP7 upon its release.

    • Knut Sparhell 4:26 am on September 10, 2015 Permalink | Log in to Reply

      “WordPress will continue to work with hosting providers to encourage them to upgrade their users to a current version of PHP”

      Is that strategy a success?

      Another strategy, like setting a date for a bump, may increase the speed of sites upgrading. The reason it’s slow is because of the current strategy. WordPress is i king that acts like a peasant in this game.

      • Gary Pendergast 4:44 am on September 10, 2015 Permalink | Log in to Reply

        Is that strategy a success?

        So far, yes. We’re seeing ~1m sites upgrade per quarter from PHP 5.2 and 5.3 to later versions.

        Another strategy, like setting a date for a bump, may increase the speed of sites upgrading.

        This is unlikely to have much, if any, effect. We tried the same when upgrading from PHP 4 to PHP 5.2, and there were still far too many sites un-upgraded when we reached the deadline. (At the time, WordPress was ~15% of the internet – not as big as today, but still the biggest CMS by far.)

        If we do the same, and the numbers still aren’t low enough when the deadline arrives, our options are to bump the deadline (making the deadline meaningless), or to stick with it, and cause pain for millions of WordPress users. For me, at least, the latter is a totally unacceptable option.

        WordPress is i king that acts like a peasant in this game.

        The progress we’re seeing is through relationships we’ve cultivated with hosts, it hasn’t been made by throwing our weight around. I agree that hosts should be upgrading as soon as possible, but there’s no evidence to suggest that setting arbitrary deadlines will make it happen any sooner.

      • Aaron Jorbin 4:49 am on September 10, 2015 Permalink | Log in to Reply

        One thing everyone can do to help move these numbers is to talk to your local user group about why they need to care about the PHP version they run. Show them how they can upgrade, show them benchmarks of PHP 7 vs. earlier versions (especially vs 5.2).

        • Gary Pendergast 5:08 am on September 10, 2015 Permalink | Log in to Reply

          Amen to that.

          The PHP 7 benchmarks consistently show massive performance improvements. Twice as many simultaneous connections handled, 30%+ reduction in page load times.

          With the research showing that slower page loading times increases page abandonment rate, you have a pretty simple and convincing argument for getting folks to upgrade: Not Upgrading Is Costing You Money.

          In the same way that WordPress has become so popular, the effort to get people to upgrade won’t be won by decree. It’ll be won by folks like you and I, like everyone who reads the make/core blogs, telling their friends and family to make sure they’ve upgraded.

        • rahul286 1:52 pm on September 10, 2015 Permalink | Log in to Reply

          What about WordPress dashboard shows warning. Just warning. Like “Hey you are using old PHP version which is bad karma… WordPress will still work, but it can work better with new WordPress”. [read more | dismiss]

          “read more” will link to a page on wordpress.org where among other things we can show list of hosting companies who are running latest php version. 😉

          • Aaron Jorbin 3:33 pm on September 10, 2015 Permalink | Log in to Reply

            Most users don’t know what PHP is, let alone what version of PHP they are running or how they can update to a new version. A notice does little to help.

            • Samuel Wood (Otto) 12:10 am on September 11, 2015 Permalink

              A notice by itself is massively pointless to show the end user, who likely neither knows nor cares how their hosting service runs.

              However, it might be worth considering trying to detect the host in question, and providing valuable information for that specific host, such as links and other methods the end user can do to update themselves. Many hosts have a choice, somewhere, and if we know that, we can provide guidance.

          • Rafael Ehlers 6:30 pm on September 10, 2015 Permalink | Log in to Reply

            We are starting to do that with MailPoet, to prepare our users for the upcoming version: https://support.mailpoet.com/knowledgebase/how-to-prepare-my-site-for-mailpoet-3-0/ and yes, we are using a notice inside our admin pages.

    • slickremix 5:26 am on September 10, 2015 Permalink | Log in to Reply

      Nice! This is awesome! PHP 7 is going to be awesome! Hopefully hosting providers along with theme and plugin developers will go along with it and start encouraging people to make sure they are running the newest version for speed, security and reliability! Looks like we’ll be having to start testing our plugins for the newest version! WordPress should add this on the plugin and theme description pages. Show what version of PHP they have been tested up to.

      • Aaron Jorbin 6:10 am on September 10, 2015 Permalink | Log in to Reply

        Please do test your themes and plugins. The more testing that takes place, the more happy users when they upgrade.

        • rahul286 1:53 pm on September 10, 2015 Permalink | Log in to Reply

          Is there any way or automated test? Many times when there are changes like this, wordpress.org sends email to plugin authors which might have compatibility issues.

    • Ahmad Awais 6:05 am on September 10, 2015 Permalink | Log in to Reply

      Cool stuff. Tested WP base install on PHP7 Ubuntu 14.04 so far so good.

    • wiesson 7:09 am on September 10, 2015 Permalink | Log in to Reply

      Where can I report “front-end” bugs? I’m having some issues with php7 RC1 and the wordpress backend.

    • Marko Heijnen 8:55 am on September 10, 2015 Permalink | Log in to Reply

      “WordPress will continue to work with hosting providers to encourage them to upgrade their users to a current version of PHP”

      Can we finally have some proof on this? I have worked at one of the bigger host and I never saw someone from WordPress core contacting us.

      • Rafael Ehlers 6:33 pm on September 10, 2015 Permalink | Log in to Reply

        ^ this!

      • Samuel Sidler 6:55 pm on September 10, 2015 Permalink | Log in to Reply

        I can’t speak to whether/when conversations occurred with “one of the bigger host[s]” that you worked at, but I can assure you that conversations are happening.

        Outside of the ~1 million sites upgraded per quarter that @pento mentioned above and the clear decline of PHP 5.2 usage on the stats page, what kind of “proof” are you looking for?

        • Marko Heijnen 7:22 pm on September 13, 2015 Permalink | Log in to Reply

          @samuelsidler: That doesn’t prove anything. That shows users and hosts are working on it. It doesn’t show that WordPress does something about it. Like I moved around 100-150k sites last year from PHP 5.2 to 5.5 which is something the host did.

          I worked at the biggest host in Europe. You would expect WordPress to talk with them. Also I never heard from my connections that WordPress was contacted them. Obviously it doesn’t mean it doesn’t happen but the changes are high it didn’t.

          So again, where is the proof?

          • Samuel Sidler 7:26 pm on September 13, 2015 Permalink | Log in to Reply

            @markoheijnen: As a representative of WordPress (component maintainer), I think it’s great that you worked for “the biggest host in Europe” and helped them migrate sites off of PHP 5.2. You are part of WordPress and you acted in the best interests of the project (and the host) to migrate sites. That’s the system working.

            I’d like to ask again: what kind of “proof” are you looking for?

            • Marko Heijnen 7:47 pm on September 13, 2015 Permalink

              I acted not in the name of WordPress but in the name of the host and their customers. Yes, I’m a part of WordPress but that doesn’t mean that all my actions can be linked to it.

              The proof I’m looking is that core members (Project Leaders/committers) are talking with hosts. As in what does it mean you are working with hosts? Just sending them a message that x users are still running PHP 5.2? are is WordPress in a more pro active role?

              One thing core could/should do is see which plugins will break when hosts move to PHP 5.5. We could build a mechanisme that would check the current version of the plugin on the versions. If we then work together with plugin authors in fixing things that would break, that would help hosts to migrate users easier. I have ideas how to do this which do involve rebuilding lot’s of WordPress infrastructure. Instead of bash scripts/cronjobs building up microservices. If wanted I can work things out before the community summit.

            • Samuel Sidler 5:15 pm on September 14, 2015 Permalink

              The proof I’m looking is that core members (Project Leaders/committers) are talking with hosts.

              @markoheijnen: Committers and project leads have stated that they are talking with hosts. It sounds like you don’t believe that and want further evidence. Is there specific evidence that will assuage you? Or does it just boil down to not trusting the statements of committers and project leads?

              That said, why are committers and project leads the only group who can communicate with others? Any member of the community can help – like you did at “the biggest host in Europe” – by contacting hosts or, if they work at a host, migrating to more-recent versions of PHP.

              If you’d like to build a tool that makes testing plugins easier, I am sure hosts and users alike would find it useful.

            • Marko Heijnen 5:31 pm on September 14, 2015 Permalink

              @samuelsidler: Yes, it comes down that I don’t trust the statement. It doesn’t match with the things I hear around me and from the talks last year at the community summit. And till now you didn’t came with any proof at all.

              I do find it interesting that in this case I’m part of the community but when it comes on working on making WordPress or translate.wordpress.org better, then you and the core team does everything to avoid me and to make me look bad.

            • Aaron Jorbin 6:10 pm on September 14, 2015 Permalink

              @samuelsidler @markoheijnen: This is straying fairly far from the topic of the post (The announcement of WordPress’s support for PHP7). The best place to discuss strategies to update the minimum supported version of PHP is in ticket #33381

      • keithpickett 1:05 pm on September 11, 2015 Permalink | Log in to Reply

        They can encourage them all they want. It’s just not going to happen IMHO. That’s mostly because hosting providers have to support other PHP apps/platforms like Joomla, Drupal, not to mention the countless EComm apps out there. The PHP version support is all over the place. As for developing in WP, it’s a nightmare. I work with Vagrant VVV locally and write plugins using some PHP libs (from Composer). VVV uses the latest PHP version, so the apps behave as expected. However, when I deploy on a hosting platform like Scala, for example, my app dies because they only support 5.3. I’m just trying not to pull all of my hair out.

        • Jon (Kenshino) 7:00 am on September 13, 2015 Permalink | Log in to Reply

          The more decent hosts have long realised that they need to have backwards compatibility and yet support the newer PHP versions.

          Good shared hosts nowadays allow users to select their PHP versions via cPanel.

          You can always educate your clients to

          1. Change hosts (I see it as my civic duty to get people to stop paying for bad hosts)
          2. Ask the host (or help them ask) to move their accounts to a higher PHP version server.
          3. Use the cPanel PHP version selector if available.


        • Marko Heijnen 7:27 pm on September 13, 2015 Permalink | Log in to Reply

          I get what you are saying. I have spoken out more that it isn’t only about WordPress, hosts and the users but also talking with other projects. Personally I would like to setup a task force to help out on a more pro active way to decrease the usage of old PHP versions.

    • Zach Tirrell 12:46 pm on September 10, 2015 Permalink | Log in to Reply

      We know from the stats that are shared that ~12% of those running WordPress are on PHP 5.2, but I think this is not the metric that matters. What is more telling is the percentage of those running the latest version of WordPress are running PHP 5.2. Could that number be shared, so maybe we could all appreciate the challenge better?

      Also, what is the metric we are shooting for to decide to drop PHP 5.2? Is it based on the number requested above? Is it raw percentage? Is it total number of users? Are we expecting to see that get to zero?

      Considering that there continues to be security patches for older version of WordPress, why can’t hosting providers who stick with on older version of PHP also stick with the current version of WordPress?

      Given that support for PHP 5.2 has been dropped by PHP, more details on the future roadmap of WordPress on this topic is essential to developers being comfortable with this ecosystem.

      • J.D. Grimes 12:55 pm on September 10, 2015 Permalink | Log in to Reply

        That is why #33381 was opened. But it hasn’t been addressed yet, unfortunately.

      • Aaron Jorbin 3:36 pm on September 10, 2015 Permalink | Log in to Reply

        I don’t have a specific number in mind, but I know I won’t be encouraging a move until it is in the low single digit percentages. I don’t know what other people have in mind.

        The numbers are fairly consistent across all versions of WordPress.

      • Omega Supreme 11:32 pm on October 14, 2015 Permalink | Log in to Reply

        Interesting discussion…and I’m going to have to add a profile pic soon.

        My thoughts to your statement….it’s not so much the 5.2 issue, but users who haven’t updated WordPress in years. I’ve seen cases where once it was installed, that was it….5 years ago. So any changes to php will for sure break the site.

        Also in terms of dropping 5.2…I’ve come across other scripts where the designers just seem to want to stick with 5.2 or 5.3. Can’t tell you why since both of those are off the radar…but even suggesting 5.3 offends them which is sad since 5.6 is close to retirement as well.

    • simonrcodrington 3:38 pm on September 10, 2015 Permalink | Log in to Reply

      Exciting times. Hopefully this will help move some of the hosting providers forward to more recent versions of PHP and we can finally get away from 5.2.

    • mulli.bahr 5:26 am on December 4, 2015 Permalink | Log in to Reply

      Is there a benchmark to show WP performance with the different PHP versions?

    • iamkingsleyf 4:04 pm on December 7, 2015 Permalink | Log in to Reply

      I would like to give this a try soon maybe next year with ubuntu 16

    • genesteinberg 2:51 pm on December 13, 2015 Permalink | Log in to Reply

      I tested PHP 7 on a Plesk server (where you can easily set different PHP versions for different domains). While performance on a test WordPress blog seemed snappier, when I tried to login to the Dashboard, I got a blank screen. ??? It’s back to PHP 5.6.x till I sort this out.


    • Kochi709 6:53 am on December 18, 2015 Permalink | Log in to Reply

      I would like to know which version of PHP required to run WordPress 4.4 safely and without any error at shared hosting.

      Also I would like to know which version of PHP is used to code WordPress 4.4.

      Would appreciate for your reply.


compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar