WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 9 months ago

#7395 closed enhancement (worksforme)

Plugins within a folder (in SVN) should be moved up a level in our plugin upgrader

Reported by: markjaquith Owned by:
Milestone: Priority: high
Severity: normal Version: 2.6
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:

Description

The Paged Comments plugin exists in SVN under a 'paged-comments' directory. Since the auto-upgrader puts plugins into a directory based on their slug, this results in the plugin being under two 'paged-comments' directories. We should be able to identify when a plugin's trunk (or current branch) directory contains only another directory, and move the whole plugin up a level.

Attachments (2)

7395.diff (4.8 KB) - added by DD32 6 years ago.
7395.2.diff (8.3 KB) - added by DD32 5 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 follow-up: DD326 years ago

I have a feeling this should be done server side during the zip creation stage, However, adding a functionality like that to the WordPress code seems like a good idea as well.

There has been a previous ticket/discussion on this, From memory the outcome was along the lines of "Then you're using the SVN repo wrong"

comment:2 in reply to: ↑ 1 Otto426 years ago

Replying to DD32:

There has been a previous ticket/discussion on this, From memory the outcome was along the lines of "Then you're using the SVN repo wrong"

Seems like the right answer to me. I mean, you could make the ZIP creator smarter, or you could kick the plugin author around a bit until he does it correctly. Either way. :)

comment:3 ryan6 years ago

  • Milestone changed from 2.7 to 2.8

Moving enhancements to 2.8.

comment:4 DD326 years ago

This is rather needed by the plugin uploader; Unless the .zip file is exactly alike the wordpress.org archives, it'll get installed, but potentially in the wrong locations, and the end result will be files exist on the server which do not appear on the plugins list.

While its not a problem for plugins downloaded from wordpress.org, it is a problem for all the plugin archives out there which do not fit.

My solution for this ticket is along the lines of:

* Search for all .php files in the unpacked archive
* check for plugin details in all files
* find the plugin file thats lowest in the directory structure
* copy the folder based on dirname($plugin_file) from previous step
* if dirname($plugin_file) == '.', Set it to copy from a directory lower than the contents of the zip (it'll be a folder based on the wordpress.org slug, or the uploaded zip filename)

But i havnt implemented that yet. It depends on if its felt that leaving the plugin uploader as it is for 2.7 is ok, or if this really needs to be implemented for it. (My vote is that it needs implementing, but not too sure on the timeframe on my behalf, so someone else doing it would be nice for sure :))

DD326 years ago

comment:5 DD326 years ago

  • Keywords has-patch added
  • Milestone changed from 2.8 to 2.7

attachment 7395.diff added.

  • Locates the best plugin directory to copy the plugin from
  • prefixes an extra directory to the unzip process if the zip does not contain a folder which the plugin is in

Its an enhancement/defect, But its needed for the plugin zip uploader, So i'm going to push for it in 2.7?

There is a issue with the functionality at present however; If you attempt it with a plugin which does not use the correct SVN layout (eg: http://wordpress.org/extend/plugins/micromint/ ), then extra files end up in the wp-content/plugins/ folder, in this case, the screen shots and readme. But it should be noted, that the plugin doesnt work with the upgrader or installer at present anyway.

I'll look into that problem tomorrow, see if i can work around it by ignoring files not in the plugins folder perhaps.

comment:6 ryan6 years ago

  • Priority changed from normal to high

DD325 years ago

comment:7 DD325 years ago

attachment 7395.2.diff added.

Working patch. The problem of files in the parent directory of the plugin has been fixed, along with the activation links being incorrect.

comment:8 DD325 years ago

  • Keywords commit added

comment:9 ryan5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [9523]) Support installation of plugins living in a subdir in svn. Props DD32. fixes #7395

comment:10 ryan5 years ago

(In [9524]) Set perms when making plugin dirs. see #7395

comment:11 ryan5 years ago

(In [9664]) Revert [9523]. fixes #8195 see #7395

comment:12 ryan5 years ago

Got several reports of this breaking things (#8195 for example) so I reverted since we're so close to release.

comment:13 ryan5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:14 jacobsantos5 years ago

  • Keywords needs-patch added; has-patch commit removed
  • Milestone changed from 2.7 to 2.8

comment:16 DD325 years ago

  • Milestone changed from 2.8 to 2.9
  • Owner changed from anonymous to DD32
  • Status changed from reopened to new

Since we're once again close to release, Bumping this again for 2.9.

I've included a filter in #7875 (Source_selection or similar, i cant remember right now) which should make this relatively easy to achieve.

Get it in store for early 2.9 with the possibility for backport to 2.8.1 IMO.

comment:17 westi4 years ago

  • Milestone changed from 2.9 to 3.0

This needs a new patch I suspect and some testing.

I think it has missed the boat for 2.9 due to feature freeze.

Moving to 3.0

comment:18 dd324 years ago

  • Milestone changed from 3.0 to Future Release

Setting to Future release due to impending Feature freeze and no new patch.

comment:19 dd329 months ago

  • Component changed from Administration to Upgrade/Install
  • Owner DD32 deleted
  • Status changed from new to assigned

comment:20 nacin9 months ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from assigned to closed

"Stable tag:" supports specifying a subdirectory for the zips. Think this is worksforme; it should be handled on the WP.org side. (Also, clearly no one has been clamoring for it.)

Note: See TracTickets for help on using tickets.