Re: [Phpslash-devel] embracing the future

[Joe S. <joe...@us...>]

On Tue, Oct 28, 2003 at 11:14:50AM +0000, Peter Cruickshank wrote:
> On Monday 27 Oct 2003 7:09 pm, Joe Stewart wrote:
> ...
> 
> Thanks for your feedback Joe and Luis - seems that a lot of my points are 
> because I was using the CVS rather than a distro, and that's it's been a 
> while since I was involved here.
> 
> > > First impressions on doing a simple default install:
> > >
> > > - I really like the modularisation. The structure is so different tho
> > > that  I think it's worth considering calling it 0.8 when it is released
> > > (will make it easier to keep Back-End in step with PSL, apart from
> > > anything else). Of course, that brings it all scarily close of 1.x...
> > > which will be hit by the end of this decade at the current rate :-)
> 
> A move to 0.8 might be the chance to change config.ini.php to consistently use 
> the dot notation for naming settings (db.host, skin.default, 
> search.maxresults etc). Just a thought.
>

A very good thought too.  It really does help clean up the variables.

> > > think it would make it easier to customise skins by making it obvious
> > > where the content comes from. (I think Joe mentioned this in the context
> > > of using the PEAR template class)
> >
> > If this isn't working, file a bug report.  The existing templates have not
> > been moved in the cvs, but it's been tested.
> 
> What convention have you used for paths? I'm going to develop a couple of 
> modules for a client, and would like to stick with the standard. 
> 
> I'd guess something like:
> {rootdir}/include/modules/{modulename}/templates/en/{skinname}/

I was using:

  {rootdir}/include/modules/{modulename}/templates/

And if a template exists in the lang/skin it overrides this one.

> with a skin.ini that points to:
> {rootdir}/include/templates/en/{skinname}/
> 
                                     ^ parentskin

> > One thing I don't like.  If your new whiz bang module adds a block type,
> > The _render.class file has to go in modules/block/blocktypes.
> 
> Perhaps if psl_block_type had an extra field to record the block's module? The 
I even had a paragraph written proposing something like this for module
registration, naming, and path.  Then I remembered that you can use a
"module" block type and reduce the number of blocktypes needed
tremendously.

> page building code would then know where to look.
> - the existing block adding/removing code would have to be changed tho. (Is it 
> used much?)
> 

I don't think this would be a big hurdle.  It might be a db hit and then
loaded in the session.

> [Other points are specific to the CVS]
> 
> > > - Not sure what the point of the show_admin_on_navbar option is. The
> > > current note got me confused...
> >
> > May be time for it to go away.  It's whether you want the login/logout in
> > the navbar.
> 
> If I enable show_admin_on_navbar, the navbar has:
> [Logout nobody] [Login] ...
       ^ didn't realize it did this now.  I think its time to silently
       drop this option.  It should also say Login.

> and once I'm logged in:
> [Logout god] [Logout] ...
                  ^ This one is the stuff in the menu array.
	^ This one is the option your asking about.
> Which just don't seem right ;-)
> 

The argument for it remaining was that it knew your name when logged in I
guess.



> New query:
> Not sure if it's just my setup, but I checked the Remember Me box, and I've 
> not been able to properly logout - when I click logout, I get the login form 
> (as you'd expect), but when I go to other pages, I'm still logged in as god.
> 
> ...
> 

What browser and rooturl?

Mozilla/Netscape can set cookies it can't delete.

> 
> > > Comments on the example data:
> > >
> > > - it would be great if Home was section 1. Put that down to me being
> > > neurotic...
> >
> > hmm... Sounds good to me.  Should be able to work around with upgrade
> > scripts.
> 
> No need to change existing data I think (unless data structure has changed) - 
> so long as the Home->3 relationship is left in config.ini.php for existing 
> installs?
> 
> > > - INSTALL should make it clear that the example data assumes that the
> > > public_html directory is visible to the web client (I think it would be
> > > better if installers were encouraged to install phpslash away from the
> > > webroot and then link public_html to the webroot. Not sure whether that
> > > would solve problems with the example data tho).
> >
> > ??  Can you go into more detail?
> 
> Using Mandrake, I downloaded to CVS to /var/www/phpslash-dev/, and then from 
> /var/www/html did an 
> ln -s ../phpslash-dev/public_html phpslash
> so that phpSlash runs from http://localhost/phpslash/ 
> 
> (OK I know I could use Apache commands to achieve the same effect) 
> 
> Anyway, all I was saying is that the links in the demo data were to 
> http://localhost/phpslash/public_html/ . . . not a big deal, and since the 
> instal is aimed at people unfamiliar with PSL the data is probably right .
> 

I can't find this in phpslash-dev/tables/0.7/slash-all.sql.


> > This is how I've been installing it -
> >
> > The files in public_html get installed in the webroot.
> > Then create a structure like this:
> > home-phpslash-etc-config.ini.php - config.php has the full path to it.
> >              -include/
> That's got me confused now!
> 

no biggy.

Joe

> > > - Perhaps the date on the 'Congratulations' article should be updated (it
> > > says 4-Dec-2000 right now...)
> ...
> 
> > thanks for the impression and suggestions.
> 
> No problems
> 
> Peter
> -- 
> Computers are not intelligent.  They only think they are.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel