Upgrading best practice?

So I am currently playing with the latest svn version and doing a little testing on some test sites that we have and I came across the usual problem I have with plugins.

When testing a new version I create a new jojo folder and point the config there. The result is that any plugins other than the default aren't there anymore. Obviously copying them over is the answer but it got me wondering if anyone else had a different approach.

Or perhaps we need to define a plugin directory in the config file too?

So I am currently playing with the latest svn version and doing a little testing on some test sites that we have and I came across the usual problem I have with plugins. When testing a new version I create a new jojo folder and point the config there. The result is that any plugins other than the default aren't there anymore. Obviously copying them over is the answer but it got me wondering if anyone else had a different approach. Or perhaps we need to define a plugin directory in the config file too?

Where do you normally store your plugins?

The way we do it is we have one folder with all the plugins in it (checked out from SVN in our case but equally a copy of the plugin pack would work). Then in each site we create a symlink for each of the plugins we are using.

- Mike

Where do you normally store your plugins? The way we do it is we have one folder with all the plugins in it (checked out from SVN in our case but equally a copy of the plugin pack would work). Then in each site we create a symlink for each of the plugins we are using. - Mike

I am using a system that Harvey created - al plugins are in the plugin directory along with the core plugins.

We have a file that we access via ssh
php plugins.php - that svn updates all the plugins individually.

Please note the one line that needs to be updated for your specific install.

I have a local version of the plugin svn, that gets all the available plugins. When new ones are added, I manually add to the plugins.php file.

I have added a rar compressed version of the plugins.php file that I use. It gets things from the trunk - so could be enhanced to have the option of pulling from the branch and tags that have been created in the last week.

I am using a system that Harvey created - al plugins are in the plugin directory along with the core plugins. We have a file that we access via ssh php plugins.php - that svn updates all the plugins individually. Please note the one line that needs to be updated for your specific install. I have a local version of the plugin svn, that gets all the available plugins. When new ones are added, I manually add to the plugins.php file. I have added a rar compressed version of the plugins.php file that I use. It gets things from the trunk - so could be enhanced to have the option of pulling from the branch and tags that have been created in the last week.

Thanks heaps guys, and for the php script, nice and easy way to do it.

Mike, I haven't heard of a symlink before. Would you mind explaining a little further? Using it are you able to control what is and isn't seen by the user in the list of plugins? Like each plugin is located in the mysite dir but only one code base?

Thanks.

Thanks heaps guys, and for the php script, nice and easy way to do it. Mike, I haven't heard of a symlink before. Would you mind explaining a little further? Using it are you able to control what is and isn't seen by the user in the list of plugins? Like each plugin is located in the mysite dir but only one code base? Thanks.

Actually I just found some docs on symlink. My only question is, do you put that in global or config or...

Actually I just found some docs on symlink. My only question is, do you put that in global or config or...

symlinks are added directly into the file system using shell commands, so although very handy for us, you can't use them (at least I can't) on a shared server platform that doesn't allow you shell access.

if you have the same folder structure on your dev environment, you can make symlinks there, tar the whole lot and extract it again on the live server and the links will be maintained, which is handy also. but again, if you don't have shell access you won't be able to extract archives on the hosted server either...

we put symlinks to a single collection of all plugins into each site's mysite/plugins folder so that users only see what they've been given. Given that we charge for adding new functionailty, it would be bad business practice to give clients access to every plugin available that they could then just install and use themselves.

symlinks are added directly into the file system using shell commands, so although very handy for us, you can't use them (at least I can't) on a shared server platform that doesn't allow you shell access. if you have the same folder structure on your dev environment, you can make symlinks there, tar the whole lot and extract it again on the live server and the links will be maintained, which is handy also. but again, if you don't have shell access you won't be able to extract archives on the hosted server either... we put symlinks to a single collection of all plugins into each site's mysite/plugins folder so that users only see what they've been given. Given that we charge for adding new functionailty, it would be bad business practice to give clients access to every plugin available that they could then just install and use themselves.

Thanks tom.

I will setup the php file that harvey setup for searchmaster. In the mean time I will sick to blocking users from the manage plugins page through their user group. Not fool proof but a step in the right direction.

Thanks tom. I will setup the php file that harvey setup for searchmaster. In the mean time I will sick to blocking users from the manage plugins page through their user group. Not fool proof but a step in the right direction.