WordPress Plugins and permission on server folders.

[kgun]

I have no problems uploading most WP plugins to the remote server, but on some plugins I get an error.

Cannot create folder.

So my simple question is. What do you do, do you change the write permission on the remote forlder and rely on the plugin?

[kgun]

In addition I experience that some plugins are incompatible with the theme that is used. It is not difficult to deactivate the plugin. When you will delete the plugin, it cannot be deleted from the DashBoard without asking for ftp configuration like password etc. I personally dont like that, since the plugin can potentially steal that information. If some information is stored in the database, it can be better to let the information be in the database without cleaning it up and delete the files for the plugin on the remote folder. What do you think?

[webmaisterpro]

If you have recently relocate your blog to another server this may be the problem. Delete updates folder and recreate it. Sometimes this may help. Another thing is that your server may blog plugins like Akismet for example which is using remote access. A good idea is to contact the hosting company.

[NetProwler]

So my simple question is. What do you do, do you change the write permission on the remote forlder and rely on the plugin?

The plugin requires to write some configuration information in its directory. So the script needs write permission. You can allow write permission to the plugin directory in discussion.

If some information is stored in the database, it can be better to let the information be in the database without cleaning it up and delete the files for the plugin on the remote folder. What do you think?

It won't hurt to leave the plugin data in the database. But the question is the offending plugin has no business asking for ftp access details. If you feel paranoic, check the plugin script for the name of the additional table/data it has created and purge them directly.

[kgun]

It won't hurt to leave the plugin data in the database. But the question is the offending plugin has no business asking for ftp access details. If you feel paranoic, check the plugin script for the name of the additional table/data it has created and purge them directly.

Thank you for that answer. My experience with themes (and I think the same is valid for plugins) is that a theme can overwrite the default functionality in WP like the ability to create menus, a 404 error page etc.

Ideally as I see it, a theme and / or a plugin should be based on the default installation and modify that as little as possible, by making it simple, as simple as possible but no simpler. In other words minimalism for what you want to achieve with your plugin and / or theme. As an example, it was very easy to implement an AddThis button in the template files without relying on a Plugin. In that way I know what and how that is done.

If flexibility and future compatability is important, I think that is of utmost importance, unless you use the WP file system as a basis for a completely independent new site.

Note:

To run wordpress your host just needs a couple of things:

• PHP version 5.2.4 or greater
• MySQL version 5.0 or greater

The requirements have changed as of wordpress 3.2. The minimum requirements for wordpress 3.1 are PHP 4.3 and MySQL 4.1.2.

My bolding.

http://wordpress.org/about/requirements/

My general impression is that some good designers have made good looking themes that are bad on technology.

Can we expect a flow of questions on this an other forums when wordpress 3.2 is launched at the end of june?

[MrGamm]

My general impression is that some good designers have made good looking themes that are bad on technology.

I am fairly certain the new version is upgrading the jquery as well. Something to do with alot of widgets made with older libraries breaking in the newer IE9 browser. As for the older PHP technology. I do remember reading that a low percentage of hosts are using the older technologies, but there are still a few, and the upgrade process would halt if you to upgrade it on a machine without the right software.

But I am not really in the know regarding it all.

There was a mention of the WP.org server getting broken into and suspicious people making commits to the files. So, without going too far out on a limb, it does seem to be a piece of software with a high enough profile that it's getting picked on quite a bit.

http://www.guardian.co.uk/technology...opbox-weakness

If the plug-in fails to load due to permissions, and you've got your permissions set up right, there are so many other options, why compromise your security for a plug-in that may have a suitable alternative? I wouldn't give a plug-in the password to anywhere or change file folder persmissions if it asked. I don't really use wp though, so I don't truly understand your situation.

Can we expect a flow of questions on this an other forums when wordpress 3.2 is launched at the end of june?

Maybe?

(Last Month Search = 184 Pages) http://www.google.ca/search?q=site:wordpress.org+broke

(May = 178 Results) http://www.google.ca/search?q=site:w...w=1394&bih=736

(April = 371 Results) http://www.google.ca/search?q=site:w...w=1394&bih=736

(March = 412 Results) http://www.google.ca/search?q=site:w...w=1394&bih=736

(Feb = 201 Results) http://www.google.ca/search?q=site:w...w=1394&bih=736

Feb 23rd was the 3.1 release, maybe that explains the high volume in March?

http://wordpress.org/news/category/releases/

[NetProwler]

My experience with themes (and I think the same is valid for plugins) is that a theme can overwrite the default functionality in WP like the ability to create menus, a 404 error page etc.

Ideally as I see it, a theme and / or a plugin should be based on the default installation and modify that as little as possible, by making it simple, as simple as possible but no simpler. In other words minimalism for what you want to achieve with your plugin and / or theme. As an example, it was very easy to implement an AddThis button in the template files without relying on a Plugin. In that way I know what and how that is done.

I agree completely with you. Most well written themes and plugins add additional functionality and features as an extension and do not modify the core Wordpress scripts. Atahualpa theme is an example. It looks good and adds additional features and widgets. But if you change the theme to another theme from the WP control panel, it is seamless - in that it has not affected the core WP.

As far as the requirement for the new Wordpress is concerned, it is going to be hard on the hosts to upgrade to the recent version of PHP - especially those with Centos. I had a problem with Magento just about a month back. But anyway, wordpress 3.2 needs PHP 5.2.4 or greater, it didn't crib to get installed when I tried it with a server running only PHP 5.2.13.

[Ravenhawk]

That is a strange issue if you can upload without changing write permissions you should always be able to. Can you mention the plugins in question I would love to test them out. No you should not change your write permissions and depend on the plugin, write permissions should never be above 755 if they need any more they should be tossed or you need to change to a hosting provider that knows how to configure their system.

[Ravenhawk]

In addition I experience that some plugins are incompatible with the theme that is used. It is not difficult to deactivate the plugin. When you will delete the plugin, it cannot be deleted from the DashBoard without asking for ftp configuration like password etc. I personally dont like that, since the plugin can potentially steal that information. If some information is stored in the database, it can be better to let the information be in the database without cleaning it up and delete the files for the plugin on the remote folder. What do you think?

Again a bit strange I have never had a plugin ask for a password when deleting it. Yes, incompatibilities in themes happen the hazard of open source code..

[kgun]

Did you note this

Earlier today the wordpress team noticed suspicious commits to several popular plugins (AddThis, WPtouch, and W3 Total Cache) containing cleverly disguised backdoors. We determined the commits were not from the authors, rolled them back, pushed updates to the plugins, and shut down access to the plugin repository while we looked for anything else unsavory.

message?: https://wordpress.org/news/2011/06/passwords-reset/

and this

http://www.webproworld.com/webmaster...ssword-Warning

related later WPW thread?

I don't remember the exact plugins. One was related to form submission. I think there are many. I deleted it from my local and remote server in DreamWeaver (DreamWeaver is excellent to that). That plugin corrupted the whole site. It took me some minutes to fix the problem. Since I tried some other plugins that did not work as expected, I deleted them. When I tried to delete one plugin from the DashBoard, it asked for a database password. I don't like that, especially with a corrupt plugin.

That learned me that it is better (for me) to download a plugin / theme and upload it via ftp. Then you also have the same files on your local as on your remote server.

My daughter is new to this, and she is fast. She learned very fast how to implement widgets (light plugins) in the side bar. My preferred solution is to locate the relevant php template file and manually install it, most often by copying and pasting code / markup.

Let us say that you have a file sidebar1.php. Then my preferred solution is to make a new file sidebar2.php with all the new code and include it in sidebar1.php or in another template file.

Then on installing a new upgrade of WP, you keep the file sidebar2.php and inclue it in the upgraded version. Fast and more secure in my opinion.