Legacy Plugin Accelerator

Status
Not open for further replies.
This suggestion has been closed. Votes are no longer accepted.
Update: This will be implemented in tomorrow's update for vB Optimise.

For security reasons, the mod will not come with a "default storage directory" for the cached files, requiring manual input of a path (similar to the path to downloads in vBDownloads). A storage directoryu should be created outside the web root (e.g. public_html) and made writeable.
 
You shouldn't have any issues, as I took steps to make sure that accessing the plugin cache files via the URL does not cause any PHP errors.

However, I would still strongly recommend placing the folder outside public_html, for the simple reason that the directory needs to be CHMOD 0777. In the event of a security breach on your site, any folder that is CHMOD 0777 is a potential storage site for malicious files (like PHP Shell scripts or database dumpers). For that reason, it's recommended to limit the number of such folders that can be accessed via the URL, unless explicitly needed.
 
hi!

can anyone give me an example of what should the correct input be like? for the directory?
whatever i input i still get an error message:
"error:
You did not enter a valid value for this setting."
 
You shouldn't have any issues, as I took steps to make sure that accessing the plugin cache files via the URL does not cause any PHP errors.

However, I would still strongly recommend placing the folder outside public_html, for the simple reason that the directory needs to be CHMOD 0777. In the event of a security breach on your site, any folder that is CHMOD 0777 is a potential storage site for malicious files (like PHP Shell scripts or database dumpers). For that reason, it's recommended to limit the number of such folders that can be accessed via the URL, unless explicitly needed.

This is simply not correct. The directory must be writable by the web server user. That is true. But where the web server is running as the domain/user, you do NOT have to chmod 777.

The most common case for needing chmod 0777 is where PHP is running as an Apache module. But not many hosts are running with this setup anymore. Most are using FastCGI, and PHP is running as the site owner and not as the generic apache user.

Please do not advise users to chmod 0777 unnecessarily. We are running the plugin optimizations just fine and our directory is the default 755, again, because PHP is running as our site user and the site user owns the folder.
 
Please do not take offense. Just wanted to offer advice for users setting this up. Don't want anyone introducing security issues where they don't have to.
 
hi!

can anyone give me an example of what should the correct input be like? for the directory?
whatever i input i still get an error message:
"error:
You did not enter a valid value for this setting."
You need to know the full path to your web directory, for example /home/Fillip H./public_html, then create a folder on the same level as public_html, so that the path becomes /home/Fillip H./plugincache.

Does that help make it clearer? :)

This is simply not correct. The directory must be writable by the web server user. That is true. But where the web server is running as the domain/user, you do NOT have to chmod 777.

The most common case for needing chmod 0777 is where PHP is running as an Apache module. But not many hosts are running with this setup anymore. Most are using FastCGI, and PHP is running as the site owner and not as the generic apache user.

Please do not advise users to chmod 0777 unnecessarily. We are running the plugin optimizations just fine and our directory is the default 755, again, because PHP is running as our site user and the site user owns the folder.
While you are technically correct, please understand that your level of knowledge regarding server administration is an order of magnitude above the level of the vast majority of our customers.

That is not to say that any of our customers are not intelligent, far from it. All our customers have knowledge about a vast array of fields that baffle me and you in the same way that what you just said baffles them.

If you put yourself in their shoes, what would you rather be told:
1. Go here and set the permissions like this
-OR-
2. Go to your server's vhost config file and find the user and group your web server is running as
2a) But if you are running on a shared host, contact your host for support and wait for them to reply
2b) Make sure folders created via your FTP server are created as the same user/group as your web server
2b i) Unless you want to avoid people editing your files via web exploits, in which case you will need to create a new user/group account on the server and make sure your FTP server is creating files & folders as this user, with read-only permission for World, then chown the folders to the user/group of your web server

You see my point? Instruction set 2 is so vastly more complex that the average user is unable to follow it. For that reason, we will continue to tell people to CHMOD 0777 :)
 
How about: create the folder. If it doesn't work, contact your host or chmod 777 the folder. 98% of hosts are not going to require 777 these days.

But that's just me I guess.
 
How about: create the folder. If it doesn't work, contact your host or chmod 777 the folder.
Two steps where one would suffice, especially asking someone to contact their host just to install a vB mod. You are now asking a non-technical person to explain to a technical person why they are making the ticket; "because this vBulletin modification's installation instructions told me to".

98% of hosts are not going to require 777 these days.
Then again, just 4 months ago 98% of hosts didn't have display_errors turned off, and were still running PHP 5.3. Now that 5.3 is fast approaching EOL (if not already), and cPanel has deprecated PHP 5.3, web hosts decide that hiding errors is a better practice than making users update their PHP scripts.

Who knows what will happen when PHP 5.5 becomes mainstream, or 5.6, or 6.

My point is, what hosts will do changes rapidly, so we'd rather not rely on it or make our products less accessible :)
 
Status
Not open for further replies.
Back
Top