Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

How can I prevent my plugin updates from clobbering the user edits and file additions in a particular subdirectory of my plugin?

I wrote a syntax highlighting plugin that makes use of GeSHi. A sub folder of the plugin is GeSHi itself. Many users will want to customize / edit the language files within GeSHi.

Specifically here is the directory structure:

  • wp-contente/plugins/my-plugin/
    • several subdirectories etc
  • wp-content/plugins/my-plugin/geshi/geshi/
    • users are going to add files to this directory
    • they will also edit files in this directory
    • when they pick up their new updates I don't want to erase their edits

What's the best way of solving this?

Thanks!


Here's what I was thinking, but I don't know how to implement:

  1. On the update plugin action hook (?) make a temporary copy of the files I want to preserve.
  2. Get the new version unzip and install like usual
  3. Copy the preserved files from the temp copy to the new version
  4. Remove the temp copy

Ideally this would all be done with files, but worst case scenario I could save data to the DB.

Problem is I don't see hooks for plugin updates. I looked here and here.

share|improve this question

2 Answers 2

Generally wordpress encourages one to use the uploads folder. Any plugin update will always overwrite whatever is in the plugin folder.

I have my plugins create a subfolder under uploads that stores any use editable stuff. That way it is safe from both wp and plugin / theme updates.

So far languages, my plugin checks if there is a custom language file in uploads/subfolder. If not then it loads from the plugin language folder the latest default language version.

share|improve this answer

Don't allow your users to add files or edit your files.

Instead, use things like do_action and apply_filters like the WordPress core does.

I'm not familiar with GeSHi, but I would suggest you figure out where in the class it loads the file required for the language. Modify the file path so it looks something like this:

$file_path = apply_filters( 'yourplugin_name_geshi_path', $file_path, $lanuage );

Then users could hook into it and modify the file path accordingly...

<?php
add_filter( 'yourplugin_name_geshi_path', 'wpse27248_path_modify', 10, 2 );
function wpse27248_path_modify( $path, $language )
{
   if( 'some_language' = $language )
   {
      $path = '/some/new/path';
   }
   return $path;
}

Your best bet is probably to create a Subclass of GeSHi, modify the methods you need to modify (as suggested), and use that class for your plugin. If GeSHi updates, you can drop in the new version without loosing your changes.

No having to worry about overriding user files or anything else. Users, if they need a new language in the library, can just create a very simple plugin of their own.

share|improve this answer
    
That is just not very user friendly. The way geshi works is that to add a language you just drop a file into the languages directory. I don't want to change existing functionality. –  Peter Ajtai Aug 30 '11 at 4:16
    
And ideally all of the files related to a plugin should be in the directory of that plugin and not somewhere else. Thanks for the idea though. –  Peter Ajtai Aug 30 '11 at 4:23
1  
I would argue that it is user friendly, if you consider your user. If someone has the knowledge to edit/create a GeSHi language file, they obviously understands PHP and probably the language for which they're making the file. It would be a simple matter for someone like that to write a WP plugin. Using a subclass allows you keep the original functionality intact, but alter what you need for your specific usage. –  chrisguitarguy Aug 30 '11 at 4:58
1  
I'm sure users would be able to do it, but the point of a Plugin is to make things convenient. That means plug and play and making sure GeSHi works the way that you're used to it working if you've used it before. –  Peter Ajtai Aug 30 '11 at 5:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.