Title: Mark (a11n)'s Replies | WordPress.org --- # Mark (a11n) [ ](https://wordpress.org/support/users/thingalon/) * [Profile](https://wordpress.org/support/users/thingalon/) * [Topics Started](https://wordpress.org/support/users/thingalon/topics/) * [Replies Created](https://wordpress.org/support/users/thingalon/replies/) * [Reviews Written](https://wordpress.org/support/users/thingalon/reviews/) * [Topics Replied To](https://wordpress.org/support/users/thingalon/replied-to/) * [Engagements](https://wordpress.org/support/users/thingalon/engagements/) * [Favorites](https://wordpress.org/support/users/thingalon/favorites/) Search replies: ## Forum Replies Created Viewing 15 replies - 1 through 15 (of 103 total) 1 [2](https://wordpress.org/support/users/thingalon/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/thingalon/replies/page/3/?output_format=md)… [5](https://wordpress.org/support/users/thingalon/replies/page/5/?output_format=md) [6](https://wordpress.org/support/users/thingalon/replies/page/6/?output_format=md) [7](https://wordpress.org/support/users/thingalon/replies/page/7/?output_format=md) [→](https://wordpress.org/support/users/thingalon/replies/page/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack Boost - Website Speed, Performance and Critical CSS] Failure to generate critical CSS (Part 2)](https://wordpress.org/support/topic/failure-to-generate-critical-css-part-2/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 4 months ago](https://wordpress.org/support/topic/failure-to-generate-critical-css-part-2/#post-17407973) * Hi [@malcolm12boxes](https://wordpress.org/support/users/malcolm12boxes/) * I’m one of the developers on the Boost team. I’ve taken a look at your site and I think I’ve figured out what is going on. It looks like your site has an HTTP header set which blocks your site from loading inside an iframe: * ```wp-block-code Content-Security-Policy: frame-ancestors 'none'; ``` * Our manual Critical CSS generator runs from your wp-admin page by creating a hidden iframe, and using it to load various pages on your site at various sizes to determine which CSS rules are needed to render the “above-the-fold” portion of your site quickly. * I’m afraid it can’t work with `frame-ancestors` set to `none`, as it prevents your site from loading inside any iframe. If you are willing to change your site settings, you could change this rule to: * ```wp-block-code Content-Security-Policy: frame-ancestors 'self' ``` * This would still disallow your site from being loaded inside an iframe from other sites but would allow it to load in iframes created on the same domain. That would let Boost load your site in an iframe to generate Critical CSS for you. * You can read more about the `frame-ancestors` settings here: [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) * Alternately, our automated Critical CSS generator (available when you upgrade Boost to a paid plan) does not use iframes to generate Critical CSS. Instead it loads your site inside a virtual browser on our servers to generate Critical CSS for you. That should work regardless of your `frame-ancestors `policy. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Cache when user log in.](https://wordpress.org/support/topic/cache-when-user-log-in/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 5 months ago](https://wordpress.org/support/topic/cache-when-user-log-in/#post-17330954) * Hi [@itsmeit](https://wordpress.org/support/users/itsmeit/) – thanks for your question. * When caching pages for logged in users, the user’s session cookies are used as a part of the cache key to ensure that two different logged in users don’t see each other’s version of the page. It prevents cache pollution across users. * As the session token is used in the cache key, logging out and in again resets this – so it is expected behaviour. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack - WP Security, Backup, Speed, & Growth] Sharing Buttons: Will Twitter be changed to X?](https://wordpress.org/support/topic/sharing-buttons-will-twitter-be-changed-to-x/) * [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 10 months ago](https://wordpress.org/support/topic/sharing-buttons-will-twitter-be-changed-to-x/#post-16979109) * Hi [@b-rad](https://wordpress.org/support/users/b-rad/) * The Twitter “X” logo was [announced as an interim logo](https://techcrunch.com/2023/07/24/twitter-has-officially-changed-its-logo-to-x/?guccounter=1&guce_referrer=aHR0cHM6Ly9naXRodWIuY29tL0F1dG9tYXR0aWMvamV0cGFjay9pc3N1ZXMvMzIxNzg&guce_referrer_sig=AQAAAEa56ezY60_wVMA_t5LGuHGOamvJx9nOBgllYYgbf8tnf-3gwtHPHu8okSYmY7svR3iHSIT_v6fycS9MbjRe4-7aEY8cr7LFLTuNUboc5503RJup5DCRJzBBGrqK6X9DAHDcK8ZlYH6oIr3Qo5cYOlWktxm-dE6J64f1b4lMqacQ), to be replaced with a more permanent logo in the near future. * As I understand it, the Jetpack team initially were waiting to see if a new permanent logo was going to be announced. You can follow the Jetpack team’s GitHub issue for updating the logo here: * [https://github.com/Automattic/jetpack/issues/32178](https://github.com/Automattic/jetpack/issues/32178) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack - WP Security, Backup, Speed, & Growth] Uncrawlable site due to line of code, remant?](https://wordpress.org/support/topic/uncrawlable-site-due-to-line-of-code-remant/) * [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 10 months ago](https://wordpress.org/support/topic/uncrawlable-site-due-to-line-of-code-remant/#post-16979076) * Hi [@pickfetishx351](https://wordpress.org/support/users/pickfetishx351/), * The link you included in your post is “uncrawlable” because it’s not a link to a different page on your site; it appears to be a download link on the Jetpack Carousel. * When Google crawls a site, it reads the HTML code for each page and uses it to find links to other pages on the same site. * Seeing an “uncrawlable link” doesn’t mean the process is broken; it just means that it found a link that doesn’t appear to lead to another page it can crawl. * Unfortunately, dealing with Google indexing can be an arcane art that I’m not fully qualified to assist with. I do note that their documentation for understanding an indexing report can be found over here: * [https://support.google.com/webmasters/answer/7440203](https://support.google.com/webmasters/answer/7440203) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Exclude from cache using URL Strings](https://wordpress.org/support/topic/exclude-from-cache-using-url-strings/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 10 months ago](https://wordpress.org/support/topic/exclude-from-cache-using-url-strings/#post-16972986) * It sounds like you’ve taken the right steps, but if those pages are still being cached then something isn’t quite right. * First, may I ask how you are checking if the pages are still cached? The easiest way is to load the pages in an incognito/private browser tab, right click on the page, and select “View Source”. At the bottom of the source code, you will find an HTML comment like the following if the page is cached: * ```wp-block-code ``` * Next, let’s double-check the paths. When you load your `contact` page, does it typically have a `/` at the end of the URL, or does that get removed? * If the `/` is not present at the end of the URL, then you should remove it from your Reject URLs settings. e.g.: just `/contact` instead of `/contact/`. * Finally, have you added each of the paths you want excluded on a line of their own in the rejected URL list? * Hopefully one of these checks will shake out what’s going wrong here. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack Boost - Website Speed, Performance and Critical CSS] Optimize Critical CSS Loading on landing with parameters](https://wordpress.org/support/topic/optimize-critical-css-loading-on-landing-with-parameters/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 10 months ago](https://wordpress.org/support/topic/optimize-critical-css-loading-on-landing-with-parameters/#post-16972905) * Hi [@sebastiengc](https://wordpress.org/support/users/sebastiengc/) * > The page at [https://ringtwice.be/nl](https://ringtwice.be/nl) is generated > by WordPress. However, the page [https://ringtwice.be/nl/](https://ringtwice.be/nl/) > is generated by a Rails application. * This is a slightly unusual setup. As `/nl/` redirects to `/nl`, would it make sense to just have `/nl/` served by WordPress in the first place? * However, if that’s not possible, you should be able to customize the URLS that Jetpack Boost uses when generating Critical CSS using the `jetpack_boost_critical_css_urls` filter. * If you are mixing Rails with WordPress, it sounds like you are an advanced user, and are likely comfortable with coding? Something like this might work with some testing and modification: * ```wp-block-code function custom_url_strip( $urls ) { return array_map( function( $url ) { return str_replace( '/nl/', '/nl', $url ); }, $urls ); } add_filter( 'jetpack_boost_critical_css_urls', 'custom_url_strip' ); ``` * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack - WP Security, Backup, Speed, & Growth] Pageview Stars Vanished](https://wordpress.org/support/topic/visitors-starts-vanished/) * [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 10 months ago](https://wordpress.org/support/topic/visitors-starts-vanished/#post-16969968) * Hi [@proptrading](https://wordpress.org/support/users/proptrading/), * Thanks for writing in with your question. * There is a known issue where LightSpeed Cache’s “Localize Resources” feature can impact Jetpack Stats. * In order to fix the issue, we recommend that you deactivate that feature in “ LightSpeed Cache > Page Optimization > Localization”. * I hope that fixes it. Let us know if you have further issues. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Version 1.10.0-alpha and Preload](https://wordpress.org/support/topic/version-1-10-0-alpha-and-preload/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 11 months ago](https://wordpress.org/support/topic/version-1-10-0-alpha-and-preload/#post-16958370) * Wow! I’m impressed at your dedication; pulling it out of GitHub trunk and installing it directly is a fiddly process to undertake. How do you keep it up-to-date as we update trunk? * If you’re eager to run the latest version of Super Cache, then we have a plugin for installing unreleased software that the Jetpack team works on; [Jetpack Beta](https://jetpack.com/download-jetpack-beta/). It lets you install pre-release versions of our software. But it does come with a warning that it is for test sites only. * I am keen to figure out what broke in your preloading. I understand that the problem has been plaguing you for a while now – but as we haven’t been able to replicate the issue ourselves, it’s impossible to be sure what’s causing it. * We’d be happy to review DEBUG logs from your site if you are able to send them to us via the Jetpack contact form: [https://jetpack.com/contact-support/?rel=support&hpi=1](https://jetpack.com/contact-support/?rel=support&hpi=1) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Version 1.10.0-alpha and Preload](https://wordpress.org/support/topic/version-1-10-0-alpha-and-preload/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [2 years, 11 months ago](https://wordpress.org/support/topic/version-1-10-0-alpha-and-preload/#post-16955413) * Hi Dimal! * I remember you were looking at your DEBUG logs a few months ago, and reported that you saw “ABSPATH” in your paths. Did you figure out where that came from, and if fixing your ABSPATH in wp-config would fix that issue? * Unfortunately, without a better understanding of how/where your preload is failing, we aren’t sure what problem to fix. We test Super Cache on sites with many posts, and aren’t seeing it stop after 20. * We’ve been iterating on the preload stuff a bit; making it work more reliably on hosts with tight limits. We’ll be releasing it in 1.10 soon once we work out a bug to do with gzip compression. But I see you’re already running 1.10-alpha now. * Where did you get it from? We don’t typically release an alpha build; that’s the version we use for the absolute latest in our repository. If you’re keeping up-to-date with our absolute latest from our repository, then installing 1.10 once it’s released won’t fix your preloading. * If you’d like us to check out what is going on with your preload, would you mind sending us your DEBUG log? * You’re welcome to post it here, but if you would like to send it to us privately, you can use the following contact form: * [https://jetpack.com/contact-support/?rel=support&hpi=1](https://jetpack.com/contact-support/?rel=support&hpi=1) * If you do, please include a link to this forum thread for context. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Some issues from WPSC debug](https://wordpress.org/support/topic/some-issues-from-wpsc-debug/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [3 years, 2 months ago](https://wordpress.org/support/topic/some-issues-from-wpsc-debug/#post-16700185) * Hi [@dimalifragis](https://wordpress.org/support/users/dimalifragis/), * > gc: could not delete ABSPATH/wp-content/cache/supercache/index.html as it’s > protected. * There are paths which Super Cache will never delete; these include the `index. html` files inside the `cache/` and `cache/supercache/` directory. I believe this message is safe to ignore. * > prune_super_cache: did not delete file as it wasn’t a directory or file and > not forced to delete new file: ABSPATH/wp-content/cache/supercache/index.html * Super Cache has an internal function called `prune_super_cache`, which is called after preloading is complete. (It’s called in other circumstances too – but I’ll focus on the one most relevant to the system you are debugging). * `prune_super_cache` deletes cached files which are too old, based on your cache settings. * We recently found an issue where `prune_super_cache` was deleting recently preloaded content if “Cache Timeout” was set to 0. We’ve [got a patch](https://github.com/Automattic/jetpack/pull/30052) coming soon to a Super Cache near you. * Anyway, this particular message will appear when Super Cache decides that a specific file is _not_ to be deleted because it’s too new (or it looks like it’s a directory). The wording “as it wasn’t a directory or file and not forced to” could be improved upon, but this one is safe to ignore. * > What all those mean? Is that “ABSPATH” an issue? * Yes, seeing `ABSPATH` in your file path _is_ a little strange, and could cause issues. `ABSPATH` is the name of a PHP constant which (usually) contains the path of your WordPress site’s files on the server they are running on. * It looks like `"ABSPATH"` has been used as a string value somewhere in your system, instead of being used as the name of a PHP / WordPress constant. * The above log messages (about `prune_super_cache`, etc) all come from parts of Super Cache which use its internal idea of where to cache your files. It bases those on `WP_CONTENT_DIR` — an internal WordPress constant describing where ` wp-content` lives. I suspect that your `WP_CONTENT_DIR` constant contains the string `"ABSPATH"`. This could potentially happen if your `wp-config.php` file contains overrides for your `wp-content` directory which are mis-applied. * Do you have any custom code in your `wp-config.php` or anywhere else in your site which may be setting the value of either `ABSPATH` or `WP_CONTENT_DIR`? * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] htaccess coordination with Wordfence plugin](https://wordpress.org/support/topic/htaccess-coordination-with-wordfence-plugin/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [3 years, 2 months ago](https://wordpress.org/support/topic/htaccess-coordination-with-wordfence-plugin/#post-16680158) * Great discussion, all – and thanks in particular to [@dimalifragis](https://wordpress.org/support/users/dimalifragis/) for suggesting simple mode as a way to let WordFence run first. * I just wanted to chime in with a few points to consider: * When WPSC is running in Expert mode, it configures your webserver to serve static HTML files directly from the cache without executing any WordPress PHP code. ( That’s why Wordfence doesn’t get a chance to run first). * I don’t think that’s necessarily a conflict. While WordFence may block some traffic to prevent attacks, serving static HTML at this stage means your site isn’t vulnerable to attack, as no dynamic content or PHP code is being executed. * If WordFence is blocking traffic from specific IP addresses to mitigate DDoS attacks, serving static HTML content for a page is likely even faster and lighter on server resources than running enough PHP code to filter the request. * That doesn’t solve the traffic reports issue, so if you rely on the traffic report from Wordfence, I’d recommend leaving WP Super Cache in simple mode as [@dimalifragis](https://wordpress.org/support/users/dimalifragis/) suggests. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Preload mode skips caching pages or deletes already cached pages](https://wordpress.org/support/topic/preload-mode-skips-caching-pages-or-deletes-already-cached-pages/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [3 years, 2 months ago](https://wordpress.org/support/topic/preload-mode-skips-caching-pages-or-deletes-already-cached-pages/#post-16647899) * Hi [@mjvito](https://wordpress.org/support/users/mjvito/), * I have some good news! I think I’ve tracked down the issue. It was your comment that started me down the right path: * > The other day, I took a one day break. After the break, I started a morning > preload with just posts and pages, and at the end of that cycle, the significant > deletion also occurred, even though it had been started manually.  * Following that rabbit-hole, I tested multiple setups with different timing and eventually stumbled upon the real reason for it. * At the end of preloading, Super Cache calls its `prune_super_cache` method to clean up the cache directory. However, if your cache expiry time is set to 0 ( which usually prevents calls to `prune_super_cache` in other situations), it deletes all files which are over 0 seconds old. * The timing is very sensitive to how quickly the preload process runs, and which files were preloaded first. If the preload takes less than a second, then often nothing will be deleted. However, if it takes longer than a second, then the older content preloaded will often be deleted at the end. * I’ve prepared a fix for this, which we will release in the next version of Super Cache. If you are interested in the development process, you can follow the patch here: [https://github.com/Automattic/jetpack/pull/30052](https://github.com/Automattic/jetpack/pull/30052) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Preload mode skips caching pages or deletes already cached pages](https://wordpress.org/support/topic/preload-mode-skips-caching-pages-or-deletes-already-cached-pages/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [3 years, 3 months ago](https://wordpress.org/support/topic/preload-mode-skips-caching-pages-or-deletes-already-cached-pages/#post-16613695) * Hi [@mjvito](https://wordpress.org/support/users/mjvito/), * Thanks for investigating and reporting the strange behaviour you’ve experienced. I’ve just tried to recreate both issues in my test sites, and have not been able to so far. * I’d be happy to check over any debug logs you have. Please be sure to redact your site url from the debug logs if you would like to keep it private. * > Preload mode creates the child categories first. Then when it creates the parent > category, it deletes the children * On my test site, I created categories `Brie` and `Cheddar`, both of which are children of `Cheese`. I ensured that `Brie` contained posts, but `Cheddar` did not. * I ran the preload process, and was able to observe: - A log message stating `wp_cron_preload_cache: delete /category/cheese/ brie` appeared in my logs, which was then followed by further log messages indicating files in the `brie` directory were fresh and so were not deleted. This occurs when Super Cache is considering deleting directories, and may not indicate that the indicated path is actually getting deleted. - The same logs appeared for `Cheddar`. - When I browsed to `Contents` > `Show file list` in the Super Cache settings page, I could see all three cheese related categories under the list of “Fresh WP-Cached files”. * You mention that you saw this deletion in your Debug logs. * If you view the contents of your cache after pre-loading, do all of your category pages appear there? Finally, if you browse to any category page which is missing from your cache does it load correctly, and does it appear in your cache contents after you load it manually? * > The significant bug is a behavior that occurs at the end of a preload refresh > cycle, but ONLY when preload is on a schedule. When preload is run manually(“ > Refresh preloaded cache files” set to 0 minutes), everything appears to function > as intended. The total cached pages indicated in the UI is close to what I > expect. It stays approximately at that level through subsequent manually started > preload cycles. However, when preload refresh is set to run on a schedule, > it deletes a large number of cached pages at the moment the cycle finishes. > This can be up to 50% of the pages. This happens both with “Preload tags, categories > and other taxonomies.” checked and unchecked. I observed this only through > the UI. * That does sound like a severe bug. * I have attempted to recreate this on my test site, but so far haven’t been able to. I would love to see Debug logs around this occurring. * When you click the “Preload now” button, it internally schedules a preload for 10 seconds in the future – using the same code as the scheduled preloads. * At the moment, the best working theory I have is that _another_ cron-job is running after your scheduled job, which is deleting the cache files. * In your original post, you mentioned that you set **Garbage Collection** to 0, but that it did not fix your original issue. Can I please verify that it’s still set to 0? * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Zlib Output Compression Enabled, but …](https://wordpress.org/support/topic/zlib-output-compression-enabled-but/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [3 years, 3 months ago](https://wordpress.org/support/topic/zlib-output-compression-enabled-but/#post-16580448) * Hi [@ericr23](https://wordpress.org/support/users/ericr23/) * Thanks for writing in. There isn’t a conflict, but WP Super Cache is warning you that your site is running inefficiently. * It is more efficient to turn off `zlib.output_compression` and turn on Super Cache’s “compress pages” feature, as Super Cache is able to compress the page content _once_ when caching it, instead of every time the page is served. * There is no option in Super Cache to turn off the warning, but it is safe to ignore if you don’t mind the performance trade-off. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Custom JavaScript is not allowed in amp](https://wordpress.org/support/topic/custom-javascript-is-not-allowed-in-amp/) * Plugin Contributor [Mark (a11n)](https://wordpress.org/support/users/thingalon/) * (@thingalon) * [3 years, 3 months ago](https://wordpress.org/support/topic/custom-javascript-is-not-allowed-in-amp/#post-16573437) * Hi [@occupygh](https://wordpress.org/support/users/occupygh/), * WP Super Cache does not add any custom JavaScript files to your site’s front- end. I can see two possible causes behind the issue you experienced: 1. Another plugin added a script to your amp pages, which Super Cache included in its cache. When you deactivated Super Cache, it fixed the problem because your site was no longer serving a cached “incorrect” AMP page, or 2. Your site was mixing up AMP pages with non-AMP pages, and serving the same content to both versions of the page. * Testing possibility 1 is very easy: Simply re-enable WP Super Cache, and click the “Delete Cache” button on the “Easy” tab in WP Super Cache to clear out your cache. If the problem persists after doing this, then we are probably dealing with the second possibility. * In order to fix the second possibility, can you please try checking the following settings: 1. Make sure that “**Tracking Parameters**” under “Advanced” does **not** include` amp`, 2. Add `amp` to the “**Rejected URL Strings**” setting under “Advanced” in a new line of its own. * Finally, can you please visit the `amp` version of your page in your browser when WP Super Cache is enabled, to check whether it looks the same as your main site, or if it looks like a simplified version. Viewing 15 replies - 1 through 15 (of 103 total) 1 [2](https://wordpress.org/support/users/thingalon/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/thingalon/replies/page/3/?output_format=md)… [5](https://wordpress.org/support/users/thingalon/replies/page/5/?output_format=md) [6](https://wordpress.org/support/users/thingalon/replies/page/6/?output_format=md) [7](https://wordpress.org/support/users/thingalon/replies/page/7/?output_format=md) [→](https://wordpress.org/support/users/thingalon/replies/page/2/?output_format=md)