Make taxonomy sitemaps adhere to pagination too #3
Labels
Milestone
Comments
ghost
assigned 
|
Altered the description and title of the original issue to reflect what needs doing ;) |
|
My latest commit has pagination for taxonomy sitemaps, but how should last modified timestamp on the root sitemap_index.xml work for this? My current implementation works as follow: Lets say the taxonomy is post_tags and you have 100 terms. Pagination limit is set to 25, so you'll have 25 terms per sitemap. For post_tag-sitemap1.xml, I query all post types that is associated with the first 25 terms, grab the one with the highest post_modified_gmt and use that for the last modified timestamp. post_tag-sitemap2.xml will be the second set of 25 terms and so forth. Under this implementation there's no particular order between post_tag-sitemap1.xml, post_tag-sitemap2.xml, post_tag-sitemap3.xml, etc which may screw up the expected sitemap format. Thoughts? |
|
That looks fine to me... Given it a test run and not really seeing weird things. |
seripap
pushed a commit
to seripap/wordpress-seo
that referenced
this issue
Nov 19, 2015
Stories/dt/keyword density
2 tasks
2 tasks
This was referenced Oct 28, 2017
2 tasks
Closed
2 tasks
2 tasks
jrfnl
added a commit
that referenced
this issue
Nov 30, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
jrfnl
added a commit
that referenced
this issue
Nov 30, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
jrfnl
added a commit
that referenced
this issue
Nov 30, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
jrfnl
added a commit
that referenced
this issue
Nov 30, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
9 tasks
jrfnl
added a commit
that referenced
this issue
Dec 6, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
jrfnl
added a commit
that referenced
this issue
Dec 9, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
jrfnl
added a commit
that referenced
this issue
Dec 16, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless as it wouldn't make a difference to the output, when the input is not a text string, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. - Stringable objects would previously be handled and this is now no longer supported. If this is undesirable, the logic can be changed, of course. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php ----------- Notes: As usual, several solutions to this issue were possible: fixing the tests, fixing the call to these functions etc. As these are such basic input sanitization functions though, it seemed sane to fix it in the `HTML_Helper` source though instead of littering code using these methods with input validation ahead of calling these functions.
jrfnl
added a commit
that referenced
this issue
Dec 16, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless, when the input is not a text string, as it wouldn't make a difference to the output, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * Stringable objects will be allowed through. * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (non-stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. Includes: * Adding tests safeguarding the support for stringable objects. * Adding a test fixture for a stringable object. For now, this test fixture is added into this code base. At a later point in time, I'd like to propose to add typical "type test" fixture classes to WP Test Utils so these test utility classes are available to all projects. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php
jrfnl
added a commit
that referenced
this issue
Dec 16, 2021
As of PHP 8.1, passing `null` to not explicitly nullable scalar parameters for PHP native functions is deprecated. In the tests, a number of errors could be seen along the lines of: ``` preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated path/to/src/helpers/schema/html-helper.php:30 path/to/src/generators/schema/website.php:31 path/to/src/generators/schema-generator.php:128 path/to/src/generators/schema-generator.php:76 path/to/tests/unit/generators/schema-generator-test.php:283 ``` In this case, both methods in the `HTML_Helper` class expect a `string` as input, but it is not verified that they actually receive a `string` and the received parameter is blindly passed on to PHP native functions. As running `strip_tags()` or the various regexes used with `preg_replace()` is useless, when the input is not a text string, as it wouldn't make a difference to the output, we can short circuit both functions by doing a type check at the start and bowing out early if the received parameter is not a string. To maintain the "old" behaviour as much as possible: * Integers and floats will be cast to string and returned (same as before as running these through the PHP native functions would also result in the parameter being cast to string). * Stringable objects will be allowed through. * In all other cases, an empty string is returned. This is a minor change in behaviour in case `true` would have been passed, which would previously return `1`, but IMO, that behaviour was incorrect anyway. This is also a change for when an array or (non-stringable) object would have been passed: - Previously an array or non-stringable object would lead to a PHP warning/error, now it will just return an empty string. Includes: * Adding tests safeguarding the support for stringable objects. * Adding a test fixture for a stringable object. For now, this test fixture is added into this code base. At a later point in time, I'd like to propose to add typical "type test" fixture classes to WP Test Utils so these test utility classes are available to all projects. Refs: * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg * https://www.php.net/manual/en/function.preg-replace.php
This was referenced Jun 16, 2022
Closed
hansjovis
pushed a commit
that referenced
this issue
Nov 21, 2022
* Squashed 'website/docs/' changes from 09bfb57e4..82ab3eff5 82ab3eff5 Added initial landing docs page git-subtree-dir: website/docs git-subtree-split: 82ab3eff504d4ec281e2cde877a63e23322f1acb * Altered sidebar file * Squashed 'website/docs/' changes from 82ab3eff5..a909fe2ca a909fe2ca Renamed id of index file git-subtree-dir: website/docs git-subtree-split: a909fe2ca079c824e18e9b93b3e83f4aa2b3836b * Altered config to fix edit URL. Still requires some other changes in subtree configuration * Moved docusaurus outside website directory * Removed reference to old docs directory * Updated configuration to point to new docs directory and updated links
7 tasks
11 tasks
11 tasks
11 tasks
2 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If number of posts in XML sitemap is set to 50 or so, make it do that for taxonomy sitemaps too.
The text was updated successfully, but these errors were encountered: