Custom PHP Settings vs Cyclone Static

This plugin can be used to customize php settings for you WordPress installation. The plugin will modify either the .htaccess file or .user.ini file in order to change the current php settings directly from within the settings page. Since the configuration file needs to be modified this file must be writable for this plugin to work as expected. Apache module When PHP is running as an Apache module the .htaccess file will be used to set customized settings; make sure so that this file exists and is writable by the webserver. CGI/Fast-CGI If instead PHP is running in CGI/Fast-CGI mode then a custom INI file will be used. The name of this file depends on the value of user_ini.filename in the php configuration, by default it is .user.ini. You can check the name of you custom INI file in the PHP Information table. The custom INI file should be placed under the root folder and most be writable by the webserver. Notice that there is also a User INI file cache TTL value in the information table, this value tells how long the custom INI file will be cached before it gets reloaded. For instance, if this value is set to 300 then any changes to your custom INI file will not be reflected for up to 5 minutes. The name for this setting in the php configuration is user_ini.cache_ttl. One important thing is to make sure that your .user.ini file is blocked by your webserver. If you are running NGINX this can be done by adding: location ~ /\.user\.ini { deny all; } to your server configuration. The same thing using Apache is done by adding the following to the configuration if not already done: order allow,deny deny from all Available Settings The settings table will display all non-system php settings that can be customized by the plugin. All modified settings will be displayed in red in this table. Some settings might be displayed in red because they are changed somewhere else, perhaps through a customized php.ini file, by WordPress itself, a plugin or in some other way. For instance if you have enabled WP_DEBUG in your wp-config.php file the error_reporting setting will turn red. If you have questions or perhaps some idea on things that should be added you can also try slack. Multiple Configurations The premium version adds support for creating multiple named configurations which all can hold their own custom PHP settings. You will then be able to easily switch between the different configurations entries applying them to you configuration file. Environment Variables In the premium version, when running PHP as an apache module and using an .htaccess file for configuration, you are able to add custom environment variables. These will be accessible by using the super global $_SERVER array. In order for this to work you will need to have the mod_env module enabled in your apache setup. Resources A complete list of settings that can be modified can be found here: List of php.ini directives Notice that directives marked as PHP_INI_SYSTEM can not be modified. Warning Make sure you know how a value should be configured and what different settings do before changing anything. This is important since some settings might render your page inaccessible, depending on what value you are using. A good example of this is the variables_order configuration: Sets the order of the EGPCS (Environment, Get, Post, Cookie, and Server) variable parsing. For example, if variables_order is set to “SP” then PHP will create the superglobals $_SERVER and $_POST, but not create $_ENV, $_GET, and $_COOKIE. Setting to “” means no superglobals will be set. If this value would be configured to EPCS then no $_GET superglobal would be set which would make your page inaccessible. Another example is setting the post_max_size to a very low value so that no form data is sent to the server, which in turn would result in that form data is never saved. If you by mistake changed some value and your site is now inaccessible you could simply manually remove everything from between the plugin markers in your .htaccess file: # BEGIN CUSTOM PHP SETTINGS PRO php_value variables_order EPCS <-- Remove # END CUSTOM PHP SETTINGS PRO If you are running PHP in CGI/Fast-CGI mode then instead remove everything between the plugins markers in your .user.ini file: ; BEGIN CUSTOM PHP SETTINGS php_value variables_order EPCS <-- Remove ; END CUSTOM PHP SETTINGS Support If you run into any trouble, don’t hesitate to add a new topic under the support section: https://wordpress.org/support/plugin/custom-php-settings/ You can also try contacting me on slack.

Cyclone Static generates fully-rendered static HTML files for every page on your WordPress site and instructs Apache to serve them directly — bypassing PHP, WordPress, and the database for anonymous visitors. When a static file exists for a requested URL, Apache reads it from disk and sends it without starting PHP or querying the database. The visitor receives a complete HTML page. Their browser runs your JavaScript, plays your audio, renders your animations — everything works as it did before, because the static file contains the same HTML WordPress would have generated. Logged-in users, POST requests, query strings, and administrative paths bypass the static cache and receive live WordPress as normal. Key features Static file serving — Apache serves files directly from disk. PHP and the database are not involved in serving anonymous page requests. Automatic regeneration — When you publish or update a post or page, it is automatically queued for regeneration. You do not need to do anything. Reduced attack surface — Static HTML files do not execute PHP or query a database. Common WordPress-targeted attack vectors that require a live PHP process — such as SQL injection via PHP, PHP code execution, and xmlrpc.php abuse — do not apply to anonymous page requests served as static files. CDN integration — Works alongside W3 Total Cache. Direct integration with Bunny.net, Cloudflare, KeyCDN, and Amazon CloudFront is available in Cyclone Static Pro. W3 Total Cache compatible — Installs its .htaccess rules before W3TC rules. Works alongside or without W3TC. Non-destructive — Deactivating the plugin removes the .htaccess rules and WordPress resumes normal operation. Your cached files are not deleted without your explicit consent — a prompt appears when you deactivate, asking whether to keep or delete them. Free and open — No license required. Support via the WordPress.org community forums. System requirements WordPress 6.0 or later PHP 8.0 or later Apache web server with mod_rewrite enabled .htaccess support enabled (AllowOverride All or equivalent) WordPress Multisite is not supported in this version — Multisite support is available in Cyclone Static Pro Nginx users: Cyclone Static manages .htaccess automatically on Apache. If your server runs Nginx, the Settings page includes a ready-to-paste Nginx server block under Settings → Nginx Configuration. CDN support The free version works automatically alongside W3 Total Cache — CDN purges are routed through W3TC when it is active. Direct API integration with Bunny.net, Cloudflare, KeyCDN, and Amazon CloudFront is available in Cyclone Static Pro. Privacy Cyclone Static does not collect, transmit, or store any personal data. The queue table stores only URLs. No external service is contacted except the CDN purge APIs you explicitly configure. Support Support is provided via the WordPress.org community forums. Post your question there — answers are public, so search first as your question may already be answered. For private inquiries, you can reach us at [email protected]. Confirmed bugs are addressed through plugin updates. Private one-on-one support is not offered via the forums. External Services Cyclone Static can optionally connect to the following third-party services to purge cached content from your CDN. These connections are only made when you configure a CDN provider under Settings → CDN Integration and a purge is triggered. No data is sent to these services unless you explicitly configure them. Bunny.net Used for CDN cache purging. Your Bunny.net API key and Pull Zone ID are sent to the Bunny.net API. * Service: https://bunny.net/ * API documentation: https://docs.bunny.net/reference/purgepublicpullzone * Privacy policy: https://bunny.net/privacy/ Cloudflare Used for CDN cache purging. Your Cloudflare API token and Zone ID are sent to the Cloudflare API. * Service: https://www.cloudflare.com/ * API documentation: https://developers.cloudflare.com/api/resources/cache/methods/purge/ * Privacy policy: https://www.cloudflare.com/privacypolicy/ KeyCDN Used for CDN cache purging. Your KeyCDN API key and Zone ID are sent to the KeyCDN API. * Service: https://www.keycdn.com/ * API documentation: https://www.keycdn.com/api * Privacy policy: https://www.keycdn.com/privacy Amazon CloudFront Used for CDN cache invalidation. Your AWS Access Key, Secret Key, and CloudFront Distribution ID are sent to the Amazon CloudFront API. * Service: https://aws.amazon.com/cloudfront/ * API documentation: https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateInvalidation.html * Privacy policy: https://aws.amazon.com/privacy/