This is an imported issue, original reference WP-10, created on 21 Jun 2013.

WordPress supports PHP 5.2.4+ and will probably not move higher any time soon. We should ideally support the same PHP versions but opinions on this vary, see comments.

This is an imported issue, original reference WP-9, created on 14 Jun 2013.

So that they're distinguishable from plain user commits (e.g., a template edit in some editor).

This is an imported issue, original reference WP-50, created on 03 Aug 2014.

Commits linked to this issue implement the old workflow which used to do uninstallation right after the deactivation. The new workflow is implemented in #58.

• This issue relates to #51

This is an imported issue, original reference WP-20, created on 10 Jan 2014.

Show initialization progress – how tables are being created, copying data into files, creating repository etc.

This is an imported issue, original reference WP-23, created on 31 Jan 2014.

Log all Git commands and its results (both stdout and errors).

This is an imported issue, original reference WP-48, created on 28 Jul 2014.

This is an imported issue, original reference WP-44, created on 24 Jul 2014.

This is an imported issue, original reference WP-27, created on 20 Feb 2014.

In the table of commits, allow revert of a single commit. Use git revert.

Note: this is different from returning to the commit which is like undo for every commit since the given SHA.

This is an imported issue, original reference WP-49, created on 31 Jul 2014.

For example, when the post changed, it would be great to display a side-by-side diff of the text, similarly to how Bitbucket or Octosplit does that. (BTW, Octosplit could be interesting for us if it can convert patch format into side-by-side by some JavaScript).

Or, when wp_option changes, display the old and new value. Etc.

We could probably use our ChangeInfo objects for that, if every type implemented this functionality the best way it can.

This is an imported issue, original reference WP-39, created on 23 Jul 2014.

Check the .maintenance file etc. Check that all is ready for production.

This is an imported issue, original reference WP-34, created on 22 Jul 2014.

This is an imported issue, original reference WP-32, created on 21 Jul 2014.

This is an imported issue, original reference WP-43, created on 23 Jul 2014.

http://php.net/manual/en/function.uniqid.php

This is an imported issue, original reference WP-24, created on 14 Feb 2014.

For example, after the Options Framework installation, the plugin shows "Your current theme does not have support for the Options Framework plugin. Learn More / Hide Notice", see attachment. Add to VersionPress installation something similar what would guide the user to finish the installation by doing a full initialization.

This is an imported issue, original reference WP-41, created on 23 Jul 2014.

db.php is run on every request. Check that we don't do wasteful things there.

This is an imported issue, original reference WP-29, created on 03 Jul 2014.

Commit message will have this shape:

*---------------------------------*
| Readable message                |
|                                 |
| Machine readable message part   |
*---------------------------------*

This is an imported issue, original reference WP-11, created on 02 Aug 2013.

Initial import can be – and will be with larger websites – time consuming, can suffer from timeouts etc.

The goal is to split up the initial import into smaller chunks and inform the user via AJAX.

Several problems need to be sorted out, like what to do with the data that arrives into the database during the import, etc.

This is an imported issue, original reference WP-13, created on 27 Sep 2013.

Currently, we call Git command line commands on the server – Git needs to be installed and calling external processes enabled.

The goal is to create an implementation that will be usable on:

1. Own server with custom security – possibly something like an PHP extension
2. Standard shared host – this might need pure-PHP implementation of Git.

This is an imported issue, original reference WP-8, created on 14 Jun 2013.

Ideally, VersionPress should install as a normal plugin.

Suggestion: first install some relatively simple PHP script that checks that the WP site meets the system requirements (e.g., db.php is available, Git is installed etc.). If the checks pass, VersionPress installs, otherwise the user gets a report and maybe a link to manual steps.

This is an imported issue, original reference WP-40, created on 23 Jul 2014.

For v1, to start simple, we reference the whole (minified) Nette which is wasteful – we use only a couple of things from it. We should:

1. Explore if this has real negative impacts (the requiring occurs in db.php so maybe we do wasteful stuff on every request?)
2. Fix this by referencing only what we need.

Nette since 2.2 is split into components, but that is PHP 5.3 only. Depending whether we're going to support PHP 5.2 or not (#10), we will or will not be able to use modular Nette. If not, we will need to create our own distribution of the older Nette.

This is an imported issue, original reference WP-28, created on 21 Feb 2014.

On Friday 21 Jan 2014 quickly duplicated a list of excluded options from OptionsStorage into the revert functionality. Remove this duplicity.

This is an imported issue, original reference WP-38, created on 23 Jul 2014.

This is an imported issue, original reference WP-45, created on 28 Jul 2014.

This is an imported issue, original reference WP-26, created on 20 Feb 2014.

Columns:

Date and time | 7-char SHA | Commit message | Actions

Actions are "Revert to this" (roll back the whole site to a certain state) and "Undo" (undoes one change).

This is an imported issue, original reference WP-7, created on 14 Jun 2013.

This is an imported issue, original reference WP-37, created on 23 Jul 2014.

Will be used in the main VP table.

This is an imported issue, original reference WP-30, created on 17 Jul 2014.

See versionpress_deactivate() and the recommendation here: http://wordpress.stackexchange.com/a/717/12248

• This issue relates to #58

This is an imported issue, original reference WP-19, created on 09 Jan 2014.

In admin, user can click and go back to a previous state.

This is an imported issue, original reference WP-14, created on 27 Sep 2013.

The synchronization (now in sync.php) must be doable via administration. The synchronization process between DB and files must be preceded by getting the files together and doing a Git merge.

This is an imported issue, original reference WP-1, created on 10 Apr 2013.

In general:

• key-value tables will be one file with many rows
• the posts table will be a directory with a bunch of files (one per post) - be careful about the revisions, they only change the file, not create a new one.

The structure of files should ideally make the diffs in Git to be clear and meaningful (for example, prefer an easy text format to XML, etc.).

• This issue blocks #2

This is an imported issue, original reference WP-18, created on 12 Dec 2013.

Demo:

• Installation, activation
• Changing something in WordPress creates a commit
• Functional revert – write a plugin using the old API, update WordPress and update a theme

This is an imported issue, original reference WP-2, created on 10 Apr 2013.

See #1.

• This issue is blocked by #1

This is an imported issue, original reference WP-17, created on 08 Nov 2013.

This is an imported issue, original reference WP-15, created on 18 Oct 2013.

Besides the new UI, this is the second pillar of the 2.0 release. See linked issues for actionable tasks.

• This issue relates to #159
• This issue relates to #389
• This issue relates to #463

This is an imported issue, original reference WP-33, created on 22 Jul 2014.

For example, the hook is called "activate" but that one doesn't create the .active file – that one is being created only by the "Installer", which is another slightly confusing name.

• This issue relates to #47

This is an imported issue, original reference WP-6, created on 12 Jun 2013.

During installation, it is necessary to reflect the database content into files.

It's going to be a separate script for now, WordPress integration will come later.

This is an imported issue, original reference WP-31, created on 21 Jul 2014.

E.g., change author from Agilio to VersionPress, etc.

This is an imported issue, original reference WP-3, created on 10 Apr 2013.

A new commit should be created with every logical change in WordPress (new commit, plugin installation etc.), separate tickets will be created for this. This ticket should create an infrastructure for others - prepare a function or hook or something that others are going to call which will in turn create a new commit in the repository.

Test on an easy use case, for example, creating a post.

This is an imported issue, original reference WP-22, created on 31 Jan 2014.

Commit done by VersionPress should have a user and email of the currently logged in user (WP can have more admins and this will allow for searching who's done what).

Probably use the --author switch for each commit.

This is an imported issue, original reference WP-4, created on 06 Jun 2013.

The aim is not to touch the existing WordPress tables (and plugins) and a possibility to define the structure and relation of tables in an external file.

This is an imported issue, original reference WP-16, created on 01 Nov 2013.

When syncing environments, the configuration (wp-config) should be very similar except database settings. Those are typically different for each environment and should not be transferred.

This is an imported issue, original reference WP-21, created on 10 Jan 2014.

Currently, updating WordPress creates 2 commits, one after creating temporary files and one after the actual update. Both commits also have quite a cryptic message. The goal is to create only a single commit, ideally with the message like "[VP] WordPress updated to version 3.8".

This is an imported issue, original reference WP-5, created on 12 Jun 2013.

After "git pull", reflect the content of the into the database.

Manual script is OK for now, automation will come later.

This is an imported issue, original reference WP-25, created on 14 Feb 2014.

Use case: user uses VersionPress but otherwise doesn't know a thing about Git. When she updates some files directly on the disk (e.g., HTML or CSS files of the theme), she should be able to go to the administration and click "commit" (with some user-friendly label) and optionally enter commit message.

Another use case is when VersionPress doesn't catch something – the user knows she should see a commit but it's simply not there. Manual commit would be a way to fix this situation.

Discussion:

Jan's comment: it's not clear how to make this feature available. If this is a clearly visible button, it will be slightly confusing because there would be nothing to commit most of the time. When we hide it by default then there's not much point in the functionality in the first place. Because of this, we're moving this to some future update.

An idea of how to possibly surface the functionality: if there's ever a screen like "advanced" or "emergency" where not too common but occasionally useful sits, it could be there.

• This issue is blocked by #446

This is an imported issue, original reference WP-46, created on 28 Jul 2014.

This is an imported issue, original reference WP-42, created on 23 Jul 2014.

So far, the deactivation flow is implemented by #58, reactivation is, however, quite stupid (it cannot continue from the previous repository). Ideally, when user re-activates VersionPress, we should somehow "merge" the old Git repo and the potentially updated DB. Maybe we could delete all files from db and generate them from scratch with that we would find, in vp_* tables, which IDs were tracked before. However, in the meantime, there might have been new data in the DB, or moved somewhere, which breaks IDs.

This needs to be thought through yet.

This is an imported issue, original reference WP-12, created on 04 Sep 2013.

This is an imported issue, original reference WP-47, created on 28 Jul 2014.

• This issue relates to #33

This is an imported issue, original reference WP-36, created on 22 Jul 2014.

The format is not entirely self-documenting, for example, "id" is maybe more something like "idColumn", also the way we write down foreign keys could be simplified.

This is an imported issue, original reference WP-35, created on 22 Jul 2014.

It's a less standard format, consider using JSON or something similar.