WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 2 months ago

#41078 closed defect (bug) (maybelater)

Detect if someone’s site is under version control, and suggest better ways to edit their sites

Reported by: karmatosed Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:

Description

Can we detect if someone’s site is under version control, and suggest better ways to edit their sites if they try to make changes using the Code Editors?

Change History (11)

#1 @swissspidy
6 months ago

We already detect sites under version control for updates. See \WP_Automatic_Updater::is_vcs_checkout().

#2 @dd32
6 months ago

Unfortunately detecting this isn't exactly easy, nor ideal for a web app.

For example, older SVN created a .svn folder in each directory versioned, it was easy, just look for the folder!. Later SVN (1.7?) just added .svn to the root directory (Git is the same). The background upgrader currently looks in all directories up to / to determine if a site is under version control.

Unfortunately it doesn't really help to determine, if say, Theme X is under a version control system - or if it's the entire WordPress install under the VCS.. The best option would be to parse each VCS's data store to determine which files it's got under version control, but I don't think that's going to be a viable option for core (and also dealing with the many versions of said VCS's).

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


6 months ago

#4 @melchoyce
4 months ago

Maybe we could just start with detecting Git files in your active theme or plugins for now?

#5 @melchoyce
4 months ago

  • Milestone changed from Awaiting Review to 4.9

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


3 months ago

#7 @westonruter
3 months ago

  • Keywords close added

One solution that comes to mind is that WordPress could detect whether or not a theme or plugin's files are versioned by first locating the .git or .svn directory to sniff the VCS type, and then it could run svn info %s or git ls-files --error-unmatch %s to determine if it is versioned.

While that would work, it would also not work reliably across WordPress installs because hosts will often disable shell commands. This is the same issue we're facing in wanting to add a PHP linter for CodeMirror in #41873. So unless there is a way to sniff inside of .git and .svn directories to find out whether a given file is versioned (as @dd32 notes), I don't see this as being feasible. I also don't think we want to write Git or SVN clients in PHP.

#8 @westonruter
3 months ago

  • Priority changed from normal to high

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

#9 @DavidAnderson
3 months ago

Presence of a .svn or .git folder doesn't prove that this particular instance is being deployed by version control. It can just mean that the guy who copied it over copied those directories too unwittingly, and didn't think about removing them. Or that the developer zipped up something for the site owner to try and forgot to remove those first, etc.

#10 @danieltj
2 months ago

Whilst it's not the most elegant solution, it does provide some fallback in detecting if there is a .svn or .git folder in the root and then setting a flag which states the site is (at least partially) under a VCS and having an interface for a user to yay or nay say which files/folders are being VCS'd.

It's not the most ideal but in some instances people may want to update a production site that is under VCS and push to the repo from prod down to dev etc. Everyone uses SVN and Git differently and this seems like the most inclusive approach. You could also argue that those that know it's under a VCS won't try and edit it using the Code Editor, so doing expensive background tasks doesn't seem like a great idea.

#11 @westonruter
2 months ago

  • Keywords close removed
  • Milestone 4.9 deleted
  • Priority changed from high to normal
  • Resolution set to maybelater
  • Status changed from new to closed

Since we have the warning now when editing files (#31779), the need for this is lessened. And since detection will not be very reliable, I think we'll close this as maybelater.

Note: See TracTickets for help on using tickets.