phpslash-devel Mailing List for phpSlash (Page 14)
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-28 13:40:24
|
On Fri, Apr 25, 2003 at 05:31:26PM -0700, Aric Caley wrote:
> Just wanted to chime in that I think this is A Good Idea.
>
> Take it all the way to index.php.
>
> I'd also like to see it work without the ? and &. For example:
>
> index.php/story/admin
> index.php/backend/rss
>
> The first part ('story') could be always interpreted as the module name, the
> second part the page. After that can be interpreted any way the module
> chooses.
>
In the past I have done this with mod_rewrite rules for the section
index pages, article pages and search results.
Most of the changes could be made in the templates. How true that
is now days, I don't know.
> This makes search engines happier. Looks purty too.
>
Since google spiders with ? and & fine it is less of an issue. The
other SE's are catching up. Path like arguments are definitely
better looking for email and conveying to someone else.
Joe
|
|
From: Aric C. <php...@pe...> - 2003-04-26 00:31:36
|
Just wanted to chime in that I think this is A Good Idea.
Take it all the way to index.php.
I'd also like to see it work without the ? and &. For example:
index.php/story/admin
index.php/backend/rss
The first part ('story') could be always interpreted as the module name, the
second part the page. After that can be interpreted any way the module
chooses.
This makes search engines happier. Looks purty too.
----- Original Message -----
From: "Joe Stewart" <joe...@us...>
To: "PHPSlash Developers List" <php...@li...>
Sent: Wednesday, April 23, 2003 9:22 AM
Subject: [Phpslash-devel] How many page scripts do we need?
>
> With the -dev modules, you really don't need all the different
> scripts. GET variables can trigger the module and page to use.
>
> For instance they could be called something like:
>
> index.php?module=Story&page=admin
>
> How far should this go? All the way to only index.php? and
> backend.php?
>
> The entire admin/ directory can go.
>
> I'd like to eventually replace the about page with either a block or
> story. It's pretty bad now that it can't be modified through the admin
> interface.
>
> Joe
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel
>
|
|
From: Joe S. <joe...@us...> - 2003-04-23 16:09:56
|
With the -dev modules, you really don't need all the different scripts. GET variables can trigger the module and page to use. For instance they could be called something like: index.php?module=Story&page=admin How far should this go? All the way to only index.php? and backend.php? The entire admin/ directory can go. I'd like to eventually replace the about page with either a block or story. It's pretty bad now that it can't be modified through the admin interface. Joe |
|
From: Joe S. <joe...@us...> - 2003-04-23 16:02:00
|
The actions taken when the block expire time equal zero has changed. When the block is parsed, the parsed data is compared to the cached data, and if different, then copied. Then if the expire time is greater than zero, the data is written to the db. This routine is only called I think this is more what everyone thinks should happen. If no cache time is given, don't use a cache. Joe |
|
From: Joe S. <joe...@us...> - 2003-04-18 16:09:05
|
On Fri, Apr 18, 2003 at 11:59:45AM -0400, Luis M wrote: > > >We've been using styles/skinname.css for theme styles. The templates and > >images > >use a separate directory. I propose using this for styles also. They > >would be > >styles/skinname/*.css. > > > >For many skins it might be overdone to have a separate directory for one > >file. > >But I think there are benefits for ease of future package > >installation/removal > >and porting of themes. As more themes have multiple css files for > >printing, etc. it will be cleaner. > > > >later, > > > >Joe > > If you are going to include style sheet files for e/a theme or for the > themes that need them, then it would be better to just have those themes > somewhere else inside the theme's own directory. > say "/" is the root for the PHPslash installation > /styles <--- styles for site > /tempates/en/basic > /tempates/en/basicurves > /templates/en/basicurves/styles.css <--- would be a nice way to do it > > in other words, the file will always be found inside the directory for a > given skin, or the skin.ini file can point to that file with a variable. > The stylesheet and images are served by the webserver. The templates are included and used by php. The don't have any need to be in the webroot. > I just think that it's easier to just drop a skin directory inside the > /templates/$LANG of choice without having to worry about putting other files > somewhere in the site. > true. > My .02 contrib... > > ----)(----- > 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 > > |
|
From: Luis M <le...@ho...> - 2003-04-18 15:59:51
|
>We've been using styles/skinname.css for theme styles. The templates and >images >use a separate directory. I propose using this for styles also. They >would be >styles/skinname/*.css. > >For many skins it might be overdone to have a separate directory for one >file. >But I think there are benefits for ease of future package >installation/removal >and porting of themes. As more themes have multiple css files for >printing, etc. it will be cleaner. > >later, > >Joe If you are going to include style sheet files for e/a theme or for the themes that need them, then it would be better to just have those themes somewhere else inside the theme's own directory. say "/" is the root for the PHPslash installation /styles <--- styles for site /tempates/en/basic /tempates/en/basicurves /templates/en/basicurves/styles.css <--- would be a nice way to do it in other words, the file will always be found inside the directory for a given skin, or the skin.ini file can point to that file with a variable. I just think that it's easier to just drop a skin directory inside the /templates/$LANG of choice without having to worry about putting other files somewhere in the site. My .02 contrib... ----)(----- 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-18 15:48:13
|
We've been using styles/skinname.css for theme styles. The templates and images use a separate directory. I propose using this for styles also. They would be styles/skinname/*.css. For many skins it might be overdone to have a separate directory for one file. But I think there are benefits for ease of future package installation/removal and porting of themes. As more themes have multiple css files for printing, etc. it will be cleaner. later, Joe |
|
From: Mike G. <mi...@op...> - 2003-04-18 03:47:48
|
Howdy folks, Just wanted to throw in a voice from the BE team to say that this development sounds very hopeful.. I think this could be done without adding a lot of confusion to how it all works for the user.. One thing which we've been talking about within BE is the ability to position blocks and edit blocks using a more intuitive process. If you've got block permissions, you should be able to move a block up or down or into another column simply by clicking on up/down or left/right arrows that appear within the block. Might also be handy to have an admin link within the block to refresh the cache & edit the block. I think the block caching confuses some folks.. We haven't had the chance to develop this yet, but think it would make it easier for folks to administer.. Mike -- Mike Gifford, OpenConcept Consulting, http://www.openconcept.ca Open Source Web Applications for Social Change. Featured Campaign - Rooting Out Evil! - http://rootingoutevil.org Give me the splendid silent sun with all his beams full-dazzling. - W Whitman |
|
From: Joe S. <joe...@us...> - 2003-04-18 00:22:21
|
On Wed, Apr 16, 2003 at 09:13:57AM -0500, Joe Stewart wrote: > > What if we used blocks to display pretty much everything. > > Just throwing this out. Some thought has gone into this, but > nothing thorough and no testing. > Now the -dev cvs has the new block types committed for testing. It's pretty buggy and not complete at all. Initial impressions - - The increased flexibility from the web interface may lead to some confusion and page screwups. - I'm accustomed to modifying the scripts some to modify the pages, so it may take some time to get used to this. - There seems to be a little hit to the response time. Not significant and caching the TopicBar block pretty much negates it. I'm sure we can find some ways to optimize the blocks. later, Joe |
|
From: nathan r. h. <na...@ds...> - 2003-04-17 23:41:04
|
On Thu, 17 Apr 2003, Joe Stewart wrote: > On Wed, Apr 16, 2003 at 04:37:59PM -0700, nathan r. hruby wrote: > > Okay, initial tests look mostly good. I'll try to get them committed > to the -dev cvs. > Sweet! > I'm curious now about how you pull the blocks. Are you using psl > functions or pulling from the db externally? > psl functions.. how much / which ones depends on what I'm doing. In a few places I just include block_i and then do a getAll...() (http://www.drma.uga.edu/) for a section to add RSS Feeds, and articles of topics. I have one page that is basically the index, but with some things moved around and a few extra block calls. (gdl.drama.uga.edu) Don't laugh at the way the site looks, It needed changing over the summer becasue lots of people were pissed off at the last version and the grad students taksed with the revamp never got it off the ground after 9 months, so I just made a 'path-of-least-resistance' look. This is actually really good timing as I need to revamp the website over the summer and I'd liek to use phpslash and/or backend more for dealing with the content as opposed to the crappy workflow we have now. Being able to drop blocks anywhere with any psl content would be, keen. -n -- ------ nathan hruby na...@ds... ------ |
|
From: Matt \TrollBoy\ W. <tro...@sh...> - 2003-04-17 22:01:47
|
> > Just realized a downside. When you add new sections, they wouldn't > > have all the page components automatically. Why just a section called "all"... which will be everything... Matt "TrollBoy" Wiseman Webmaster: Shoggoth.net Site Designer: phpslash.org The oldest and strongest emotion of mankind is fear, and the oldest and strongest kind of fear is fear of the unknown. -H.P. Lovecraft --------------------------------------------------------- Please do not resell my e-mail address to anyone or send me unsolicited e-mail --------------------------------------------------------- |
|
From: Joe S. <joe...@us...> - 2003-04-17 13:30:53
|
On Wed, Apr 16, 2003 at 04:37:59PM -0700, nathan r. hruby wrote: > On Wed, 16 Apr 2003, Joe Stewart wrote: > > > > > What if we used blocks to display pretty much everything. > > > > I like it! I've started pulling blocks from psl and placing them on lots > of other non-psl pages in various portions our sites, and the ability to > have any contetn nealy packaged and easily availible would be super cool. > Okay, initial tests look mostly good. I'll try to get them committed to the -dev cvs. I'm curious now about how you pull the blocks. Are you using psl functions or pulling from the db externally? Joe > -n > > -- > ------ > nathan hruby > na...@ds... > ------ > |
|
From: nathan r. h. <na...@ds...> - 2003-04-16 23:23:03
|
On Wed, 16 Apr 2003, Joe Stewart wrote: > > What if we used blocks to display pretty much everything. > I like it! I've started pulling blocks from psl and placing them on lots of other non-psl pages in various portions our sites, and the ability to have any contetn nealy packaged and easily availible would be super cool. -n -- ------ nathan hruby na...@ds... ------ |
|
From: Joe S. <joe...@us...> - 2003-04-16 15:40:45
|
On Wed, Apr 16, 2003 at 11:22:40AM -0400, Matthew Leingang wrote: > Joe Stewart wrote: > <snip> > > > Just realized a downside. When you add new sections, they wouldn't > > have all the page components automatically. > > Right...unless you build that into the saveSection function? > yes. For example it would be easy enough to add a check box to assign the same blocks as the home page. > > -- > ---------------------------------------------------------------- > Matthew Leingang http://www.math.rutgers.edu/~leingang > Rutgers University lei...@ma... > Department of Mathematics "This signature needs no quote." > > |
|
From: Matthew L. <lei...@ma...> - 2003-04-16 15:23:21
|
Joe Stewart wrote: > What if we used blocks to display pretty much everything. I thought about this once. A block is something that take data in the database and converts it to "nice, fluffy HTML." That describes just about every module we have in use. Definitely worth thinking about. <snip> > Just realized a downside. When you add new sections, they wouldn't > have all the page components automatically. Right...unless you build that into the saveSection function? -- ---------------------------------------------------------------- Matthew Leingang http://www.math.rutgers.edu/~leingang Rutgers University lei...@ma... Department of Mathematics "This signature needs no quote." |
|
From: Joe S. <joe...@us...> - 2003-04-16 14:24:11
|
On Tue, Apr 15, 2003 at 08:31:13PM -0400, Luis M wrote:
>
> MOVED TO -devel ...
>
> <snip>
>
> > > >There is a typo:
> > > >
> > > >45 error_reporting(E_ALL,~E_WARN);
> > > >
> > > >should be something like (untested):
> > > >
> > > >error_reporting(E_ALL & ~E_WARN);
> > >
> > > Well, mails seems to be sent only to the first person on the list
> >anyway.
> > > Kind of strange, don't you think ? I'm no good with php, but I did run a
> > > test to see what's happening.
> > >
> > > If I run with the standard .71 MailingList.class, it stops after the
> >first
> > > address, but if I change the while ($this->db->next_record()) {
> > > ... } to only be:
> > > while ($this->db->next_record()) {
> > > $name = $this->db->Record["name"];
> > > $email = $this->db->Record["email"];
> > > $dayback = $this->db->Record["dayback"];
> > > $this->message .= "To: $email <$name>\n";
> > > } // End: while ( $this->db->next_record() )
> > >
> >
> >Well I know why it's broke now. What I'm not sure about is why it
> >ever worked.
>
> It never really worked, it only sent the first email and screwed the array
> as you proved below.
>
> >
> >if ( ($dayback != $tmpDay) && ( !($ary['override']) ) ) {
> > $ary['body'] = $this->build_body($ary,$dayback);
> >}
> >
> >The call to build_body uses the same db object. This screws up the
> >array for the current while loop.
> >
> >I got it to work by creating a new db object in build_body and using
> >it instead of this->db.
> >
> >Luis - can you work on this?
> >
>
> Yes, I need to fix this as I mention before. I'll work in the phpslash-dev
> module.
>
nathan - Can you look at this too? I don't see how it ever would have
worked.
> I wanted to ask you, what will happen to the phpslash-ft module? Are you
> planning to keep sync'ing all changes manually everytime something is proven
> to work in the -dev module? or you will use the "stable" phpslash module
> once phpslash-dev becomes stable enough to do a new release?
> In whichever case, I'll try to fix this and the poll bugs reported before in
> the phpslash-dev module.
>
I had hoped there would be more discussion whether the changes in the
phpslash-dev tree were the right direction and to nail down how we
wanted to proceed. The back-end development list had some recent comments:
http://sourceforge.net/mailarchive/message.php?msg_id=4302489
The sf.net archive isn't working too well at the moment. You might
have to go the the list archive to follow the thread.
I haven't been able to keep the -dev tree synced with the bugfixes in
the -ft tree.
So for the moment, keep working in the -ft tree.
thanks,
Joe
> <snip>
>
> ----)(-----
> 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
>
|
|
From: Joe S. <joe...@us...> - 2003-04-16 14:03:57
|
What if we used blocks to display pretty much everything.
Just throwing this out. Some thought has gone into this, but
nothing thorough and no testing.
What if we used blocks for:
header and footer - We could easily have section specific headers.
While this isn't a complete separate skin, it's what is needed for
many uses.
topicbar - Since this doesn't change often a block cache would keep
from querying the db. And if you don't use the topicbar, the class
wouldn't be loaded at all. However some skins don't really
have a place for it so we'd have to work around this.
navbar - We already have this. We could use the block to display the
top and bottom navbars also.
modules - If module output was diplayed with a block we could add
different titles easily or outline with a box for all module output,
rather than having to change each module's templates. For stories we
could move the location and number of stories on a page easily.
The index page only has to call the block object to get all data
needed. We might even be able to make use of a page type block.
We might also be able to use something like a template block type.
It's only task would be to parse the named template into a block.
Most of this can be done with minimal changes. The index templates
need a {TOP} and {BOTTOM} and the blocks assigned to these columns.
The Block_render classes should be pretty simple.
Just realized a downside. When you add new sections, they wouldn't
have all the page components automatically.
Joe
|
|
From: Luis M <le...@ho...> - 2003-04-16 00:31:20
|
MOVED TO -devel ...
<snip>
> > >There is a typo:
> > >
> > >45 error_reporting(E_ALL,~E_WARN);
> > >
> > >should be something like (untested):
> > >
> > >error_reporting(E_ALL & ~E_WARN);
> >
> > Well, mails seems to be sent only to the first person on the list
>anyway.
> > Kind of strange, don't you think ? I'm no good with php, but I did run a
> > test to see what's happening.
> >
> > If I run with the standard .71 MailingList.class, it stops after the
>first
> > address, but if I change the while ($this->db->next_record()) {
> > ... } to only be:
> > while ($this->db->next_record()) {
> > $name = $this->db->Record["name"];
> > $email = $this->db->Record["email"];
> > $dayback = $this->db->Record["dayback"];
> > $this->message .= "To: $email <$name>\n";
> > } // End: while ( $this->db->next_record() )
> >
>
>Well I know why it's broke now. What I'm not sure about is why it
>ever worked.
It never really worked, it only sent the first email and screwed the array
as you proved below.
>
>if ( ($dayback != $tmpDay) && ( !($ary['override']) ) ) {
> $ary['body'] = $this->build_body($ary,$dayback);
>}
>
>The call to build_body uses the same db object. This screws up the
>array for the current while loop.
>
>I got it to work by creating a new db object in build_body and using
>it instead of this->db.
>
>Luis - can you work on this?
>
Yes, I need to fix this as I mention before. I'll work in the phpslash-dev
module.
I wanted to ask you, what will happen to the phpslash-ft module? Are you
planning to keep sync'ing all changes manually everytime something is proven
to work in the -dev module? or you will use the "stable" phpslash module
once phpslash-dev becomes stable enough to do a new release?
In whichever case, I'll try to fix this and the poll bugs reported before in
the phpslash-dev module.
<snip>
----)(-----
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-14 18:21:30
|
This feature is mostly done and committed to cvs. The block options demonstrate radio and select boxes for block options. Pretty spiffy. Screenshot: http://www.phpslash.org/images/screenshots/block_options.jpg The author Profile template was limited to changing the default options only. This isn't fixed yet. later, Joe |
|
From: Luis M <le...@ho...> - 2003-04-13 00:22:12
|
> > > > Took the plunge and updated my site to the crispy clean 0.71rc1 >release... > > so far things have been nice. The upgrade was very smooth this time. > > > > I found that some strings were added to the en.php locale file, so I > > translated them for the es.php (Spanish). Check patch submission 720102. > > > >thanks. You can commit it to cvs if you like. I probably won't get to it >till >Monday. Oh, I didn't realized I could... I'll commit it then. > > > Nice work guys. "Remember Me" function works like a charm now. I have >not > > tried to replicate the other known bugs (like those in the Polls), but, > > something is something and getting the "Remember Me" up and running was > > worth the try to upgrade. > > > >There are some more fixes to the auth being tested too. > >Did you see the posts regarding cronmail? Yes I saw the post. I didn't make much sense of it though since I read it too quickly. I have seen that the script stops at some point now and doesn't continue sending the emails as it should. So I know there are bugs in it, and I need to get them fixed quickly because I use this script everyday -- it just doesn't send the emails to the people that should be receiving them according to the days that they are subscribed for. Is anybody interested in working on the cronmail.php script together with me to get this script to just work as it should? ----)(----- 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-04-12 07:11:45
|
Took the plunge and updated my site to the crispy clean 0.71rc1 release... so far things have been nice. The upgrade was very smooth this time. I found that some strings were added to the en.php locale file, so I translated them for the es.php (Spanish). Check patch submission 720102. Nice work guys. "Remember Me" function works like a charm now. I have not tried to replicate the other known bugs (like those in the Polls), but, something is something and getting the "Remember Me" up and running was worth the try to upgrade. ----)(----- 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-10 19:00:42
|
On Fri, Apr 04, 2003 at 10:26:00AM -0600, Joe Stewart wrote:
>
> 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?
>
Okay this was hard to explain. In short - the index pages can have
{HEADER} and {FOOTER} placeholders.
The pertinent parts of the index page look like this:
...skip...
// get page header and footer
$header = getHeader($pagetitle,$_PSL['metatags']);
$footer = getFooter();
...skip...
// parse these template variables for display.
$template->set_var(array(
'HEADER' => $header,
'FOOTER' => $footer,
...skip...
// add page output to be displayed
$output .= $template->parse('OUT','index');
// add header if not parsed above in index page template
if( !$template->is_available('index','HEADER')) {
$output = $header . $output;
}
// add footer if not parsed above in index page template
if( !$template->is_available('index','FOOTER')) {
$output .= $footer;
}
// display the page
echo $output;
The template::is_available method is this:
function is_available($var, $placeholder) {
$status = false;
$str = ' '.$this->get_var($var);
if( strpos($str,"{".$placeholder."}") > 1) {
//found
$status = true;
}
return $status;
}
Joe
|
|
From: Mike G. <mi...@op...> - 2003-04-09 14:49:18
|
On Wed, 2003-04-09 at 10:40, Joe Stewart wrote:
> On Tue, Apr 08, 2003 at 08:39:43PM -0400, Mike Gifford wrote:
<snip>
> > Now the convention is (I think) that all of the scripts in the /admin/
> > directory call on 'config.php' in that directory which calls up the
> > '../config.php' script, right? So couldn't you just fillet out the
> > extra rooturl?
> > $_PSL['rooturl'] = str_replace('/admin/', "/", $_PSL['rooturl']);
> > Or am I missing something...
> The navbar arrays are defined in rooturl/config.php. So their links
> are screwed up when in the admin directory.
Drat..
> This is inside the called config.php. So defining rooturl in the
> admin/config.php before or after won't help.
How much of a resource drag would it be to put this in the
rooturl/config.php file?
$_PSL['rooturl'] = str_replace('/admin/', "/", $_PSL['rooturl']);
Don't imagine that it would inconvenience too many folks if they
couldn't set up a root url within an /admin/ directory..
There are other apps that have done this.. If I have a chance and find
some good example code I'll send it along.. But this isn't a critical
function..
Mike
--
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca
|
|
From: Joe S. <joe...@us...> - 2003-04-09 14:29:49
|
On Tue, Apr 08, 2003 at 08:39:43PM -0400, Mike Gifford wrote:
> On Mon, 2003-04-07 at 23:11,
> php...@li... wrote:
>
> <snip>
>
> > 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.
>
> Now the convention is (I think) that all of the scripts in the /admin/
> directory call on 'config.php' in that directory which calls up the
> '../config.php' script, right? So couldn't you just fillet out the
> extra rooturl?
>
> $_PSL['rooturl'] = str_replace('/admin/', "/", $_PSL['rooturl']);
>
> Or am I missing something...
>
The navbar arrays are defined in rooturl/config.php. So their links
are screwed up when in the admin directory.
This is inside the called config.php. So defining rooturl in the
admin/config.php before or after won't help.
> <snip>
>
> Mike
> --
> Mike Gifford <mi...@op...>
> OpenConcept Consulting http://www.openconcept.ca
>
|
|
From: Mike G. <mi...@op...> - 2003-04-09 00:39:38
|
On Mon, 2003-04-07 at 23:11, php...@li... wrote: > Send Phpslash-devel mailing list submissions to > php...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/phpslash-devel > or, via email, send a message with subject or body 'help' to > php...@li... > > You can reach the person managing the list at > php...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Phpslash-devel digest..." > > > Today's Topics: > > 1. Re: root_url and http_host (Joe Stewart) > > --__--__-- > > Message: 1 > Date: Mon, 7 Apr 2003 14:29:40 -0500 > From: Joe Stewart <joe...@us...> > To: PHPSlash Developers List <php...@li...> > Subject: Re: [Phpslash-devel] root_url and http_host > > On Thu, Dec 19, 2002 at 11:32:57AM -0600, Joe Stewart wrote: > > In short to paraphrase Mike: Love it when things get shorter.. > > "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';" It's great to be able to specify it, but it's probably even better if you don't have to.. <snip> > 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. Now the convention is (I think) that all of the scripts in the /admin/ directory call on 'config.php' in that directory which calls up the '../config.php' script, right? So couldn't you just fillet out the extra rooturl? $_PSL['rooturl'] = str_replace('/admin/', "/", $_PSL['rooturl']); Or am I missing something... <snip> Mike -- Mike Gifford <mi...@op...> OpenConcept Consulting http://www.openconcept.ca |
2 messages has been excluded from this view by a project administrator.
