moongear

I have not crossed that bridge, yet.

You will be the ONLY service provider that is offering that for WordPress. It is much talked about but nobody is doing it.

Good morning. So, I don’t think this is working quite right. I am going to create a fork and tinker around with it.

I pulled this today and it looks really good. So far it appears to be working as intended.

Thank you so much and I will update if anything changes.

When a unique CSS file is generated for each source URL then the refer column in that table works as expected.

However, in a hacky case it would not be difficult to derive the hashed file from the last 5 MD5 of the json_encoded SRC + ITEM_TIMESTAMP_PURGE_CSS combination then come at this from another direction. I would do add_action( 'wp', 'interrupt_all_frontend' ) when specific GET vars are present then return the necessary css source list on demand. This would, however, be a pain as it would require running these in advance then saving the results separately somewhere for easy access and constantly testing if option litespeed.optimize.timestamp_purge_css has changed.

A better solution would be if you update refer with subsequent source URLs.

Also, would be nice if there was a ON/OFF switch to generate css (or js) for each unique page. Then when ON you could add the uri value in $hash = md5( json_encode( $src ) . $purge_timestamp ) ; perhaps like $hash = md5( json_encode( $src ) . $uri . $purge_timestamp ) ;

Even better yet… more hooks in your software so people like me can better manipulate/add-to its behavior.

Edit: I saw your last post regarding the filter after I wrote this. Yes, a filter such as that would be helpful. In that situation, I would apply my methodology making the files unique for each URL.

• This reply was modified 4 years, 9 months ago by moongear.
• This reply was modified 4 years, 9 months ago by moongear.

FYI: I am using it with WP version 5.4.2 and it works just fine. I think it may need just the capability updated. Although to be thorough, I have not tested to see if I am getting any notices and such with debug turned on.

Thanks, but separate CCSS is not the goal. Seperate CSS is the goal. Additionally, in my instance I am not using CCSS as it is unreliable and bloated. I manually created the CCSS and am including it in the header.php.

Thank you for your response. I think perhaps you did not read my original post or you do not understand what I wrote. I fully and completely understand the concept of how the plugin works.

I want to see different files. My goal is to have a completely separate file generated for every unique URL.

I do not want them to be shared across multiple URL’s even IF those URL’s load the same CSS files.

I don’t care about the JS files because in my configuration I am not combining JS. I use JS HTTP/2 Push so combining them is a waste of resources.

I want seperate CSS files because I am using UNCSS to remove unused CSS from each of them after they are generated by the LS plugin. (I already wrote this above but here it goes…) I cannot rely on this process when the files are shared across multiple URL’s because not all pages, even though they load the same original CSS files, do not utilize all of the rules in the original CSS files. Therefore, if the CSS is stripped of unused CSS based on Page A, then Page B may be missing CSS rules.

Because of this, Page B/C/D/E/F/G and so on need their own generated CSS file so that UNCSS can strip unused CSS from it based on what rules are used in those particular pages.

In short, is there a way to FORCE the LS Cache plugin to generate a new combined CSS file for every unique URL?

The generated files vary from page to page but only a few files are generated over dozens of pages.

It does.

I second this. To me, this just makes sense.

Try:

function_exists('get_field') && get_field('director') == 'Some Desired Value'

Placing this in the visibility part within DIVI “should” work.

FYI: This plugin and support area is not for this purpose. And there are no built in options for doing this with DIVI.

The easiest method is to install a plugin called YOAST SEO. Then on each page you will find an SEO meta box in which you can choose setting then modify the NOINDEX value for that page/post.

After reading this, I checked and mine, too, is still including the tracking code.

I removed the add_action bit from content-visibility-for-divi-builder.php but this is frustrating as it will no doubt return when the next update becomes available.

Add a function to your child theme functions.php file. Edit the roles to suit your needs. It might look like this:

function user_role_can_see_this() {
    // Which Roles
    $which_roles = array(
        'author'.
        'editor'
    );
    $user = wp_get_current_user();
    return in_array( $which_roles, (array) $user->roles );
}

Once that is uploaded, add the function user_role_can_see_this() to the Visibility part of the section in DIVI that you want to be visible only to your chosen roles.

That should do it!

• This reply was modified 6 years ago by moongear.