BPS keeps bumping me back to php 5.2

Upon rereading it, I think it’s talking about the line my host added to htaccess regarding the using of php 5.4 but I still don’t know where to copy that to. A folder name and file name for BPS Custom Code would be helpful. folder/folder/filename.xxx for example
Thanks

I think I got it. I copied

# Use PHP5.4 as default
AddHandler application/x-httpd-php54 .php

From my root htaccess into the custom code tab of BPS plugin admin page. Just noticed those tabs for the first time. Medium grey text on medium blue tabs just doesn’t show up very well. I can see where BPS has written to my root htaccess. Can it not copy from it into it’s own database field? Why did I have to do it manually?

PHP/php.ini handler htaccess code means either php handler htaccess code or php.ini handler htaccess code.

To add PHP/php.ini handler htaccess code to BPS Custom Code to save it permanently to your database these are the steps:
1. Copy your PHP/php.ini handler .htaccess code to this BPS Root Custom Code text box: CUSTOM CODE TOP PHP/PHP.INI HANDLER/CACHE CODE
2. Click the Save Root Custom Code button.
3. Go to the Security Modes page, click the Create secure.htaccess File AutoMagic button, select the Activate Root Folder BulletProof Mode Radio button and click the Activate|Deactivate button.

Adding any custom/personal htaccess code to BPS Custom Code saves that code to your database permanently so that it will always be created in your htaccess file. Clicking the Create secure.htaccess File AutoMagic button creates a new Master htaccess file that has all BPS standard .htaccess code and includes any custom/personal code that you have saved to BPS Custom Code. Activating BulletProof Mode copies the Master htaccess file to your website root folder to make it active/Live.

Medium grey text on medium blue tabs just doesn’t show up very well.

Those are not the standard BPS CSS colors – see screenshots of what BPS plugin pages are supposed to look like visually: https://www.ads-software.com/plugins/bulletproof-security/screenshots/. So what that means is that another plugin that you have installed or your theme is loading CSS and probably js scripts too in BPS plugin pages and changing/breaking the visual appearance of BPS plugin pages. Unfortunately, this is a very common problem: https://forum.ait-pro.com/forums/topic/bulletproof-security-menus-css-and-js-not-displaying-correctly/ and there is not much more we can do about these coding mistakes in other plugins and themes.

[dumb idea – redacted]
We should not have to replace our good coding standards/practices with bad coding standards/practices in order to compensate for other plugins and themes with bad coding standards/practices/mistakes.

I see that another plugin that you have installed is also being visually broken by another plugin or your theme: https://www.ads-software.com/support/topic/dont-mess-with-the-core?replies=1

Meanwhile this link doesn’t show up well at all because it’s medium gray on dark gray. Almost didn’t see it and I’ll bet a lot of people won’t.

Please deactivate your plugins one by one to figure out which plugin is causing the visual problems for all of your other plugins that use jQuery. BPS, Network Switch Button, etc. If the problem is still occurring after deactivating all of your plugins then switch your theme to a WordPress theme: 2015, 2014, etc. Please post the name of the plugin or theme that is breaking other plugins CSS and js scripts so that we can test it and figure out how to permanently prevent this plugin or theme from breaking BPS CSS and js scripts. Thanks.

Note: We have a list of several plugins and themes that are are doing a variety of non-WordPress coding practices/bad coding practices in general so we would like to find an overall solution for all of these Rogue plugins and themes instead of trying to individually block/prevent all of these Rogue plugins and themes from breaking other plugins.

I believe we have come up with a concept that will work for not only the BPS plugin, but will also work for all plugins. This is in the concept stage so the concept description below is generalized.

BPS New Feature Name: Rogue Script Killer
Concept: Create a Rogue Script Killer constant that can be created in the wp-config.php file in an automated way from within the BPS plugin. Rogue Script Killer option settings will allow someone to also list other plugins to protect against Rogue plugin and theme scripts loading in those plugin’s pages and breaking them. The way it would work is Rogue scripts would be detected by BPS and then you would use the Rogue Script Killer option settings to prevent that Rogue script from loading on all BPS plugin pages and breaking them. Additional option settings would allow you to do the same for any/all other plugins that are being broken by Rogue plugin or theme scripts.

Rogue Script Killer Alert:
Plugin X appears to be loading its CSS and js scripts in BPS plugin pages which is breaking BPS from displaying visually correct and possibly breaking other things. Click here to go to the Rogue Script Killer options page to prevent Plugin X from breaking the BPS plugin. You can also use the Rogue Script Killer to fix and stop Plugin X from breaking other plugins on your website.

Notes: First stage of concept development will focus on the wp-admin backend area only so if the Rogue plugin or theme is also breaking things on the frontend of the site then the next stage of development will be to add additional option settings that will allow someone to prevent Rogue scripts from breaking things on the frontend of a website.

Found it. It’s the Piklist plugin which is for templating CPTs but I haven’t even used it yet so it’s odd that it’s overriding BPS styling. I left an fyi thread on their support board here on wp.org

If a plugin is activated on the WordPress Plugins page then it is “in use” and will load its scripts even though you are not actually using it. ?? Thanks for posting the plugin name. We will download the plugin and include it our testing for the new Rogue Script Killer feature.

No problem. What I meant was, I haven’t used it to create or style any custom post types so it’s not something I caused. Merely having the plugin activated causes it.

Yep, got that and just wanted to state everything very clearly in case anyone else comes across this topic.

And to also state this very clearly so that someone does not think the Piklist plugin is a bad plugin. It could be a simple coding mistake or a misunderstanding about standard WordPress script enqueue methods. In any case, the BPS Rogue Script Killer feature will not negatively impact any other plugins and will simply do only 2 things: detect rogue script problems and allow someone to create a quick and simple solution for rogue script problems. At a later time if a plugin author fixes the rogue script problem in that plugin then whether or not the BPS Rogue Script Killer feature is still preventing a rogue script from loading somewhere will not matter and will not negatively impact anything.

I think the BPS Rogue Script Killer feature will be a very handy and useful thing. What is so annoying about this particular rogue script problem is that users are not aware that visually things are all screwed up in a plugin and just assume that the plugin author must either be blind or a visual idiot to create such a horrible visual UI. We have actually gotten several 1 star or low star Reviews because folks thought that the BPS visual UI was horrible and were not aware that another plugin or theme was causing the problem. There is no indication that this problem is occurring…well not yet anyway == BPS Rogue Script Killer. ??

Thanks for letting us know about the conflict. We will take a look and let you know what we find.

In reality, piklist is more something to be used in a local environment anyway where BPS would not be needed.

@piklist – containing backend script loading to your plugin pages in the wp-admin backend area is very simple to do. The frontend of the site on the other hand is a much more difficult thing to do if your plugin does not have a “set/standard” Request URI you can check against. ie the users can create anything they want anywhere.

if ( preg_match( '/page=plugin-folder-name/', esc_html($_SERVER['REQUEST_URI']), $matches ) ) {
// your script loading code here
}