Prior to [23512], the Toolbar was still displayed on wp-signup.php while logged-in because it was hooked to the `init` action. When `_wp_admin_bar_init()` was moved to instead fire on `template_redirect` for the front-end and `admin_init` on the back-end, the visibility was lost because `template_redirect` isn't fired on wp-signup.php due to `WP_USE_THEMES` not being defined.
In order to maintain expected display results, a default filter has been added to hook `_wp_admin_bar_init()` to the `before_signup_header` action. This approach has the added benefit of allowing `_wp_admin_bar_init()` to be fired prior to the `wp_head` action where `_admin_bar_bump_cb()` is called (or the callback defined when 'admin-bar' theme support is added).
Fixes#34418.
Built from https://develop.svn.wordpress.org/trunk@35423
git-svn-id: http://core.svn.wordpress.org/trunk@35387 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34561] instituted the policy of forcing pagination for comments. This strategy
was intended to avert problems when 'page_comments' is set to 0 - as it is by
default - and the number of comments on a given post rises into the hundreds or
thousands. By forcing pagination in all cases, we ensured that WordPress would
not time out by processing unwieldy numbers of comments on a given pageload.
The strategy proves problematic, however, because comment permalinks are
generated using the page of the comment. Forcing pagination for posts that
were not previously paginated would change the URL of all comments that do not
appear on the default comment page.
This changeset reintroduces the 'page_comments' setting and its corresponding
checkbox on Settings > Discussion. A number of tests, which were written after
[34561], are modified to work now that 'page_comments' will, once again, be
disabled by default.
See #8071.
Built from https://develop.svn.wordpress.org/trunk@35331
git-svn-id: http://core.svn.wordpress.org/trunk@35297 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Baby API was born at 2.8KLOC on October 8th at 2:30 UTC. API has lots
of growing to do, so wish it the best of luck.
Thanks to everyone who helped along the way:
Props rmccue, rachelbaker, danielbachhuber, joehoyle, drewapicture,
adamsilverstein, netweb, tlovett1, shelob9, kadamwhite, pento,
westonruter, nikv, tobych, redsweater, alecuf, pollyplummer, hurtige,
bpetty, oso96_2000, ericlewis, wonderboymusic, joshkadis, mordauk,
jdgrimes, johnbillion, jeremyfelt, thiago-negri, jdolan, pkevan,
iseulde, thenbrent, maxcutler, kwight, markoheijnen, phh, natewr,
jjeaton, shprink, mattheu, quasel, jmusal, codebykat, hubdotcom,
tapsboy, QWp6t, pushred, jaredcobb, justinsainton, japh, matrixik,
jorbin, frozzare, codfish, michael-arestad, kellbot, ironpaperweight,
simonlampen, alisspers, eliorivero, davidbhayes, JohnDittmar, dimadin,
traversal, cmmarslender, Toddses, kokarn, welcher, and ericpedia.
Fixes#33982.
Built from https://develop.svn.wordpress.org/trunk@34928
git-svn-id: http://core.svn.wordpress.org/trunk@34893 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For the past 6 years, WordPress has operated as an oEmbed consumer, allowing users to easily embed content from other sites. By adding oEmbed provider support, this allows any oEmbed consumer to embed posts from WordPress sites.
In addition to creating an oEmbed provider, WordPress' oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules), and provides a preview from within the post editor.
For security, embeds appear within a sandboxed iframe - the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.
Props swissspidy, pento, melchoyce, netweb, pfefferle, johnbillion, extendwings, davidbinda, danielbachhuber, SergeyBiryukov, afercia
Fixes#32522.
Built from https://develop.svn.wordpress.org/trunk@34903
git-svn-id: http://core.svn.wordpress.org/trunk@34868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
New functions in `media.php`:
* `wp_get_attachment_image_srcset_array()` - Returns an array of image candidate string data used to build a `srcset` value for an attachment given an `$attachement_id` and `$size`.
* `wp_get_attachment_image_srcset()` - Returns the `srcset` value for an attachment given an `$attachement_id` and `$size`.
* `wp_get_attachment_image_sizes()` - Returns the `sizes` value for an attachment given an `$attachement_id` and `$size` and optional arguments used to alter its output.
* `wp_make_content_images_responsive()` - A display filter for adding `srcset` and `sizes` to images embedded in content.
* `wp_img_add_srcset_and_sizes()` - A utility function used by `wp_make_content_images_responsive()` to add `srcset` and `sizes` to a single `<img>` element.
Modifies existing core functions:
* Modify `wp_get_attachment_image()` so the HTML returned for an image includes `srcset` and `sizes`.
* Modify `get_media_embedded_in_content()` (sup, 3.6 leftover) by adding `<img>` to the list of accepted tags that can be matched in content. This is used in `wp_make_content_images_responsive()` to find all of the images embedded in content before passing them off to `wp_img_add_srcset_and_sizes()`.
Tests:
* Add a new factory method to `WP_UnitTest_Factory_For_Attachment` named `create_upload_object()`
* Adds unit tests
* Updates unit tests
Props joemcgill, tevko, jaspermdegroot, mdmcginn, barryceelen, peterwilsoncc, fsylum, wonderboymusic, chriscoyier, benjaminpick, jrfnl, #12kingkool68, janhenckens, ryanmarkel, side777, ryelle, wturrell, micahmills, mattbagwell, coliff, DrewAPicture.
See #33641.
Built from https://develop.svn.wordpress.org/trunk@34855
git-svn-id: http://core.svn.wordpress.org/trunk@34820 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Lazy-loading logic is moved to a method on `WP_Query`. This makes it possible
for comment feeds to take advantage of metadata lazyloading, in addition to
comments loaded via `comments_template()`.
This new technique parallels the termmeta lazyloading technique introduced in
[34704].
Fixes#34047.
Built from https://develop.svn.wordpress.org/trunk@34711
git-svn-id: http://core.svn.wordpress.org/trunk@34675 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34529] introduced lazyloading for the metadata belonging to terms matching
posts in the main `WP_Query`. The current changeset improves this technique
in the following ways:
* Term meta lazyloading is now performed on the results of all `WP_Query` queries, not just the main query.
* Fewer global variable touches and greater encapsulation.
* The logic for looping through posts to identify terms is now only performed once per `WP_Query`.
Props dlh, boonebgorges.
See #34047.
Built from https://develop.svn.wordpress.org/trunk@34704
git-svn-id: http://core.svn.wordpress.org/trunk@34668 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the 'page_comments' toggle allowed users to disable comment
pagination. This toggle was only superficial, however. Even with
'page_comments' turned on, `comments_template()` loaded all of a post's
comments into memory, and passed them to `wp_list_comments()` and
`Walker_Comment`, the latter of which produced markup for only the
current page of comments. In other words, it was possible to enable
'page_comments', thereby showing only a subset of a post's comments on a given
page, but all comments continued to be loaded in the background. This technique
scaled poorly. Posts with hundreds or thousands of comments would load slowly,
or not at all, even when the 'comments_per_page' setting was set to a
reasonable number.
Recent changesets have addressed this problem through more efficient tree-
walking, better descendant caching, and more selective queries for top-level
post comments. The current changeset completes the project by addressing the
root issue: that loading a post causes all of its comments to be loaded too.
Here's the breakdown:
* Comment pagination is now forced. Setting 'page_comments' to false leads to evil things when you have many comments. If you want to avoid pagination, set 'comments_per_page' to something high.
* The 'page_comments' setting has been expunged from options-discussion.php, and from places in the codebase where it was referenced. For plugins relying on 'page_comments', we now force the value to `true` with a `pre_option` filter.
* `comments_template()` now queries for an appropriately small number of comments. Usually, this means the `comments_per_page` value.
* To preserve the current (odd) behavior for comment pagination links, some unholy hacks have been inserted into `comments_template()`. The ugliness is insulated in this function for backward compatibility and to minimize collateral damage. A side-effect is that, for certain settings of 'default_comments_page', up to 2x the value of `comments_per_page` might be fetched at a time.
* In support of these changes, a `$format` parameter has been added to `WP_Comment::get_children()`. This param allows you to request a flattened array of comment children, suitable for feeding into `Walker_Comment`.
* `WP_Query` loops are now informed about total available comment counts and comment pages by the `WP_Comment_Query` (`found_comments`, `max_num_pages`), instead of by `Walker_Comment`.
Aside from radical performance improvements in the case of a post with many
comments, this changeset fixes a bug that caused the first page of comments to
be partial (`found_comments` % `comments_per_page`), rather than the last, as
you'd expect.
Props boonebgorges, wonderboymusic.
Fixes#8071.
Built from https://develop.svn.wordpress.org/trunk@34561
git-svn-id: http://core.svn.wordpress.org/trunk@34525 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a new table to the database schema (`wp_termmeta`), and a set of
`*_term_meta()` API functions. `get_terms()` and `wp_get_object_terms()`
now also support 'meta_query' parameters, with syntax identical to other
uses of `WP_Meta_Query`.
When fetching terms via `get_terms()` or `wp_get_object_terms()`, metadata for
matched terms is preloaded into the cache by default. Disable this behavior
by setting the new `$update_term_meta_cache` paramater to `false`.
To maximize performance, within `WP_Query` loops, the termmeta cache is *not*
primed by default. Instead, we use a lazy-loading technique: metadata for all
terms belonging to posts in the loop is loaded into the cache the first time
that `get_term_meta()` is called within the loop.
Props boonebgorges, sirzooro.
See #10142.
Built from https://develop.svn.wordpress.org/trunk@34529
git-svn-id: http://core.svn.wordpress.org/trunk@34493 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[34268] introduced cache priming for commentmeta, enabled by default. To
ensure performance on single post pages - where commentmeta is most likely
to cause performance issues - we disable up-front cache-priming. Instead, we
prime commentmeta caches for all comments in the loop the first time
`get_comment_meta()` is called on the page.
Props bradt, dd32, wonderboymusic, boonebgorges.
Fixes#16894.
Built from https://develop.svn.wordpress.org/trunk@34270
git-svn-id: http://core.svn.wordpress.org/trunk@34234 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When a new user is created in various places throughout the interface,
notifications are sent to the site admin and the new user. Previously, these
notifications were fired through direct calls to `wp_new_user_notification()`,
making it difficult to stop or modify the messages.
This changeset introduces a number of new action hooks in place of direct calls
to `wp_new_user_notification()`, and hooks the new wrapper function
`wp_send_new_user_notifications()` to these hooks.
Props dshanske, thomaswm, boonebgorges.
Fixes#33587.
Built from https://develop.svn.wordpress.org/trunk@34251
git-svn-id: http://core.svn.wordpress.org/trunk@34215 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_password_change_notification()` is now called at the 'after_password_reset'
action, rather than being invoked directly from the `reset_password()` function.
In order to make it possible to call `wp_password_change_notification()` as a
`do_action()` callback, the function signature has to be changed so that the
`$user` parameter is expected to be a value rather than a reference. Since
PHP 5.0, objects are passed by reference, so `&$user` was unnecessary anyway.
Props dshanske, thomaswm.
See #33587.
Built from https://develop.svn.wordpress.org/trunk@34107
git-svn-id: http://core.svn.wordpress.org/trunk@34075 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[32814] introduced a routine to split shared terms, which was run during the
regular WP database upgrade. This turned out to be problematic because plugins
are not loaded during the db upgrade (due to `WP_INSTALLING`), with the result
that plugins were not able to hook into the 'split_shared_term' action during
the bulk split. We work around this limitation by moving the term splitting
routine to a separate process, triggered by a wp-cron hook.
Props boonebgorges, Chouby, peterwilsoncc, pento, dd32.
Fixes#30261.
Built from https://develop.svn.wordpress.org/trunk@33615
git-svn-id: http://core.svn.wordpress.org/trunk@33582 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The pre-3.4 theme previewer doesn't work when using a static front page.
We kept the old theme preview for no-JS and some browsers that were less capable. But since browsers are doing a better job today we don't need to continue fixing/shipping this legacy code. Bye!
fixes#33178.
Built from https://develop.svn.wordpress.org/trunk@33492
git-svn-id: http://core.svn.wordpress.org/trunk@33459 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This v1 marries Jetpack's Site Icon module with the Media Modal, reusing code
from the Custom Header admin. For now, the core-provided icons will be limited
to a favicon, an iOS app icon, and a Windows tile icon, leaving `.ico` support
and additional icons to plugins to add.
Props obenland, tyxla, flixos90, jancbeck, markjaquith, scruffian.
See #16434.
Built from https://develop.svn.wordpress.org/trunk@32994
git-svn-id: http://core.svn.wordpress.org/trunk@32965 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Replace `wp_htmledit_pre()` and `wp_richedit_pre()` with `format_for_editor()`.
- Replace the `'htmledit_pre'` and `'richedit_pre'` filters with `'format_for_editor'`.
- Do not run the post content through `wpautop()` in PHP when the visual editor is default. Run the textarea content through the JS wpautop on initializing TinyMCE.
- Simplify both editors initialization.
- Improve setting of `wpActiveEditor` in Quicktags.
- Improve editor.js, use `tinymce.$` when possible.
See #32425.
Built from https://develop.svn.wordpress.org/trunk@32899
git-svn-id: http://core.svn.wordpress.org/trunk@32870 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Stop trying to remove `<title>` and `<category>` meta tags. They have not been used for many many years.
- Replacement of `<br>` with `<br />` and `<hr>` with `<hr />` is not needed for HTML 5.0. Also, these tags are formatted like that by the visual editor.
- Replace invalid HTML entities that might be pasted in the Text editor on save instead of on display.
Fixes#32335.
Built from https://develop.svn.wordpress.org/trunk@32896
git-svn-id: http://core.svn.wordpress.org/trunk@32867 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* DOMDocument was removed in [31752] but not the check.
* wp_staticize_emoji() has never accepted a second arg; remove it from calls.
* Remove wp_staticize_emoji_for_feeds(), no need for it.
* Remove _ and @ignore from wp_staticize_emoji_for_email(), no need for it.
see #31242.
Built from https://develop.svn.wordpress.org/trunk@32161
git-svn-id: http://core.svn.wordpress.org/trunk@32136 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Add the styling for the replacement images to the admin CSS.
- Revert to using `.emoji` as replacement image class.
- When pasting in the editor, convert emoji images to our format so we can replace them with chars on saving.
- Some more clean up of both the plugin and wp-emoji.js.
See #31242.
Built from https://develop.svn.wordpress.org/trunk@31786
git-svn-id: http://core.svn.wordpress.org/trunk@31766 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replace exisiting smilies with equivalent emoji, or with shiny new smiley images where no emoji existed.
Props batmoo, joen and mkaz for the original plugin upon which this is based.
Props pento, iseulde, kraftbj and peterwilsoncc for making the internet's dreams come true.
See #31242
Built from https://develop.svn.wordpress.org/trunk@31733
git-svn-id: http://core.svn.wordpress.org/trunk@31714 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When updating an existing taxonomy term that shares its `term_id` with
another term, we generate a new row in `wp_terms` and associate the updated
term_taxonomy_id with the new term. This separates the terms, such that
updating the name of one term does not change the name of any others.
In cases where a plugin or theme stores term IDs in the database, term splitting
can cause backward compatibility issues. The current changeset introduces
two utilities to aid developers with the transition. The `'split_shared_term'`
action fires when the split takes place, and should be used to catch changes in
term_id. In cases where `'split_shared_term'` cannot be used, the
`wp_get_split_term()` function gives developers access to data about terms
that have previously been split. Documentation for these functions, with
examples, can be found in the Plugin Developer Handbook. WordPress itself
stores term IDs in this way in two places; `_wp_check_split_default_terms()`
and `_wp_check_split_terms_in_menus()` are hooked to `'split_shared_term'` to
perform the necessary cleanup.
See [30241] for a previous attempt at the split. It was reverted in [30585]
for 4.1.0.
Props boonebgorges, mboynes.
See #5809.
Built from https://develop.svn.wordpress.org/trunk@31418
git-svn-id: http://core.svn.wordpress.org/trunk@31399 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a revert of [30494], [30492], [30347], and [30334]. The latter
changeset was a revert of [30336], which was a revert of [30241].
Watch for Term Splitting, Version III in version 4.2, coming soon to a
WordPress trunk near you.
See #30335, #5809.
Built from https://develop.svn.wordpress.org/trunk@30585
git-svn-id: http://core.svn.wordpress.org/trunk@30575 1a063a9b-81f0-0310-95a4-ce76da25c4cd
