phpslash-devel Mailing List for phpSlash (Page 15)
Brought to you by:
joestewart,
nhruby
Menu
▾
▴
phpslash-devel — For developers of phpslash to communicate.
This list is closed, nobody may subscribe to it.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(45) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(29) |
Feb
(49) |
Mar
(38) |
Apr
(22) |
May
(39) |
Jun
(21) |
Jul
(6) |
Aug
(9) |
Sep
(6) |
Oct
(26) |
Nov
(42) |
Dec
(19) |
| 2003 |
Jan
(15) |
Feb
(71) |
Mar
(40) |
Apr
(41) |
May
(28) |
Jun
(5) |
Jul
(25) |
Aug
|
Sep
(2) |
Oct
(50) |
Nov
(89) |
Dec
(19) |
| 2004 |
Jan
(21) |
Feb
(9) |
Mar
(5) |
Apr
(6) |
May
(7) |
Jun
|
Jul
(4) |
Aug
|
Sep
(14) |
Oct
(24) |
Nov
(3) |
Dec
|
| 2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joe S. <joe...@us...> - 2003-04-07 19:18:58
|
On Thu, Dec 19, 2002 at 11:32:57AM -0600, Joe Stewart wrote:
>
> Mike Gifford and I have been discussing something that I've brought up
> before.
>
> Whether root_url should just be the relative path and not include the full
> url.
>
> In short to paraphrase Mike:
>
> "Would it just be easier to specify a host:
> $_PSL['http_host'] = $_ENV['HTTP_HOST'];
>
> & have the root url be somthing like this (if it's in a subdirectory of
> the site):
> $_PSL['rooturl'] = '/public_html';"
>
I played around with having config.php detect the basedir and rooturl
if it is not given in config.ini. This only left the db variables and
dir.include. I also played around with setting up variables for the
domain name and host name.
Worked OK except for the scripts in the admin directory. The rooturl
changed and screwed it all up. The rooturl has /admin appended. Then
adminurl appends /admin again. Anybody got any good ideas? I sure
don't.
Joe
// basedir -> complete filesystem path to the pages
if(empty($_PSL['basedir'])) {
$_PSL['basedir'] = getcwd();
}
...skip...
// rooturl -> The base URL for the PHPSlash site.
if(empty($_PSL['rooturl'])) {
$url = parse_url($_SERVER['REQUEST_URI']);
$pathinfo = pathinfo($url['path']);
$_PSL['rooturl'] = $pathinfo['dirname'];
}
// root.http_host -> The hostname of the PHPSlash site.
if(empty($_PSL['root.http_host'])) {
$_PSL['root.http_host'] = $_SERVER['HTTP_HOST'];
}
// root.domain -> The domain for the PHPSlash site.
if(empty($_PSL['root.domain'])) {
$server_parts = explode('.', $_PSL['root.http_host']);
$count = count($server_parts);
if($count > 1) {
$_PSL['root.domain.tld'] = $server_parts[$count-1];
$_PSL['root.domain.name'] = $server_parts[$count-2];
$_PSL['root.domain'] = $_PSL['root.domain.name'] .".". $_PSL['root.domain.tld'];
unset($server_parts[$count-1]);
unset($server_parts[$count-2]);
$_PSL['root.domain.host'] = implode('.', $server_parts);
} else {
// no tld - like localhost
$_PSL['root.domain.tld'] = '';
$_PSL['root.domain.name'] = $_PSL['root.http_host'];
$_PSL['root.domain'] = $_PSL['root.http_host'];
$_PSL['root.domain.host'] = '';
}
}
> I always just do the rooturl as shown above. There a few templates that I
> either have to add the host or {SITE_HOST}. This is how phpslash.org and
> phpslash.sf.net generate correct links on one installation.
>
> Are there still any browser considerations? I believe NS4 will look up
> the url again for full urls and not relative.
>
> Any input?
>
> Joe
>
|
|
From: Luis M <le...@ho...> - 2003-04-04 23:41:02
|
>Hello, > >With 0.7.1 being released maybe we can step back and plan some >direction. > >-=- > >A couple of gotchas recently: > >The css files aren't parsed so image urls are site specific. I do >prefer having regular css files that are served by the webserver and >cached by the browser over generating them with php. > It's really hard to test images from sites running on local developing machines because the IMAGE url tends to be absolute (if this is what you mean) in the phpslash releases that I have used. I agree that some work is needed to get the style sheets in better shape; maybe compliant with W3C standard (I know somebody fought this fight before... ). I get an awful lot of errors when trying to validate my site with the HTML or CSS validator at W3C.org. And while we are at it, why not just change the fileformat of all .gif to .png ;-) <snip> > >I've taken to using KDE for most of my development. It's really come >a long way ( the hardware has caught up to it too). > >A couple of things stand out - <snip> >quanta - This IDE is working well for me. When the kate editor that it >uses has the embedded vim, I'll probably use it much more. Anjuta is very nice (for me) since it uses an embeded scintilla-based editor (that does nice highlighting for lots of different languages).... I'm working on various projects on Anjuta only (though I have to go to the terminal for Vim's rescue from time to time) and have no complaints about it so far... ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Joe S. <joe...@us...> - 2003-04-04 18:25:50
|
On Fri, Feb 07, 2003 at 11:39:14AM +0000, Peter Cruickshank wrote: > Hi > At 17:00 06/02/03 -0500, you wrote: > >Hi all, > > > >I'm trying to develop a new skin off of the basic set. Thanks to Joe for > >making this easy! > <snip> > > >Is there a reason (like, older browsers don't like it) not to go to > >compliant CSS? There shouldn't be too much to change (I'll volunteer if > >nobody else wants to do it), and it'd be The Right Thing To Do. > > Your email has kicked me into action. > > FWIW, I've never heard anything about even NN4 not liking classes instead of ids.... > > I've posted a couple of skins I've playing around with to the Patches area - they use ids to divide the page into zones and then classes for everything else. Combining ids and classes is great because it means that blocks can look different depending where they are on the page, without defining new templates. > > You can see the skins in action at www.cruickshank.biz and www.cruickshank.biz/sl/ - there's still a couple of layout problems to sort out (eg the topic graphic element in Mozilla) and they're only designed to be readable by NN4, not pretty-looking - though I've moved the worst NN-breaking stuff into a separate stylesheet brought in by an @import. > > Feel free to use or modify. > Peter, I really like what you've done. Think we could come up with more unique names before committing to cvs? I used cruickshank.biz on the demo at phpslash.org. The default topic images and the " Also under" text really are the only things I see messed up. Do you have any updates to this? thanks, Joe > Cheers > > Peter > > > ----------------------------- > Peter Cruickshank > Tel: +44 7092 086 881 > email: pe...@kr... > > |
|
From: Joe S. <joe...@us...> - 2003-04-04 16:15:07
|
Hello,
With 0.7.1 being released maybe we can step back and plan some
direction.
-=-
A couple of gotchas recently:
The css files aren't parsed so image urls are site specific. I do
prefer having regular css files that are served by the webserver and
cached by the browser over generating them with php.
It would be useful to have a template to parse for modules similar to
the storyIndex.tpl. Instead of having to modify each module's output
to match the theme, maybe a moduleIndex.tpl that could provide it in
one place.
CSS only themes have a problem using a common footer template with two
and three column output. Evidently the designers of CSS layout didn't
really make it useful for having a consistent way to have footers with
different layouts. It is possible to put a {FOOTER} tag in the
index page to be able to set the location of the footer. I did find a
way to check if the {FOOTER} placeholder is used and if not echo
the output at the end as usual. Does this sound useful or too much
overhead?
-=-
A snapshot of the phpslash-skins cvs was released to play with. If
anyone wants to help manage a skins repository speak up. The current
ones are pretty rough - they basically give the look, but aren't
tested for completeness.
I would like someone to help with a design contest for the main
distribution template sets. If one we already have wins - good.
It still should get some interest and new designs out.
Xaraya just had a logo contest and Midgard is having a contest for
their website redesign now.
-=-
Hopefully I can get the phpslash-modules cvs synced up with 0.7.1.
-=-
I've taken to using KDE for most of my development. It's really come
a long way ( the hardware has caught up to it too).
A couple of things stand out -
kompare - a visual diff. Really nice display of diff output. I start
it from the command line. As much as I'm impressed by gvim's diff
mode, I use this more.
vimpart - embedded vim in kde editor components.
quanta - This IDE is working well for me. When the kate editor that it
uses has the embedded vim, I'll probably use it much more.
later,
Joe
|
|
From: Joe S. <joe...@us...> - 2003-04-02 22:24:49
|
On Wed, Apr 02, 2003 at 02:24:01PM -0800, nathan r. hruby wrote:
> >
> > getName, getRealName and getAuthor
> >
>
> Do we want to say that these are reccommended methods of getting this
> data, and just ignore $auth? altogether or is it still preferred to just
> get what you need from $auth->{name,dname,emailfoo}
>
Not yet.
We use the author methods to load the $auth->{name,dname,emailfoo}.
We currently don't have a method to call that gets the
auth->{name,dname,emailfoo} data, making the query involved and
setting the session variables if needed.
gotta go
|
|
From: nathan r. h. <na...@ds...> - 2003-04-02 22:10:11
|
On Wed, 2 Apr 2003, Joe Stewart wrote:
> On Wed, Apr 02, 2003 at 01:19:28PM -0800, nathan r. hruby wrote:
> >
> > I think this is me being dyslexic. IIRC, in phplib $auth->nobody was a
> > boolean shorthand to determine if the current $auth object is
> > authenticated as a user, or if we're operating as a default user and
> > looking through the auth.inc class seems to beack this up. this may have
> > chnaged recently, at this point Joe, youd know better than I.
> >
>
> It is a boolean to set if nobody access is allowed.
>
> false or unset - login is required.
> true - public access is allowed.
>
Hurm.. I will go back and re-read auth class - somthing isn't jiving in my
head but that makes sense.
> > So the correct method for determinig the user is still to check
> > $auth->['uid'] == 'nobody'
>
> Well it would have worked before :)
>
> Now the uid of nobody is changed to that of the phpSlash nobody user.
> This is done to have a easy method to control the name and access of
> the public user.
>
Ah.. that does make sense.
> The way we're checking for login status in phpSlash is if they have
> the "user" permission.
>
> perm->have_perm("user")
>
Wondered why we were doing this. Ok.
>
> > I though phplib did away with this a longtime
> > ago (maybe now we're supposed to check $auth->['username']?)
> >
>
> no.
>
You're so mean to me ;)
> If it helps -
>
> There are a couple of methods in Author.class that can get author info
> from the uid.
>
> getName, getRealName and getAuthor
>
Do we want to say that these are reccommended methods of getting this
data, and just ignore $auth? altogether or is it still preferred to just
get what you need from $auth->{name,dname,emailfoo}
> > Again, me being kinda stupid.
> >
>
> nope. It's about three things happening right together.
>
Hey! You got permissions in my auth class!
Hey! You got auth in my permissions class!
Heeeey!
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: Joe S. <joe...@us...> - 2003-04-02 22:01:35
|
On Wed, Apr 02, 2003 at 01:19:28PM -0800, nathan r. hruby wrote:
> On Wed, 2 Apr 2003, Joe Stewart wrote:
>
> > On Tue, Apr 01, 2003 at 08:44:27PM -0800, nathan r. hruby wrote:
> > >
> > > This is really dumb. I have a site, I login as god (with 'root'perm) or
> > > as my admin user will all but root and nobody set. $auth->nobody is
> > > always 1. Clues?
> > >
> >
> > slashAuthCR.class:
> >
> > var $nobody = true;
> >
> >
> > > I don't see anyplace where's is explicitly unset, so I;m wondering if it;s
> > > not jsut carrying over from the session.
> > >
> >
> > auth->nobody allows public access.
> >
> > The "nobody" user is used after someone is identified. Then what
> > public access is allowed can be changed by the "nobody" group's
> > permissions.
> >
>
> I think this is me being dyslexic. IIRC, in phplib $auth->nobody was a
> boolean shorthand to determine if the current $auth object is
> authenticated as a user, or if we're operating as a default user and
> looking through the auth.inc class seems to beack this up. this may have
> chnaged recently, at this point Joe, youd know better than I.
>
It is a boolean to set if nobody access is allowed.
false or unset - login is required.
true - public access is allowed.
> So the correct method for determinig the user is still to check
> $auth->['uid'] == 'nobody'
Well it would have worked before :)
Now the uid of nobody is changed to that of the phpSlash nobody user.
This is done to have a easy method to control the name and access of
the public user.
The way we're checking for login status in phpSlash is if they have
the "user" permission.
perm->have_perm("user")
> I though phplib did away with this a longtime
> ago (maybe now we're supposed to check $auth->['username']?)
>
no.
If it helps -
There are a couple of methods in Author.class that can get author info
from the uid.
getName, getRealName and getAuthor
> Again, me being kinda stupid.
>
nope. It's about three things happening right together.
Joe
> -n
> --
> ------
> nathan hruby
> na...@ds...
> ------
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel
>
|
|
From: nathan r. h. <na...@ds...> - 2003-04-02 21:05:37
|
On Wed, 2 Apr 2003, Joe Stewart wrote: > On Tue, Apr 01, 2003 at 08:44:27PM -0800, nathan r. hruby wrote: > > > > This is really dumb. I have a site, I login as god (with 'root'perm) or > > as my admin user will all but root and nobody set. $auth->nobody is > > always 1. Clues? > > > > slashAuthCR.class: > > var $nobody = true; > > > > I don't see anyplace where's is explicitly unset, so I;m wondering if it;s > > not jsut carrying over from the session. > > > > auth->nobody allows public access. > > The "nobody" user is used after someone is identified. Then what > public access is allowed can be changed by the "nobody" group's > permissions. > I think this is me being dyslexic. IIRC, in phplib $auth->nobody was a boolean shorthand to determine if the current $auth object is authenticated as a user, or if we're operating as a default user and looking through the auth.inc class seems to beack this up. this may have chnaged recently, at this point Joe, youd know better than I. So the correct method for determinig the user is still to check $auth->['uid'] == 'nobody' I though phplib did away with this a longtime ago (maybe now we're supposed to check $auth->['username']?) Again, me being kinda stupid. -n -- ------ nathan hruby na...@ds... ------ |
|
From: Joe S. <joe...@us...> - 2003-04-02 14:26:10
|
On Tue, Apr 01, 2003 at 08:44:27PM -0800, nathan r. hruby wrote: > > This is really dumb. I have a site, I login as god (with 'root'perm) or > as my admin user will all but root and nobody set. $auth->nobody is > always 1. Clues? > slashAuthCR.class: var $nobody = true; > I don't see anyplace where's is explicitly unset, so I;m wondering if it;s > not jsut carrying over from the session. > auth->nobody allows public access. The "nobody" user is used after someone is identified. Then what public access is allowed can be changed by the "nobody" group's permissions. What happens is: The session is created. The auth starts. If the uid is "nobody" the uid is changed to the "nobody" user's uid and perms. It is possible at this point if the "remember me" option was used, a cookie is read and the uid is changed to the particular users's uid. does this help? thanks, Joe > -n > > > -- > ------ > nathan hruby > na...@ds... > ------ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel > |
|
From: nathan r. h. <na...@ds...> - 2003-04-02 04:30:39
|
This is really dumb. I have a site, I login as god (with 'root'perm) or as my admin user will all but root and nobody set. $auth->nobody is always 1. Clues? I don't see anyplace where's is explicitly unset, so I;m wondering if it;s not jsut carrying over from the session. -n -- ------ nathan hruby na...@ds... ------ |
|
From: Luis M <le...@ho...> - 2003-03-28 23:42:10
|
>Is anyone going to PHPCON East in NYC in April? I figured it's not going >to get much closer to me, so I'll be there for the two session days (none >of the tutorials). Maybe we can do a WiP or something, or just get >together and drink, I mean, chat. Tempting uh! especially for us who live in NYC. And of course after seeing this presentation about PHP 5: http://talks.php.net/show/php5intro/1 ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
|
From: Matthew L. <lei...@ma...> - 2003-03-28 03:41:09
|
Hi guys, Is anyone going to PHPCON East in NYC in April? I figured it's not going to get much closer to me, so I'll be there for the two session days (none of the tutorials). Maybe we can do a WiP or something, or just get together and drink, I mean, chat. --Matt ---------------------------------------------------------------- Matthew Leingang http://www.math.rutgers.edu/ Rutgers University lei...@ma... Department of Mathematics "This signature needs no quote." |
|
From: Joe S. <joe...@us...> - 2003-03-27 20:11:58
|
Hey folks,
0.7.1RC1 has been released for testing. Mostly bugfixes but there are a
few nice things thrown in too.
-=-=-
The section argument to getHeader was changed to an array. This array
argument is then parsed so that the array key is a template placeholder
substituted to contain the array value. In other words, slashTemplate
could contain:
{KEY1}
{KEY2}, etc. which when output would be:
value1
value2
This is an easy way to add the output of phpAdsNew.
-=-=-
You should be able to create groups of users that have limited access to
post stories only to certain sections.
If the user is editing a block or story that is also assigned to a section
they do not have access to, the contents can be changed, but not deleted
entirely.
-=-=-
Please test this RC so that we can move on.
thanks,
Joe
|
|
From: Mike G. <mi...@op...> - 2003-03-19 20:50:22
|
Hello Again,
<just snipping some stuff>
On Tue, 2003-03-18 at 22:39, Luis M wrote:
> >This is just my 2c on this issue. But I would think that the easiest
> >thing from the user perspective would be to:
> >1) check to see if the config.ini.php has write permissions
> >a) if so write to directly to the file (with confirmation)
> >if(is_writeable{config.ini.php})
> >
> >b) if not send the config to the user via:
> >header ("Content-type: application/txt\nContent-Disposition: inline;
> >filename='config.ini.php'");
> >
> >Think that this is valid, I had it as
> >application/csv\nContent-Disposition previously.
> I will experiment using different headers on different browsers to see what
> happens, but I know it will work for all browsers (even lynx) if one only
> allows the file to be presented as HTML and then let the users save it
> locally.
Adding browser detection for those odd browsers like lynx is an
interesting and admirable idea. Can you edit a phpSlash site with
Lynx? That would be pretty funky. However most folks who use lynx and
would also be setting up phpSlash would probably be pretty hard core
folks and pretty darn familiar with vi.
But for folks with visual disabilities, would be interesting to see how
little one could get away with..
> Joe didn't want to deal with writing the file to the server because
> of permission issues and just more questions to the FAQ from newbies.
> My idea of a setup.php is to be as easy as possible on newbies, hardcore
> phpslash users will go their way with their vim's or emacs. Of course, if we
> get the setup.php right, then core users could run the initial setup.ini.php
> thru the setup.php first (just for convenience) and then if needed edit it
> later by hand (to add extra features).
Security... Seems like such a drag until someone busts in and destroys
a site you've spent months working on.
However, hopefully phpSlash will start to attract folks who are looking
to 'upgrade' from phpNuke. Would be good if an install were as simple
as possible to get off the ground. Securing it after that so that
no-one can do any damage is the trick and I can't say that I know enough
about this.. Just keep looking for a crisper solution to move us closer
to a fool proof install.
> > > Save this resulting file as Plain Text, and
> > > give it a valid name "setup.ini". Of course the user will put this file
> > > OUTSIDE of the web server space, thus there is no need to add the ";
> ><?php
> > > die() " lines ... but, to be safe, we could add those lines regardless.
> >For security, the config.php could check to see that setup.php has been
> >deleted before allowing the user to log in. This way they could see
> >that its working and then delete it. either or both of these could be
> >used to add security to make sure someone else can't edit the config
> >afterwards.
> >if(is_file(setup.php))
> >if(is_writeable{config.ini.php})
> Well, setup.php is harmless if it only allows the config-dist.ini.php file
> to be used. It's only when we start allowing users to pass arguments with
> their own files that the problems start getting complicated. At that point
> we might just check first that there is a valid instalation of phpslash
> (checking if setup.php is loadable and using the login stuff to get the
> users to login with a valid username/password)... but that's a lot more than
> what is needed... we only need a simple way to get phpslash setup the first
> time -- with newbies and Mac users in mind :-)
Agreed.. Folks who are upgrading are already more committed to the code
than someone downloading it for the first time to check it out.
> > > The reason I did this is because sending a header to the browser that
> >this
> > > file is type text/ini or text/whatever, might cause the browser to
> >display
> > > the file anyway. So the "save file" would not do what it's supposed to
> >do.
> >
> >True.. But its also another step for a user to go through.. What
> >browsers would mix up the header?
> :-) it's just a matter of testing browsers to see what works for all :-) or
> adding an extra step and skip the testing part...
Both take time....
> > > I added other minor enhancements. I plan to allow the users to "preview"
> >the
> > > file and possibly feed it back to the same form to be re-edited... but
> > > that's in the future.
> >Only so much time.. Does the script populate the database or just write
> >the config.ini.php for you?
> it might be nice to get to that point, but for now is just to get a .ini . I
> think that populating the database will get us in a whole different mess:
> users will have to definitely remove the setup.php file from their
> instalations when finished, users will have to provide the .sql file they
> want/need according to whether they are upgrading or are setting phpslash
> for the first time, etc...
Yes... It's certainly more complicated.. Ideally there'd be some way
to just grab a piece of the phpMyAdmin script so that after creating the
ini that the script check that it has proper permissions to the db,
checks to see if phpSlash tables exist to upgrade, and if there aren't
tables there to upgrade, grabs the slash-all.sql and populates the
database (much like it would if you just cut & paste it into the
phpMyAdmin text area box).
Unfortunately when I tried to do this with phpMyAdmin, I found the code
wasn't modular enough for me to do this very easily....
But that's a ways off I suspect.
> talking about upgrading, it would be nice to pick the settings from the past
> config.php3 files for those users... but then again, that's another big mess
> :-) i'm just trying to keep it simple.
Probably best.. Get something working that everyone can agree on..
Then if there's time & interest make it better..
Mike
--
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca
|
|
From: Mike G. <mi...@op...> - 2003-03-19 20:18:03
|
Hi Luis, I should have thought about using wget... Also interesting to know about the .bz2 & not requiring mime types. I was using Galeon I think so not sure why it would have barfed on the .bz2.. I would have thought that would be just fine. Took a look at the setup.php file. It looks like it will be pretty easy to maintain as the code develops. Looks like the start of a very nice/flexible script. Mike On Tue, 2003-03-18 at 22:43, Luis M wrote: > <snip> > > > Script compressed: > > > http://www.latinomixed.com/setup.php.bz2 > > > >I suspect that your server isn't set to recognize .bz2's mime types. I > >could be way wrong on that, but I couldn't download it. > > > <snip> > > Just for clarification, from /etc/mime.types: > < quote > > > # Note: Compression schemes like "gzip", "bzip", and "compress" are not > # actually "mime-types". They are "encodings" and hence must _not_ have > # entries in this file to map their extensions. The "mime-type" of an > # encoded file refers to the type of data that has been encoded, not the > # type of the encoding. > > < end quote > > > I suspect that has to be how the individual browsers deal with these > filetypes... in any case, "wget" works nicely. > > > ----)(----- > Luis Mondesi > System Administrator > LatinoMixed.com > > le...@ho... > > "...The Mac does this so smoothly, it feels like an extension of your mind." > - Paula Speer, MacWorld Magazine 2003-04 > > Public signature: http://www.latinomixed.com/lems1/public-a.asc > > _________________________________________________________________ > MSN Messenger : discutez en direct avec vos amis ! > http://www.msn.fr/msger/default.asp -- Mike Gifford <mi...@op...> OpenConcept Consulting http://www.openconcept.ca |
|
From: Luis M <le...@ho...> - 2003-03-19 03:43:47
|
<snip> > > Script compressed: > > http://www.latinomixed.com/setup.php.bz2 > >I suspect that your server isn't set to recognize .bz2's mime types. I >could be way wrong on that, but I couldn't download it. > <snip> Just for clarification, from /etc/mime.types: < quote > # Note: Compression schemes like "gzip", "bzip", and "compress" are not # actually "mime-types". They are "encodings" and hence must _not_ have # entries in this file to map their extensions. The "mime-type" of an # encoded file refers to the type of data that has been encoded, not the # type of the encoding. < end quote > I suspect that has to be how the individual browsers deal with these filetypes... in any case, "wget" works nicely. ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
|
From: Luis M <le...@ho...> - 2003-03-19 03:39:48
|
Hello Mike, >On Mon, 2003-03-17 at 23:28, Luis M wrote: > > >Is this posted somewhere to take a look at? mailman's digest garbled > > >the attachment pretty badly so I'd need to download it from somewhere > > >else. > > Working version (revised): > > http://www.latinomixed.com/setup.php > >This looked nice. Might be good to have the setup.php guess the right >answers to the location, but other than that it looks quite hopeful. that's an idea... I'll keep it in mind. > > > Script compressed: > > http://www.latinomixed.com/setup.php.bz2 > >I suspect that your server isn't set to recognize .bz2's mime types. I >could be way wrong on that, but I couldn't download it. > Using wget works for me here. it seems to crash my mozilla (v1.4a): wget http://www.latinomixed.com/setup.php.bz2 I also put the file in this ftp url: ftp://ftp.latinomixed.com/downloads/setup.php.bz2 (use PORT and not PASSIVE). > > I figured a better way to parse the file. It now just submit the data to > > itself and then the user will have to save the output using the "Save >As..." > > command from the browser window. > >This is just my 2c on this issue. But I would think that the easiest >thing from the user perspective would be to: >1) check to see if the config.ini.php has write permissions >a) if so write to directly to the file (with confirmation) >if(is_writeable{config.ini.php}) > >b) if not send the config to the user via: >header ("Content-type: application/txt\nContent-Disposition: inline; >filename='config.ini.php'"); > >Think that this is valid, I had it as >application/csv\nContent-Disposition previously. I will experiment using different headers on different browsers to see what happens, but I know it will work for all browsers (even lynx) if one only allows the file to be presented as HTML and then let the users save it locally. Joe didn't want to deal with writing the file to the server because of permission issues and just more questions to the FAQ from newbies. My idea of a setup.php is to be as easy as possible on newbies, hardcore phpslash users will go their way with their vim's or emacs. Of course, if we get the setup.php right, then core users could run the initial setup.ini.php thru the setup.php first (just for convenience) and then if needed edit it later by hand (to add extra features). > > > Save this resulting file as Plain Text, and > > give it a valid name "setup.ini". Of course the user will put this file > > OUTSIDE of the web server space, thus there is no need to add the "; ><?php > > die() " lines ... but, to be safe, we could add those lines regardless. > >For security, the config.php could check to see that setup.php has been >deleted before allowing the user to log in. This way they could see >that its working and then delete it. either or both of these could be >used to add security to make sure someone else can't edit the config >afterwards. >if(is_file(setup.php)) >if(is_writeable{config.ini.php}) Well, setup.php is harmless if it only allows the config-dist.ini.php file to be used. It's only when we start allowing users to pass arguments with their own files that the problems start getting complicated. At that point we might just check first that there is a valid instalation of phpslash (checking if setup.php is loadable and using the login stuff to get the users to login with a valid username/password)... but that's a lot more than what is needed... we only need a simple way to get phpslash setup the first time -- with newbies and Mac users in mind :-) > > The reason I did this is because sending a header to the browser that >this > > file is type text/ini or text/whatever, might cause the browser to >display > > the file anyway. So the "save file" would not do what it's supposed to >do. > >True.. But its also another step for a user to go through.. What >browsers would mix up the header? :-) it's just a matter of testing browsers to see what works for all :-) or adding an extra step and skip the testing part... > > > I added other minor enhancements. I plan to allow the users to "preview" >the > > file and possibly feed it back to the same form to be re-edited... but > > that's in the future. > >Only so much time.. Does the script populate the database or just write >the config.ini.php for you? > it might be nice to get to that point, but for now is just to get a .ini . I think that populating the database will get us in a whole different mess: users will have to definitely remove the setup.php file from their instalations when finished, users will have to provide the .sql file they want/need according to whether they are upgrading or are setting phpslash for the first time, etc... talking about upgrading, it would be nice to pick the settings from the past config.php3 files for those users... but then again, that's another big mess :-) i'm just trying to keep it simple. ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
|
From: Mike G. <mi...@op...> - 2003-03-18 15:47:58
|
Hi Luis, On Mon, 2003-03-17 at 23:28, Luis M wrote: > >Is this posted somewhere to take a look at? mailman's digest garbled > >the attachment pretty badly so I'd need to download it from somewhere > >else. > Working version (revised): > http://www.latinomixed.com/setup.php This looked nice. Might be good to have the setup.php guess the right answers to the location, but other than that it looks quite hopeful. > Script compressed: > http://www.latinomixed.com/setup.php.bz2 I suspect that your server isn't set to recognize .bz2's mime types. I could be way wrong on that, but I couldn't download it. > I figured a better way to parse the file. It now just submit the data to > itself and then the user will have to save the output using the "Save As..." > command from the browser window. This is just my 2c on this issue. But I would think that the easiest thing from the user perspective would be to: 1) check to see if the config.ini.php has write permissions a) if so write to directly to the file (with confirmation) if(is_writeable{config.ini.php}) b) if not send the config to the user via: header ("Content-type: application/txt\nContent-Disposition: inline; filename='config.ini.php'"); Think that this is valid, I had it as application/csv\nContent-Disposition previously. > Save this resulting file as Plain Text, and > give it a valid name "setup.ini". Of course the user will put this file > OUTSIDE of the web server space, thus there is no need to add the "; <?php > die() " lines ... but, to be safe, we could add those lines regardless. For security, the config.php could check to see that setup.php has been deleted before allowing the user to log in. This way they could see that its working and then delete it. either or both of these could be used to add security to make sure someone else can't edit the config afterwards. if(is_file(setup.php)) if(is_writeable{config.ini.php}) > The reason I did this is because sending a header to the browser that this > file is type text/ini or text/whatever, might cause the browser to display > the file anyway. So the "save file" would not do what it's supposed to do. True.. But its also another step for a user to go through.. What browsers would mix up the header? > I added other minor enhancements. I plan to allow the users to "preview" the > file and possibly feed it back to the same form to be re-edited... but > that's in the future. Only so much time.. Does the script populate the database or just write the config.ini.php for you? Mike -- Mike Gifford <mi...@op...> OpenConcept Consulting http://www.openconcept.ca |
|
From: Luis M <le...@ho...> - 2003-03-18 04:28:30
|
>Hi Luis, > <snip> > > So far, I made sure the script picks every item and create all necessary > > form objects. It's still a little rough, but this is a start. It >validates > > against HTML 3.2, so it's compatible with all browsers that support W3C > > standards. > > > > There are some things needed, check the TODO comments on top. From a >design > > (pleasant?) point of view, I would like the comments to stand out (or >even > > be hidden) so that users only see them after passing the mouse on top or > > clicking on something... I'm still undecided about this little >details... > >Is this posted somewhere to take a look at? mailman's digest garbled >the attachment pretty badly so I'd need to download it from somewhere >else. Working version (revised): http://www.latinomixed.com/setup.php Script compressed: http://www.latinomixed.com/setup.php.bz2 I figured a better way to parse the file. It now just submit the data to itself and then the user will have to save the output using the "Save As..." command from the browser window. Save this resulting file as Plain Text, and give it a valid name "setup.ini". Of course the user will put this file OUTSIDE of the web server space, thus there is no need to add the "; <?php die() " lines ... but, to be safe, we could add those lines regardless. The reason I did this is because sending a header to the browser that this file is type text/ini or text/whatever, might cause the browser to display the file anyway. So the "save file" would not do what it's supposed to do. I added other minor enhancements. I plan to allow the users to "preview" the file and possibly feed it back to the same form to be re-edited... but that's in the future. > > > any help will be greatly appreciated... > >We can't offer any right now, but might be able to in a couple of >months. Would certainly want to be able to offer this with Back-End.. ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
|
From: Mike G. <mi...@op...> - 2003-03-17 22:56:23
|
Hi Luis, On Sun, 2003-03-16 at 15:14, php...@li... wrote: > Joe, as promised, here is the first revision of the setup.php file that > parses the config-dist.ini.php file from public_html directory. In case you > forgot, or for those that haven't been around in irc.freenode.net#phpslash, > this script will parse the .ini.php file and create widgets as it goes thru > the variables. At the end, it will allow the user to save the file to the > local computer (running the script from a browser) and the user will then > put this file wherever he/she wants it to be and change the config.php file > to point to this file. This looks very hopeful.. > So far, I made sure the script picks every item and create all necessary > form objects. It's still a little rough, but this is a start. It validates > against HTML 3.2, so it's compatible with all browsers that support W3C > standards. > > There are some things needed, check the TODO comments on top. From a design > (pleasant?) point of view, I would like the comments to stand out (or even > be hidden) so that users only see them after passing the mouse on top or > clicking on something... I'm still undecided about this little details... Is this posted somewhere to take a look at? mailman's digest garbled the attachment pretty badly so I'd need to download it from somewhere else. > any help will be greatly appreciated... We can't offer any right now, but might be able to in a couple of months. Would certainly want to be able to offer this with Back-End.. Mike -- Mike Gifford <mi...@op...> OpenConcept Consulting http://www.openconcept.ca |
|
From: Luis M <le...@ho...> - 2003-03-15 22:32:43
|
Hello all, Joe, as promised, here is the first revision of the setup.php file that parses the config-dist.ini.php file from public_html directory. In case you forgot, or for those that haven't been around in irc.freenode.net#phpslash, this script will parse the .ini.php file and create widgets as it goes thru the variables. At the end, it will allow the user to save the file to the local computer (running the script from a browser) and the user will then put this file wherever he/she wants it to be and change the config.php file to point to this file. So far, I made sure the script picks every item and create all necessary form objects. It's still a little rough, but this is a start. It validates against HTML 3.2, so it's compatible with all browsers that support W3C standards. There are some things needed, check the TODO comments on top. From a design (pleasant?) point of view, I would like the comments to stand out (or even be hidden) so that users only see them after passing the mouse on top or clicking on something... I'm still undecided about this little details... any help will be greatly appreciated... ----)(----- Luis Mondesi System Administrator/Web developer LatinoMixed.com le...@ho... "Black holes are where God divided by zero" - Steven Wright Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Luis M <le...@ho...> - 2003-03-14 02:37:22
|
I just noticed that some search engines (FAST-WebCrawler/3.6 for now) are digging into the "/templates" portion of the URL's that use phpslash. I have no idea why, but, it was a good thing because I realized that all sites using phpslash have the "/templates" open for people to browse thru them. This is not in any way a security hole of any kind, unless of course you don't like people to be able to copy your template files :-). In any case, to avoid this, setup a ".htaccess" file in the "templates" directory with the following lines: order deny,allow deny from all allow from 127.0.0.1 That will deter everybody from browsin thru your templates. To get an idea of what browsing the templates means go to: http://www.phpslash.org/templates/en/ It's just ugly... ----)(----- Luis Mondesi System Administrator/Web developer LatinoMixed.com le...@ho... "Black holes are where God divided by zero" - Steven Wright Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
|
From: Joe S. <joe...@us...> - 2003-03-12 16:50:02
|
Okay I setup two cvs sandboxes so we can play around: phpslash-dev - contains the 0.7 code moved around. The changes have mostly been limited to: loading the modules, changed file locations, and php extensions. phpslash-skins - a skins repository. Currently contains the funkatronic skin used on phpslash.org, a rough no-tables skin based on The Layout Reservoir at bluerobot.com, and a set of skins ported from phpWebSite 0.9. None are really polished and complete. Joe |
|
From: nathan r. h. <na...@ds...> - 2003-03-11 02:12:23
|
On Mon, 10 Mar 2003, Matthew Leingang wrote: > On Mon, 10 Mar 2003, Joe Stewart wrote: > > > How about if I setup this code in the "phpslash" cvs tree to get us > > started? It's pretty well borked at the moment anyway. > > > > Joe > > Remind the rookie...what's in the phpslash tree? My own inclination is to > create a new directory rather than overwrite something old, just because > space is cheap (isn't it?) and you never know. But that might just be a > reflection of my own neuroses than any actual wisdom... > phpslash is the original 0.5x CVS tree imported from netuse.de back in the day. At one point I tried to import the 0.6 tree into it completely fsck'ed it, and have not fixed it yet. that said, it;d be nice to have, perhaps we should add a new module 'playground' or 'modules-dev'. -n -- ------ nathan hruby na...@ds... ------ |
|
From: Matthew L. <lei...@ma...> - 2003-03-10 16:38:46
|
On Mon, 10 Mar 2003, Joe Stewart wrote: > How about if I setup this code in the "phpslash" cvs tree to get us > started? It's pretty well borked at the moment anyway. > > Joe Remind the rookie...what's in the phpslash tree? My own inclination is to create a new directory rather than overwrite something old, just because space is cheap (isn't it?) and you never know. But that might just be a reflection of my own neuroses than any actual wisdom... -- ---------------------------------------------------------------- Matthew Leingang http://www.math.rutgers.edu/ Rutgers University lei...@ma... Department of Mathematics "This signature needs no quote." |
2 messages has been excluded from this view by a project administrator.
