Ticket #20
rick c
files in a subdirectory is one of the oldest tickets in trac. It may
be too early to do so, but I've created a branch, located in /branches/
onefolder to work on this. The directory structure consists of two
main directories, /system and /user, with all files subject to upgrade
in /system, and all user maintained files in /user (with the exception
of config.php for a single-site install, which can easily be moved
into /user once we decide how to perform the upgrade). The changes
required to make this directory structure work appear to have been
minimal
Unless I forgot to include a change I made, the branch seems to be
working properly. Obviously, I haven't been able to test it with all
plugins, most notably it hasn't been tested with staticfront as yet.
It would be helpful if people would checkout the branch and test it to
find where it fails.
Several issues crossed my mind as I was working on this.
1. Is this something we want to do? If not, the ticket should be
closed as a wontfix.
2. How do we deal with the upgrade to this directory structure? I
don't recall working with an upgrade that moved directories. Should
the installer attempt to move them, or should we require people to
move the directories manually. Note that we are at a 0.x version.
3. I see two benefits from a directory structure such as this, to keep
the root of the install as clean as possible, and to let upgrades be
as simple as ripping out /system and dropping the new /system in. As
such, the placement of /3rdparty is questionable. We've told people it
can be used for installing third party components. Simply deleting /
system for an upgrade becomes untenable once they install such
components. Should we leave it in system and implicitly leave those
situations for the user to deal with; should /3rdparty be on the same
level as /system and /user; or should we have a /user/3rdparty for
user installed third party components (the option that makes the most
sense to me and most closely mirrors the rest of Habari)?
4. Why are humanmsg and hotkeys in /3rdparty? They are javascript, so
I'm surprised they're not in /scripts with other third party scripts
Habari uses.
Rick
Randy Walker
I like the work you've put into this. I asked once before why some
third-party scripts are in one place and some are in another and never
got a clear answer. I like your idea of a completely replaceable /
system folder.
--
Randy Walker
Realpolitik
Now, my question: should there be a 3rd party and/or scripts folder
in /user by default? What if 5 plugins all require a YUI component,
you don't want the YUI scripts in /user/plugin/name/ five times, you'd
prefer to have them in /user/scripts/ or /user/3rdparty, right?
If you move 3rdparty and scripts, you should create them in both
subdirectories.
On Jun 19, 12:13 am, Randy Walker <randy.wal...@mac.com> wrote:
> </lurk>
>
> I like the work you've put into this. I asked once before why some
> third-party scripts are in one place and some are in another and never
> got a clear answer. I like your idea of a completely replaceable /
> system folder.
>
> --
> Randy Walker
>
>
>
>
>
>
> >https://trac.habariproject.org/habari/ticket/20- Run Habari with most
Realpolitik
users to do so if it fails for whatever reason.
On Jun 19, 12:07 am, rick c <rickcock...@gmail.com> wrote:
> https://trac.habariproject.org/habari/ticket/20- Run Habari with most
Owen Winkler
> https://trac.habariproject.org/habari/ticket/20 - Run Habari with most
> files in a subdirectory is one of the oldest tickets in trac.
> Several issues crossed my mind as I was working on this.
>
> 1. Is this something we want to do? If not, the ticket should be
> closed as a wontfix.
I hate to say it, but I don't think what's been done was the intent of
the ticket.
My impression of what the ticket's original request was for was not to
consolidate Habari into as few directories as possible, but to package
the entire installation excluding an index.php and .htaccess file into a
single directory that could be *relocated*.
Whether the directories include 3rdparty or scripts at the root of the
Habari install is unimportant to the original request. What is
important is that whatever directories there are can be moved into some
single directory (likely named "habari") somewhere in the system, and
with a minor tweak to the index.php file to tell php where to find that
directory, everything would continue to work.
The original request in this ticket has nothing to do with ease of
update. It likely has somewhat to do with directory sprawl, but not
directory count. It has primarily to do with being able to relocate the
bulk of the Habari files to some other place in the filesystem.
All that said, the work done here has some other benefits.
> 2. How do we deal with the upgrade to this directory structure? I
> don't recall working with an upgrade that moved directories. Should
> the installer attempt to move them, or should we require people to
> move the directories manually. Note that we are at a 0.x version.
People really won't have to move their own directories, will they? Just
(optionally) delete the directories that were moved, and update /system.
> 3. I see two benefits from a directory structure such as this, to keep
> the root of the install as clean as possible, and to let upgrades be
> as simple as ripping out /system and dropping the new /system in. As
> such, the placement of /3rdparty is questionable. We've told people it
> can be used for installing third party components. Simply deleting /
> system for an upgrade becomes untenable once they install such
> components. Should we leave it in system and implicitly leave those
> situations for the user to deal with; should /3rdparty be on the same
> level as /system and /user; or should we have a /user/3rdparty for
> user installed third party components (the option that makes the most
> sense to me and most closely mirrors the rest of Habari)?
/3rdparty should stay where it was. All contents of /3rdparty should be
user-supplied. It shouldn't have any system-supplied components in it.
The scripts that were there should move to /system/scripts.
My own use of /3rdparty makes sense to me, but it's what I do and not
everyone cares to do it this way. Plugins I write go in /user/plugins.
Plugins everyone else writes go in /3rdparty/plugins. This is not the
"correct way", just "a useful way to me".
Most users can just ignore the 3rdparty directory. As a matter of fact,
I think Habari will run fine (if the dependencies like BP and javascript
libraries are moved out of there) even if the directory isn't there at all.
> 4. Why are humanmsg and hotkeys in /3rdparty? They are javascript, so
> I'm surprised they're not in /scripts with other third party scripts
> Habari uses.
Yes. See above.
Owen