Upgrade instructions fatally flawed for Mac

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Steve Lewis-6
On 1/18/07, Charles <[hidden email]> wrote:
>
> > [Steve]  It *can* be written.  It can work cleanly.  It can improve
> > the application.  Charles, I guess I'm signing on to help.
>
> Excellent!  I'll do whatever I can, too.  I'm more of a PM-type than a
> coder, but I know enough to be dangerous.   :O)   Time for me to spend
> some
> cozy time with the source...


I'm a good coder, and I have been rooting around in WP code for a couple
years now, authoring custom plugins, themes, and a couple hacks.  I can do
all the work, but wouldn't by any means refuse the chance to collaborate.
The /most/ important part of this feature is it's design.  Should we allow
the path to be configurable?  Should we allow it to be outside the webroot?
What security implications does that introduce?


--
SteveL
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Petit
Steve Lewis wrote:

> On 1/18/07, Charles <[hidden email]> wrote:
>>
>> > [Steve]  It *can* be written.  It can work cleanly.  It can improve
>> > the application.  Charles, I guess I'm signing on to help.
>> <snip>
> I'm a good coder, and I have been rooting around in WP code for a couple
> years now, authoring custom plugins, themes, and a couple hacks.  I
> can do
> all the work, but wouldn't by any means refuse the chance to collaborate.
> The /most/ important part of this feature is it's design.  Should we
> allow
> the path to be configurable?  Should we allow it to be outside the
> webroot?
> <snip>
No.
For coders, geeks and that kind, it is OK to be outside the web servers
document root.
For many other normal users, that will be too complicated.

/Petit

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: User folders for themes, plug-ins

Charles-50
In reply to this post by Steve Lewis-6
> I'm a good coder, and I have been rooting around in WP code for a
> couple years now, authoring custom plugins, themes, and a couple
> hacks.

Awesome.

> Should we allow the path to be configurable?

Let's depend on convention over configuration at first, keeping it
conceptually simple as we introduce it.  However, any new WP functions that
need to be created could abstract the path to the point that they wouldn't
prevent this from becoming configurable in the future.

> Should we allow it to be outside the webroot?

I can't think of reason that this would be necessary, but others might.

-- Charles


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Steve Lewis-6
In reply to this post by Petit
On 1/18/07, Petit <[hidden email]> wrote:

>
> > The /most/ important part of this feature is it's design.  Should we
> > allow
> > the path to be configurable?  Should we allow it to be outside the
> > webroot?
> > <snip>
> No.
> For coders, geeks and that kind, it is OK to be outside the web servers
> document root.
> For many other normal users, that will be too complicated.
>

Of course, I don't suggest not providing a useful default.  I don't mean to
be dense, but how is support for the scenario complicated exactly?  I'm not
following.

--
SteveL
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Aaron Brazell-3
In reply to this post by Andy Staines
That you did. I personally just found out about that yesterday  
afternoon.
--
Aaron Brazell
Technology Architect, b5media
"A Global New Media Company"

web:: www.b5media.com, www.technosailor.com
phone:: 410-608-6620
skype:: technosailor



On Jan 18, 2007, at 8:29 AM, Andy Staines wrote:

> Didn't I come across a new constant defined in 2.1 named PLUGINDIR ?
> Which I recall is set to 'wp-content/plugins'
>
> Andy

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Steve Lewis-6
In reply to this post by Charles-50
On 1/18/07, Charles <[hidden email]> wrote:

>
> Let's depend on convention over configuration at first, keeping it
> conceptually simple as we introduce it.  However, any new WP functions
> that
> need to be created could abstract the path to the point that they wouldn't
> prevent this from becoming configurable in the future.
>
> > Should we allow it to be outside the webroot?
>
> I can't think of reason that this would be necessary, but others might.
>

For Mac servers, the problem stems from directory replacement behaviors.
IIRC that is how we ended up here.
That leaves us with the important question of how can Wordpress:

a) deprecate wp-content/plugins and wp-content/themes
b) while continuing to support existing plugins which depend on that path
gracefully
c) make sure that the new 'user-extensions' directory exists on install
d) not overwrite that directory on upgrade

By my thinking it will require the path to be customizable by configuration.

I can also say that I have some concerns over the security of the model that
allows us to write plugins that generate HTML responses.  I don't know that
having the new user extensions directory outside the webroot is necessary,
but would want to consider it at least.

--
SteveL
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: User folders for themes, plug-ins

Brian Layman
A less intrusive solution might be more compatible.  Rename the wp-content
directory, in the distribution tarball, to wp-std-content.  Then during the
install/upgrade process, the files in the wp-content-std directory are
iteratively copied into the wp-content directory.  WordPress would make no
other references to wp-std-content.

Since this is a file by file process, the whole directory replacement
argument is moot.  There does not need to be a massive rewrite of existing
plugins.  No testing need be done on all the areas of the core code that
reference plugins or themes.  It a has a limited scope of change and limited
testing requirements.  It does not complicate the tarball.  What are the
negatives?  Are the functions required to perform the copy going to be
active in all php installs?

_______________________________________________
Brian Layman
http://www.TheCodeCave.com
http://www.TheCodeCave.com/EasyWPUpgrade
 

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Steve Lewis-6
On 1/18/07, Brian Layman <[hidden email]> wrote:
>
> A less intrusive solution might be more compatible.  Rename the wp-content
> directory, in the distribution tarball, to wp-std-content.  Then during
> the
> install/upgrade process, the files in the wp-content-std directory are
> iteratively copied into the wp-content directory.  WordPress would make no
> other references to wp-std-content.


And this requires WordPress to have write permissions to the filesystem.
That is currently not the case and I believe it would gain us very little
over the current system.

--
SteveL
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: User folders for themes, plug-ins

Brian Layman
> That is currently not the case
.htaccess is written to, if nothing else.  If write access is the problem,
the fix could be to reference wp-std-content if wp-content does not exists.
We could probably put such a rule in .htaccess.  Though I think a core code
solution would be better.

I'm not so sure this issue really needs to be fixed, as it has not caused
problems even up to this point.  But if a fix must be made, an objective for
that solution should be that it not lead to more harm and confusion than
what the original issue caused.

So, solutions that break a bunch of plugins, for a bunch of users, seem to
be inappropriate if fixing the issue for a very limited number of servers is
the main pay off.

Something to keep in mind...

_______________________________________________
Brian Layman
http://www.TheCodeCave.com
http://www.TheCodeCave.com/EasyWPUpgrade
 




_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: User folders for themes, plug-ins

Charles-50
In reply to this post by Steve Lewis-6
>> I can't think of reason that this would be necessary, but others
>> might.
>
> IIRC that is how we ended up here.  For Mac servers, the problem
> stems from directory replacement behaviors.

The current problem is that user and system files are intermingled within
individual folders.

This first step is to separate user plug-in and theme files into their own
folder.  These user folders would be in the root folder and not included
with WP, so users can drag in all files and folders from new WP
distributions and everything will be fine.

I understand you're talking about the use case where someone using a
folders-replace-folders client (not a "Mac servers" issue per se) could drag
the single "wordpress" folder over their "wordpress" folder, but for that to
be useful we'd have to move /all/ user files outside the WP root
(wp-config.php, wp-images, etc.).  That might be a really great thing to do
in the future, but that shouldn't block this interim improvement.

> a) deprecate wp-content/plugins and wp-content/themes

No, these have to stay as system plug-in and theme folders.

-- Charles


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: User folders for themes, plug-ins

Chris Williams-9
In reply to this post by Brian Layman
How about a solution that separates system and user content, by moving
the system content?  To wit:

- Move system supplied content to a new directory (e.g. wp-syscontent)
- Change core code to look in both this directory and wp-content (with a
priority on one or the other -- that argument yet to be had)
- From then on wp-content is solely a user directory
- On update, don't touch wp-content

This involves only changes to core code, doesn't farkle with user
content directories on update (avoiding the original problem), doesn't
break a bunch of existing plug-ins, and more elegantly separates user
and system content.

-----Original Message-----
From: Brian Layman
Subject: RE: [wp-hackers] User folders for themes, plug-ins

So, solutions that break a bunch of plugins, for a bunch of users, seem
to
be inappropriate if fixing the issue for a very limited number of
servers is
the main pay off.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Steve Lewis-6
In reply to this post by Brian Layman
On 1/18/07, Brian Layman <[hidden email]> wrote:

.htaccess is only written to if the WordPress install has access to write to
it, but the app still functions if it can't.
And that writing to .htaccess is merely for adding the mod_rewrite rules
AFAIK.  Please correct me if I am wrong.

I'm not so sure this issue really needs to be fixed, as it has not caused
> problems even up to this point.


The mix of customized files amongst standard files is peeving.  It makes
backups either unnecessarily wasteful or complex.  It makes upgrading more
of a chore than it need be. See also your upgrade script (which I haven't
taken the time to try to adapt).

So, solutions that break a bunch of plugins, for a bunch of users, seem to
> be inappropriate if fixing the issue for a very limited number of servers
> is
> the main pay off.


sorta like deprecating $table_* purely for stylistic purposes? :)

I think your point is valid.  We might be too far down the road with the
current directory structure to change short of a 3.0 release.

I offered to help with implementation but if we can't find agreement on the
scope of work than I'll spend my time on something else.  If I'm the only
person standing on this side of the fence, I won't pick a fight.

--
SteveL
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: User folders for themes, plug-ins

Charles-50
> I offered to help with implementation but if we can't find agreement
> on the scope of work than I'll spend my time on something else.  If
> I'm the only person standing on this side of the fence, I won't
> pick a fight.

This can be made unnecessarily complex, but solving the current problem (of
mixed user and system files in folders) is straightforward:

- Add "My Themes" and "My Plug-Ins" folders to the root folder.*

- Whenever the same theme exists in the user folder and the system folder,
prefer the theme from the user folder.

- Whenever the same plug-in exists in the user folder and the system folder,
prefer the theme from the user folder unless it's older than the plug-in
from the system folder.

Once this is implemented, users who like how it works now can still use WP
that way.

-- Charles

*I can hear a couple folks sneering at the names, but I've walked enough
people through WP installations and upgrades that I'm confident that proper
names (i.e. for people) and locations (i.e. not buried) would really help.


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade instructions fatally flawed for Mac

Lloyd Dewolf
In reply to this post by Michael B-2
On 1/17/07, Michael B <[hidden email]> wrote:
> Regardless of this pissing match over Finder vs FTP, I altered the
> instructions 2 days ago to say "do not overwrite your wp-contents
> directory".  If someone wants to add to manually overwrite Akismet, knock
> themselves out.  I don't think Default or Classic have been changed in quite
> sometime, and anyone using default or classic have probably made changes,
> and wouldn't want them overwritten anyway.

Your change is greatly appreciated, but it also does not address any
fundamental problem -- are  specific instructions desirable for a
particularly environment?

I specifically had hoped to clarify why some people think Mac OS X
only knows how to overwrite folders. What are the steps to duplicate
the problem?
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: Upgrade instructions fatally flawed for Mac

Charles-50
(I'm reluctant to continue the thread because I think this has been
explained multiple times, but here's a try at a summary...)

> I specifically had hoped to clarify why some people think Mac OS X
> only knows how to overwrite folders. What are the steps to duplicate
> the problem?

There are two things a client can do when copying/moving folder "Foo" (we'll
call this "new Foo") into another folder that already contains a folder
called "Foo" ("old Foo").

- Behavior 1:  Replace Folder

  In this case, you assume the user wants to replace "old Foo" with
  "new Foo" wholesale.  Any files in "old Foo" that don't exist in
  "new Foo" are gone forever.

- Behavior 2:  Merge Folder

  In this case, you assume the user wants to merge -- that is,
  replace individual files in "old Foo" with same-named files in
  "new Foo" -- the two folders instead of replacing them.  Any
  files in "old Foo" that don't exist in "new Foo" are still
  around.

Mac OS X users can merge folders using the FileMerge utility that ships with
the OS <http://www.macworld.com/weblogs/macosxhints/2006/03/cmpfldr/>.

-- Charles

*Examples of different clients include Mac OS X's Finder, FTP app running on
Mac OS X, Windows Explorer, Sftp Drive (which mounts an SFTP server as a
Windows drive letter), the Linux "cp" command, etc.


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: User folders for themes, plug-ins

Steve Lewis-6
In reply to this post by Chris Williams-9
On 1/18/07, Chris Williams <[hidden email]> wrote:
>
> - Change core code to look in both this directory and wp-content (with a
> priority on one or the other -- that argument yet to be had)


I like that idea as well. It avoids breaking existing plugins, and can be
readily changed in core code.  My ideal solution would be to dig the user
content out from the bowels of the wp code, but this works.

--
SteveL
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade instructions fatally flawed for Mac

André Schieleit
In reply to this post by Lloyd Dewolf

Am 18.01.2007 um 23:06 schrieb Lloyd Budd:

> Your change is greatly appreciated, but it also does not address any
> fundamental problem -- are  specific instructions desirable for a
> particularly environment?
>
> I specifically had hoped to clarify why some people think Mac OS X
> only knows how to overwrite folders. What are the steps to duplicate
> the problem?
This problem only exists when copying folders using Finder.

When using Terminal and the cp command existing files will be left  
alone.
I did a quick test in Terminal:

/* create two directories with the same name in different locations */
 > mkdir -p mytest
 > mkdir -p mytest1/mytest

/* populate the directories with some files */
 > f=1;while (($f<5));do touch mytest/$f.txt;((f=$f+1));done
 > f=1;while (($f<5));do touch mytest1/mytest/new$f.txt;((f=$f+1));done

/* copy the second directory to the location of the first directory */
 > cp -R mytest1/mytest .

/* list the content of the first directory */
 > ls mytest/
1.txt  2.txt  3.txt  4.txt  new1.txt  new2.txt  new3.txt  new4.txt
 >

So you see: the files created in the first directory are still there.
Tested on Mac OS X 10.4.8 in Terminal

   André_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade instructions fatally flawed for Mac

Michael B-2
In reply to this post by Lloyd Dewolf
On 1/18/07, Lloyd Budd <[hidden email]> wrote:

>
> On 1/17/07, Michael B <[hidden email]> wrote:
> > Regardless of this pissing match over Finder vs FTP, I altered the
> > instructions 2 days ago to say "do not overwrite your wp-contents
> > directory".  If someone wants to add to manually overwrite Akismet,
> knock
> > themselves out.  I don't think Default or Classic have been changed in
> quite
> > sometime, and anyone using default or classic have probably made
> changes,
> > and wouldn't want them overwritten anyway.
>
> Your change is greatly appreciated, but it also does not address any
> fundamental problem -- are  specific instructions desirable for a
> particularly environment?


First and foremost, for a long time, in WP support, the de rigeur was to not
touch wp-contents.  I don't know who and what changed that, so I don't know
why or how... In Mac, if you want to overwrite something in a directory, you
are prompted "an older item exists, do you want to overwrite", so, there's a
fail safe... but without knowing...no merge of content..

So long story short, I still stand by the opinion that leave wp-content
alone, unless release notes mention a change to a bundled plugin/theme
(which right now is akismet (opinion withheld/ default (god forbid that's
upgraded...))

I specifically had hoped to clarify why some people think Mac OS X
> only knows how to overwrite folders. What are the steps to duplicate
> the problem?
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
123