Fork me on GitHub

Subject:*
Name/Email:*
Message Icon:*
Message:*
url email imgsrc image php hide code quote
SAMPLE
alignleft aligncenter alignright bold italic underline linethrough   


 [more...]
Options:*
 

 

 
View requirements*
Reply No requirement
Confirmation Code*
  The code is case-insensitive  Click the image for a new code. | Maximum attempts: 8
     
Re: New Protector 3.50 feature - enable manipulation checking

by debianus on 2011/3/9 4:24:56

Yes, or update could be a nightmare..and deactivate by default
Re: New Protector 3.50 feature - enable manipulation checking

by Vaughan on 2011/3/6 13:17:03

Quote:


This is a very good thing to have, but there needs to be a better way to upgrade your sites, or control the behavior. I'm not sure how GiJoe intends to handle upgrades and recovering sites when the changes are made, but it does need some improvement.



how about adding a step in the update script that disables that function upgrade before the update commences, & then enables it again after update is completed?
Re: New Protector 3.50 feature - enable manipulation checking

by Will on 2010/9/28 8:49:11

Same thing happened to me - it took forever to figure this one out.

The swearing could be heard from miles around.
Re: New Protector 3.50 feature - enable manipulation checking

by debianus on 2010/9/28 0:59:01

Thanks for the tip about access to the site again.
I would recommended disable the feature in module preferences: my first day using Protector 3.50 was a shock for it (look it was on a local server)
New Protector 3.50 feature - enable manipulation checking

by skenow on 2010/9/26 20:13:36

Protector 3.50 (beta) has a new feature that can be useful, but frustrating if you are accustomed to working directly on your files through ssh or even ftp. Or, even if you want to upgrade your sites through a normal process.

If you enable the 'manipulation checking' feature, any change to any file within your installation will result in a blank page with the message "Protector detects site manipulation". If you happen to change a file, as I just did (changed my .htaccess file) while this option is activated, you will shut down your site and make it inaccessible until you disable the feature in your database.

If you run into this, you'll need to connect to your database, (I used phpMyAdmin), find the module ID for Protector (in prefix_modules), then filter the config table for items for the Protector module. You will be looking for the config_name of 'enable_manip_check' and want to set it to '0'. Then you will be able to access your site again.

This is a very good thing to have, but there needs to be a better way to upgrade your sites, or control the behavior. I'm not sure how GiJoe intends to handle upgrades and recovering sites when the changes are made, but it does need some improvement.