true)); // Hide hardcoded irrelevant post types foreach (\WpAssetCleanUp\MetaBoxes::$noMetaBoxesForPostTypes as $noMetaBoxesForPostType) { unset($postTypesList[$noMetaBoxesForPostType]); } ?>
array())); ?>>

;

 
>

>
  • style="display: none;" class="wpacu-dom-get-type-info" id="wpacu-dom-get-type-direct-info"> -
  • style="display: none;" class="wpacu-dom-get-type-info" id="wpacu-dom-get-type-wp-remote-post-info"> WP Remote Post -


Sometimes, you might have a post type marked as 'public', but it's not queryable or doesn't have a public URL of its own, making the assets list irrelevant. Or, you have finished optimising pages for a particular post type and you wish to have the assets list hidden. You can choose to hide the meta boxes for these particular post types.

In order to view the options related to the CSS & JS manager meta box located within the edit post/page/taxonomy area, the above option needs to be enabled.
  If you are logged in, this will make the list of assets show below the page that you view (either home page, a post or a page).
>

The area will be shown through the wp_footer action so in case you do not see the asset list at the bottom of the page, make sure the theme is using wp_footer() function before the </body> tag. Any theme that follows the standards should have it. If not, you will have to add it to make sure other plugins and code from functions.php will work fine.

>

Example: If the URI contains et_fb=1 which triggers the front-end Divi page builder, then you can specify it in the list above (it's added by default) to prevent the asset list from showing below the page builder area.

'administrator', 'orderby' => 'user_nicename', 'order' => 'ASC' ); $users = get_users( $args ); ?>  
class="wpacu_hide" id="wpacu-allow-manage-assets-to-select-list-area">
This is a multiple selection drop-down. If nothing is chosen from the list, it will default to "any administrator".

Some people that have admin access might be confused by the CSS/JS manager (which could be for the developer of the website). If they are mostly editing articles, updating WooCommerce products and so on, there's no point for them to keep seeing a cluttered edit post/page with CSS/JS assets that can even be changed by mistake. You can leave this only to the developers with "administrator" roles.

:

:

Read more

  • Read more
  • Read more
  etc.

  Allow to anonymously track plugin usage in order to help us make the plugin better? No sensitive or personal data is collected. What kind of data will be sent for the tracking?
  Read more
day(s)
This is relevant in case there are alterations made to the content of the CSS/JS files via minification, combination or any other settings that would require an update to the content of a file (e.g. apply "font-display" to @font-face in stylesheets). When the caching is cleared, the previously cached CSS/JS files stored in that are older than (X) days will be deleted as they are outdated and likely not referenced anymore in any source code (e.g. old cached pages, Google Search cached version etc.). Read more
 If you wish to prevent Asset CleanUp Pro from triggering on certain pages (except the Dashboard) or group of pages for any reason (e.g. incompatibility with another plugin), you can specify some URI patterns in the following textarea (one per line), just like the examples shown below:

You can either use specific strings or patterns (the # delimiter will be automatically applied to the preg_match() PHP function that would check if the requested URI is matched). Please do not include the domain name. Here are a few examples:

  • /checkout/ - if it contains the string
  • /product/(.*?)/ - any product page (most likely from WooCommerce)
×

The following information will be sent to us, and it would be helpful to make the plugin better.

e.g. see which themes and plugins are used the most and make the plugin as compatible as possible with them, see the most used plugin settings, determine the most used languages after English which is helpful to prioritise translations etc.

setupData(); $pluginTrackingClass::showSentInfoDataTable($pluginTrackingClass->data); ?>
×

Any optimized files (e.g. via minification, combination) have their caching information (such as original location, new optimized location, version) stored in the disk by default (in most cases, it's the most effective option) to avoid extra connections to the database for a few files' information.

However, if you already have a light database and lots of Apache/NGINX resources already in use by your theme/other plugins, you can balance the usage of 's resources and go for the "Database & Disk (50% / 50%)" option (Example: If, for instance, on a page, there are 19 CSS/JS files which are optimized & cached, 10 would have their caching information fetched from the database while 9 from the disk).

The contents are stored like in the following example:

{"source_uri":"\/wp-content\/plugins\/plugin-title-here\/assets\/style.css","optimize_uri":"\/wp-content\/uploads\/asset-cleanup\/css\/item\/handle-title-here-v10-8683e3d8975dab70c7f368d58203e66e70fb3e06.css","ver":10}

Once this information is retrieved, the file's original URL will be updated to match the optimized one for the file's content stored in .

Note: If you are using a plugin such as WP-Optimize, WP Fastest Cache or the caching system provided by your hosting company, then this fetching process would be significantly reduced as visitors will access static HTML pages read from the caching. Technically, no SQL queries should be made as the WordPress environment would not be loaded as it happens with a non-cached page (e.g. when you are logged-in and access the front-end pages).