Nice refactoring 👍

Before we merge, we should discuss the final structure of paths:

1. Do we like the WP_CONTENT_DIR/.versionpress/<plugin-slug> path? Some alternatives:
   1. WP_PLUGIN_DIR/.versionpress/<plugin-slug> – would support WP_THEME_DIR/.versionpress/<theme-slug> in a natural way. (Please also see note on themes below.)
   2. WP_CONTENT_DIR/versionpress-definitions/<plugin-slug> (or something shorter than versionpress-definitions like vpdefs or @vp). The point here is to avoid the "dot name" which could maybe cause some issues in some cases (for example, ls does not list it by default, some backup plugin might iterate directories and skip the dot files, etc.).
   3. WP_CONTENT_DIR/.versionpress/plugins/<plugin-slug> to make room for themes in the future. Two notes here:
      • Maybe it's out of scope to think about themes now. We can delay this decision.
      • On a typical site, plugins dominate (many plugins per one active theme). Maybe it would be OK to have plugins at the top-level directory (WP_CONTENT_DIR/.versionpress) and put themes to a specially named one like WP_CONTENT_DIR/.versionpress/@themes. But it's just a thought now, I'm not sure I like it better.
2. What about core definitions? Do we like the path WP_PLUGIN_DIR/versionpress/.versionpress? I personally think it would be more consistent to put it in a subfolder like .versionpress/wp-core (of course making it unique so that it doesn't conflict with any plugin slug).
3. On a related note, do we want to support WP_PLUGIN_DIR/versionpress/.versionpress as one of the discovery locations? For example, if we wanted to ship WooCommerce support out of the box, it would give us the opportunity to use the WP_PLUGIN_DIR/versionpress/.versionpress/woocommerce folder.
   • An alternative would be to use these folders in our source code but do not use it at runtime as a dicovery location. VersionPress would need to copy the files from there to WP_CONTENT_DIR/.versionpress/<plugin-slug> on activation. Again, just an idea, I'm not sure I like it that much.

1.i.: It looks ok but what about WP core?
1.ii.: I think .versionpress shouldn't be a problem. It's similar to .git – it will break the site if someone performs backup & restore without .git.
1.iii.: I think this will be the best. WP_CONTENT_DIR/.versionpress/plugins/<plugin-slug> and WP_CONTENT_DIR/.versionpress/themes/<stylesheet> look fine.
2.: Subfolders in WP_PLUGIN_DIR/versionpress/.versionpress 👍 Maybe same structure as 1.iii.?
3.: We can drop the support of WP_PLUGIN_DIR/versionpress/.versionpress at any time. Let's keep it for now.

After some more internal discussion, the decision is:

• The path will be WP_CONTENT_DIR/.versionpress/plugins/<plugin-slug> for plugins and WP_CONTENT_DIR/.versionpress/themes/<stylesheet> for themes.
  • We'll go with the "dot name" .versionpress.
• WP core definitions will not be updatable via WP_CONTENT_DIR just yet. If we support that in the future, it will probably a sibling folder to /plugins and /themes like /core or /wp-core.
• WP_PLUGIN_DIR/versionpress/.versionpress will not be a third discovery location, it will only be used for WP core definitions (and even that might change in the future; WP core definitions could be downloaded from the online repo).

I would suggest structure similar to WordPress languages folder (everyone is familiar with it).

1. i. WP_PLUGIN_DIR is directory for plugins, we probably should not use it for definitions, it could lead to misunderstanding. WP_CONTENT_DIR is better in this case.
   ii. This path can leads to problems with future support for themes.
   iii. I agree that WP_CONTENT_DIR/.versionpress/plugins/<plugin-slug> is the best way. I am not sure if dot can lead to any problems, maybe it can be used without dot WP_CONTENT_DIR/versionpress/plugins/<plugin-slug> or change the whole name (no personal preference).

2. WP_PLUGIN_DIR/versionpress/.versionpress is OK, I guess. Core files can be also mirrored directly in WP_CONTENT_DIR/.versionpress/ (without special subfolder). But there are related issues, see point 3.

3. How will be definitions stored and updated? There will be some repo (server, something...) to store definitions and allow users to contribute. For example support for WooCommerce. When plugin authors create their own definitions, they can ship it inside their plugin package WP_PLUGIN_DIR/woocommerce/.versionpress/. Or they can submit definitions to planned repo and VersionPress will distribute it into WP_PLUGIN_DIR/versionpress/.versionpress/plugins/woocommerce or WP_CONTENT_DIR/versionpress/plugins/woocommerce? Using WP_PLUGIN_DIR is not very good because definitions should be able to update more frequently than core plugin files and for this case is probably better WP_CONTENT_DIR. But on the other hand, when we distribute it into WP_CONTENT_DIR, we should also give developers some other place or hook to allow them modify these files without danger of automatic updates (safe place which will be somehow discoverable by VersionPress, but never modified automatically). There is a special filter (often used) for example for languages to allow modification without rewriting original files, load_textdomain_mofile.

@pavelevap The plan for 3 is to download to WP_CONTENT_DIR. This takes precedence over the default definitions shipped with a plugin.

Filters are a good idea but we should probably wait until there's a specific need for it.