Title: rlkz's Replies | WordPress.org --- # rlkz [ ](https://wordpress.org/support/users/rlkz/) * [Profile](https://wordpress.org/support/users/rlkz/) * [Topics Started](https://wordpress.org/support/users/rlkz/topics/) * [Replies Created](https://wordpress.org/support/users/rlkz/replies/) * [Reviews Written](https://wordpress.org/support/users/rlkz/reviews/) * [Topics Replied To](https://wordpress.org/support/users/rlkz/replied-to/) * [Engagements](https://wordpress.org/support/users/rlkz/engagements/) * [Favorites](https://wordpress.org/support/users/rlkz/favorites/) Search replies: ## Forum Replies Created Viewing 5 replies - 1 through 5 (of 5 total) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Simple History – Track, Log, and Audit WordPress Changes] 5.29.0 Translations update bug](https://wordpress.org/support/topic/5-29-0-translations-update-bug/) * [rlkz](https://wordpress.org/support/users/rlkz/) * (@rlkz) * [4 months, 1 week ago](https://wordpress.org/support/topic/5-29-0-translations-update-bug/#post-18933520) * Hi there, * We have the same issue (Translations ES). It was causing havoc with WPTC trying to get backups going (100plus diffs daily). * Remove Simple History completely, and there is no Translation Update available). Add Simple History back, and there is a Translations Update available. When you update (translations ES for Simple History), it doesn’t seem to indicate it was actually updated, and continues to show as an update. Simple History logs show a loop of it being installed for that plugin alone, over and over and over. * Odd issue we have not seen on any other site we maintain. More than happy to provide additional logs/site info if needed. * Thanks * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Backup and Staging by WP Time Capsule] Connection Failures for all sites](https://wordpress.org/support/topic/connection-failures-for-all-sites/) * Thread Starter [rlkz](https://wordpress.org/support/users/rlkz/) * (@rlkz) * [4 months, 2 weeks ago](https://wordpress.org/support/topic/connection-failures-for-all-sites/#post-18924309) * FYI, this issue seems to have cleared, and backups are resuming for most sites. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[PublishPress Capabilities: User Role Access Control, Admin Area Permissions] 2.41 breaks on front-end: “pp_capabilities_feature_enabled()” undefined.](https://wordpress.org/support/topic/2-41-breaks-on-front-end-pp_capabilities_feature_enabled-undefined/) * [rlkz](https://wordpress.org/support/users/rlkz/) * (@rlkz) * [6 months, 3 weeks ago](https://wordpress.org/support/topic/2-41-breaks-on-front-end-pp_capabilities_feature_enabled-undefined/#post-18861582) * Hi [@stevejburge](https://wordpress.org/support/users/stevejburge/) – Confirmed that the 2.40.0 release resolves fatal errors on two sites we manage. Thanks for the quick investigation/resolution. * Cheers * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[W3 Total Cache] Error in htaccess after updating to v2.8.0](https://wordpress.org/support/topic/error-in-htaccess-after-updating-to-v2-8-0/) * [rlkz](https://wordpress.org/support/users/rlkz/) * (@rlkz) * [1 year, 10 months ago](https://wordpress.org/support/topic/error-in-htaccess-after-updating-to-v2-8-0/#post-18159561) * Hi [@vmarko](https://wordpress.org/support/users/vmarko/) – I’ve played around with a small site that had the issue, and I believe I have found the culprit. * For this particular site (centralmachinery.ca), W3TC was already in place for a year plus without issue. After a recent upgrade, a visit to the site would suddenly result in a 500 Internal Server Error, which would not go away unless this particular line (which is faulty – bad syntax) was removed from .htaccess: * ```wp-block-code Header set Public-Key-Pins "pin-sha256="$pin"; pin-sha256="$pinbak"; max-age=31536000" ``` * If the line was removed, and the site refreshed, it would be added back immediately, and the 2nd page refresh would result in a 500. * The only solution was to disable/delete the w3tc plugin directory, and then strip the htaccess file. A re-install of the plugin would result in same behaviour, as it was pulling configs from the wp-content/w3tc-config/master.php file. If that file is deleted prior to a new install/activation, the site responds as expected. So that may be one quick fix for you [@tutumu](https://wordpress.org/support/users/tutumu/)– Backup that master.php file, delete it, install latest version, and re-run setup guide. You should be good to go. * However, if within the Browser Cache Settings of the plugin, under Security Headers, HTTP Public Key Pinning is enabled, that offending line is added to the .htaccess file, and the problems start up again. Of note, I have not modified any default settings within Public Key Pinning – I just know that as soon as it’s enabled and saved, the .htaccess file is no longer valid and the site will no longer load. * FWIW * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[W3 Total Cache] Error in htaccess after updating to v2.8.0](https://wordpress.org/support/topic/error-in-htaccess-after-updating-to-v2-8-0/) * [rlkz](https://wordpress.org/support/users/rlkz/) * (@rlkz) * [1 year, 10 months ago](https://wordpress.org/support/topic/error-in-htaccess-after-updating-to-v2-8-0/#post-18157367) * Hi, * We’ve seen similar behaviour on multiple sites. The offending line is: * Header set Public-Key-Pins “pin-sha256=”$pin”; pin-sha256=”$pinbak”; max-age= 31536000″ * ________ (Fatal – Header has too many arguments) * Which we’ve found via a tool here: [http://www.htaccesscheck.com/](http://www.htaccesscheck.com/) * For many sites, as soon as W3TC is enabled, the local .htaccess is amended with the usual headers/caching settings, but this line causes a 500 error as soon as the site is refreshed. If the offending line is removed, but the plugin remains active, a refresh of any page will re-insert it, causing the 500 error again. Removing the plugin completely, taking out all references of W3TC within the . htaccess restores site functionality. However, once the plugin is re-installed and activated, the issue re-appears. We’re still trying to find commonality on the sites where this occurs. * Of note one cannot go into Browser Cache/General settings of the plugin to try to disable individual options, because as soon as the plugin is enabled, the offending .htaccess line will cause a 500 error on any page visit within the site. * [@vmarko](https://wordpress.org/support/users/vmarko/) Viewing 5 replies - 1 through 5 (of 5 total)