abitofmind

@vmarko — Thanks for looking into this!

But I ran a whole test series again: I can tell you that DOCUMENT_ROOT is where it is supposed to be through a php test file I created, see below! And that wp w3-total-cache fix_environment apache then fixes it wrongly! But I have to tell you: I run the plugin My Private Site on this staging domain, and that possibly causes issues with routing and accessing… ?

In the domain root folder for staging.example.com I created a new file document_root_echo.php with the contents:

<?php echo "Document Root: " . $_SERVER['DOCUMENT_ROOT']; ?>

It returns:

Document Root: /data/web/customer-id/html/apps/staging.example.com

At this time my .htaccess contains these lines (which I have manually fixed):

RewriteCond "%{DOCUMENT_ROOT}/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SLASH}%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" -f
    RewriteRule .* "/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SLASH}%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" [L]

I now copy .htaccess to .htaccess-BACKUP for later comparisons.

I again run:

wp w3-total-cache fix_environment apache
Success: Environment adjusted.

I inspect .htaccess and it shows despite DOCUMENT_ROOT being where it should be, w3tc nevertheless “fixes” the filepath wrongly:

RewriteCond "%{DOCUMENT_ROOT}/html/apps/staging.example.com/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SLASH}%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" -f
    RewriteRule .* "/html/apps/staging.example.com/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SLASH}%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" [L]

Thanks for giving a quick first response!

Looking forward to the results of your investigation!

Ok and ok. Beyond that (the open discussion part): What’s your take on it? Could this be useful in practise? Which use cases do you see? Which problems do you see? SEO-wise, usability-wise, staff-wise, 3rd plugins stability wise (hardcoded assumptions). Curious on your take.

By tendency:

Categories are few, well named, rarely changed. On some sites possibly under editorial control, not extend-able by every little contributor.

• ? So a good candidate to make an exception for and allow for a namespace overlap with pages.

Tags are created frequently and by every contributor, possible even redundant among themselves

• ? Not a good candidate to mix into the global namespace.

But there are also some neutral aspects:

• ?? Tag base does not serve as a URL component for blogposts, so one consequence less.
• ?? There could be scenarios where it is a primary goal that categories and tags are valid top level candidates. Be it SEO or also as a simple means for using tags as landing pages to topical clusters, etc. If that’s a primary goal, then the discipline needed to avoid name conflicts may be worth to achieve that primary goal.

But I did yet not see any concrete need. So at the moment very fuzzy/theoretical. Hence curious on your take!

• This reply was modified 9 months, 1 week ago by abitofmind.

@eedee : As written, it is still relevant for me, and I now plan to dedicate some time again into my WordPress website project. So any plans I should know off? Thanks for any reply!

@gutenbergslider and @eedee: Do you plan do fix that bug with the proposed improvement I laid out?

• This reply was modified 9 months, 2 weeks ago by abitofmind.

@gutenbergslider and @eedee — Any concrete plans meanwhile? As written I am available for further inquiries, feedback, etc.

• This reply was modified 9 months, 2 weeks ago by abitofmind.

You announced to ?look into it again“ then I confirmed ?that I‘m still very interested and also willing to collaborate/beta-test“ only to then hear nothing back from you.

I hope all is well on your side. And hope to read back or better get some first actionable changes. Thanks!

Did you get my post confirming that my interest is still there? I‘d appreciate a reaction, thanks.

This is still very relevant to me.

I’m also willing to beta test the changes/improvement.

Any news?

Also interested to read about any difficulties or uncertainties you may faced. Maybe we can figure something out together, beta-test, experiment, etc.

• This reply was modified 1 year, 3 months ago by abitofmind.

Any news?

Hi,

I have served you all research regarding site-wide LightBox plugins, and by what mechanism they include/exclude images for opening.

I prefer the mechanism “Link to media file” which the majority of site wide Lightbox plugins support, and which I assume would be quite trivial to implement for your plugin too: In the HTML output just wrap an <a href="/path/to/media.png"></a> element around the IMG or VIDEO element. I personally would like to use it with Lightbox with PhotoSwipe.

I would appreciate a reaction whether you plan to support this. Thank you!

To clarify a possible misunderstanding: My proposal does not force the user to set 2-3 breakpoints. It makes it possible, but does not enforce it at all.

• You can set Desktop to X. → All lower breakpoints inherit X.
• You can set Tablet to X. → Desktop has the default value. Everything below Tablet inherits X.
• You could set Desktop to X, and Tablet to Y. → Everything below Tablet inherits Y.
• New possibility: You could set Desktop to X, and Tablet to NULL. → Everything below Tablet inherits NULL.
• New possibility: You could set Desktop to X, Tablet to NULL, Mobile-Landscape to Z. → Mobile-Landscape inherits Z.

The only real change I ask for is the possibility to add an explicit NULL value to a single breakpoint. Which then gets passed down as long until there is another concrete value. Is this really not possible?

• On a media-query level I’m quite certain this is possible.
• Greenshift’s UI controls of course would need to introduce a visualization of a user assigned NULL or UNSET.
• But overall I think it is possible. If you would explain to me why this is not possible I sure accept that! But I still think there is a misunderstanding. That’s why I try and try again to explain my idea. Hope that you now get the idea. Or that you explain me the exact reason why this is not possible.

• This reply was modified 1 year, 3 months ago by abitofmind.

• Desktop: Concrete value X
• Tablet: NULL assigned by user. ← That’s my feature request.
• Mobile Landscape, Mobile Portrait: Inherit the value of the nearest higher breakpoint, so NULL. If Tablet would be value Y, then they would inherit Y.

Allowing the user to assign the Tablet breakpoint a “NULL” value is a critical change? That will break all other sites? I really don’t understand why. I still wait for the technical explanation.

Ok, when I use the core image block within a Greenshift container I will apply my custom CSS fix.

And I may also consider using an Greenshift image block within a Greenshift container. When I use the Image Processor: WP Responsive (srcset) I get the benefits of the core image block and then can use the extra features of Greenshift.

Another such benefit of using a dedicated Greenshift image block would be the possibility to offer extra controls when nested within a Greenshift container, as I proposed here: Greenshift Image block gets grid item UI controls when within CSS grid container.