phpslash-devel — For developers of phpslash to communicate.

[Phpslash-devel] module text file shortcoming?

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

How do we want to handle the text that is in the translation files for new
modules?

This is something that hasn't been addressed at all.

[Phpslash-devel] back-end install wizard

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

I backported Evan Hughes' install wizard for back-end to phpslash.  It is
in cvs now.  If you do an anon checkout it may not be mirrored yet.

Luis - can you see if you can add your download option?  Currently if it
can't write the ini file it displays it for cut and paste.  Also see if
maybe we could graft your editor on for modifying the other options, or
expand the questions.  It currently only does the bare minimum to get
started.

Since I didn't tag the 0.8alpha release yet and I screwed up and put the
templates in twice, I'm going to replace the download binary with a new
one.  If you've got any bug fixes, get them in.  I'm going to try to get
some new story text plugin changes done too.

Joe

Re: [Phpslash-devel] How to add a module?

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

On Wed, Nov 05, 2003 at 10:27:54PM +0000, Peter Cruickshank wrote:
> In the delay between sending the email (5+ hours ago) and it appearing on the 
> list, I've sussed out the problem... ten minutes after the message appears. 
> Typical.
> 
> I'd miss-spelled the template name 'contentonly' as 'contentsonly'.
> 
> I guess it took so long to pin down the answer because there have been so many 
> changes I wasnt sure where to start looking.
> 
> I have to ask tho.... is there any way to get an error message generated, 
> rather than the page just silently dying? If the template class error had 
> been shown, I'd have been able to get some productive work done today. (Or if 
> I was less careless, I know...)
> 

I'd like that too.  There may be some commented out, but I've had some
problems with errors in the template class not being very forgiving.
Yours should have simply shown the applicable fancybox.tpl.  Seems a bug
to me.

> Grumble, grumble... still, at least I got it sorted before giving up for the 
> day. Must look on the bright side.
> 
> P
> -- 
> PS It truly is fascinating how many times login.php seems to instantiate 
> slashBD...
> 
> 

Yeah.  Did Ian get the queries cleaned up some?  I think most people
won't notice a slight delay while logging in.  After logging in the array
is in the session.

Joe

Re: [Phpslash-devel] How to add a module?

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

On Wed, Nov 05, 2003 at 03:08:01PM +0000, Peter Cruickshank wrote:
> I'm trying to add a new module to phpSlash 0.8alpha and I need some help... 
> 
> This is what I've done so far.
> 
> 1. Copied the glossary files to use as a basis for my new module (called 
> House)
> - /public_html/glossary.php -> property.php
> - /public_html/admin/glossaryAdmin.php  -> propertyAdmin.php
> - /include/modules/glossary/  -> house/
> 
> (You might be able to work out what the application's for...)
> 
> 2. Edited the code to use House.class instead of Glossary.class
> 
> 3. Edited config.ini.php
>  - Added a new module House = house
>  - Set jpcache.enable = false so I'm looking at live pages
> 
> 4. Added new menu items
> $menuitem[] = array(
>    'name'   => "House",
>    'link'   => $_PSL['rooturl'] . "/property.php",
>    'perm'   => "nobody",
>    'module' => "House"
> );
> 
> and (for admin menu)
> 
> $menuitem[] = array(
>    'name'   => "House",
>    'link'   => $_PSL['adminurl'] . "/propertyAdmin.php",
>    'perm'   => "glossary",
>    'module' => "House"
> );
> 
> 
> This was enough for the admin screen to work (ie the glossary admin screen 
> appears, since I have made no changes to the code), but there was nothing for 
> the main page (property.php).
> 
> After a little thinking and digging around, I did a bit more:
> 
> 5. Created a House section
> 
> 6. Added a new module block
> - Owned by section: House
> - Order number = 90
> - column = center
> - box_type = contentsonly
> - module = House 
> ** Incidentally, the code went berserk when I missed the module paremeter, 
> adding c200 copies of the new module block. I will track this down and submit 
> a fix.
> 
> ...Still nothing. Konqueror helpfully tells me that the connection to the host 
> is broken (which is a lie - it's only that something's going wrong with the 
> page).
> 
> If I remove the link between the House block at the House section, I get a 
> page with an empty center column, so I am fairly sure that the issue is with 
> generating the content to go into the House-module block. 
> 

Sounds like maybe modules/house/index.php is goofy.

> I can't see how to pin it down though.
> - I have put a debug line in modules/house/index.php - it is never reached
> - debug on propery.php shows module.current == "block" (if I force it to 
> 'house' I get the glossary search page, but nothing else)
> 

Ah.  so the index page may be ok.  

> All the debug statements have been removed along the line, so turning debug on 
> isnt helping a whole lot.
> 
> What else do I need to do? I'm sure it's something pretty simple I've missed 
> out...
> 
> 

Don't have much time now but here's a few thoughts.

Looks like you found the way it's mostly setup.

The glossary.php/property.php are not imperative anymore.  The site should
work with:

	http://localhost/phpslash-0.8alpha/public_html/index.php?module=House

If this doesn't work, look at the module/house/index.php code.

If it works, look at property.php,  you can change the section to
something else that seems to work to test.  

Instead of using the House section you can also use ary['module'] =
'House'; instead.  You should get all the blocks for the home page with
the House module in the center.  This is what the admin page does.

By default the public page modules call modules/modulename/index.php.  The
admin pages call modules/modulename/admin.php.

The index page can bring them up like:

index.php?module=modulename&page=admin

The form code in the existing index.php and admin.php hasn't been modified
to work though.  This is what the changes to poll.php, glossary.php
accomplished.

> The benefit of helping me - I will write this up as a how-to for the website 
> once everything's working. Unless there is one already, and I've missed it...
> 

No, there are a few different examples in the example code.

> Thanks in advance!
> 

hope there is something in there.

Joe

> Peter
> 
> 

Re: [Phpslash-devel] How to add a module?

[Peter C. <li...@cr...>]

In the delay between sending the email (5+ hours ago) and it appearing on the 
list, I've sussed out the problem... ten minutes after the message appears. 
Typical.

I'd miss-spelled the template name 'contentonly' as 'contentsonly'.

I guess it took so long to pin down the answer because there have been so many 
changes I wasnt sure where to start looking.

I have to ask tho.... is there any way to get an error message generated, 
rather than the page just silently dying? If the template class error had 
been shown, I'd have been able to get some productive work done today. (Or if 
I was less careless, I know...)

Grumble, grumble... still, at least I got it sorted before giving up for the 
day. Must look on the bright side.

P
-- 
PS It truly is fascinating how many times login.php seems to instantiate 
slashBD...

[Phpslash-devel] How to add a module?

[Peter C. <li...@cr...>]

I'm trying to add a new module to phpSlash 0.8alpha and I need some help... 

This is what I've done so far.

1. Copied the glossary files to use as a basis for my new module (called 
House)
- /public_html/glossary.php -> property.php
- /public_html/admin/glossaryAdmin.php  -> propertyAdmin.php
- /include/modules/glossary/  -> house/

(You might be able to work out what the application's for...)

2. Edited the code to use House.class instead of Glossary.class

3. Edited config.ini.php
 - Added a new module House = house
 - Set jpcache.enable = false so I'm looking at live pages

4. Added new menu items
$menuitem[] = array(
   'name'   => "House",
   'link'   => $_PSL['rooturl'] . "/property.php",
   'perm'   => "nobody",
   'module' => "House"
);

and (for admin menu)

$menuitem[] = array(
   'name'   => "House",
   'link'   => $_PSL['adminurl'] . "/propertyAdmin.php",
   'perm'   => "glossary",
   'module' => "House"
);


This was enough for the admin screen to work (ie the glossary admin screen 
appears, since I have made no changes to the code), but there was nothing for 
the main page (property.php).

After a little thinking and digging around, I did a bit more:

5. Created a House section

6. Added a new module block
- Owned by section: House
- Order number = 90
- column = center
- box_type = contentsonly
- module = House 
** Incidentally, the code went berserk when I missed the module paremeter, 
adding c200 copies of the new module block. I will track this down and submit 
a fix.

...Still nothing. Konqueror helpfully tells me that the connection to the host 
is broken (which is a lie - it's only that something's going wrong with the 
page).

If I remove the link between the House block at the House section, I get a 
page with an empty center column, so I am fairly sure that the issue is with 
generating the content to go into the House-module block. 

I can't see how to pin it down though.
- I have put a debug line in modules/house/index.php - it is never reached
- debug on propery.php shows module.current == "block" (if I force it to 
'house' I get the glossary search page, but nothing else)

All the debug statements have been removed along the line, so turning debug on 
isnt helping a whole lot.

(BTW I've put some debugs back in and discovered some interesting things:
- block_i::getBlocks runs through an array of all the blocks 6 times (once for 
each column type)
- pslNew('slashDB') is invoked at least 6 times on a page - I guess meaning 
that psl uses that many mySQL connections per page-invokations.) 

What else do I need to do? I'm sure it's something pretty simple I've missed 
out...


The benefit of helping me - I will write this up as a how-to for the website 
once everything's working. Unless there is one already, and I've missed it...

Thanks in advance!

Peter
-- 
Ummm, well, OK.  The network's the network, the computer's the computer.
Sorry for the confusion.
		-- Sun Microsystems

[Phpslash-devel] How to add a module?

[Peter C. <li...@cr...>]

I'm trying to add a new module to phpSlash 0.8alpha and I need some help... 

This is what I've done so far.

1. Copied the glossary files to use as a basis for my new module (called 
House)
- /public_html/glossary.php -> property.php
- /public_html/admin/glossaryAdmin.php  -> propertyAdmin.php
- /include/modules/glossary/  -> house/

(You might be able to work out what the application's for...)

2. Edited the code to use House.class instead of Glossary.class

3. Edited config.ini.php
 - Added a new module House = house
 - Set jpcache.enable = false so I'm looking at live pages

4. Added new menu items
$menuitem[] = array(
   'name'   => "House",
   'link'   => $_PSL['rooturl'] . "/property.php",
   'perm'   => "nobody",
   'module' => "House"
);

and (for admin menu)

$menuitem[] = array(
   'name'   => "House",
   'link'   => $_PSL['adminurl'] . "/propertyAdmin.php",
   'perm'   => "glossary",
   'module' => "House"
);


This was enough for the admin screen to work (ie the glossary admin screen 
appears, since I have made no changes to the code), but there was nothing for 
the main page (property.php).

After a little thinking and digging around, I did a bit more:

5. Created a House section

6. Added a new module block
- Owned by section: House
- Order number = 90
- column = center
- box_type = contentsonly
- module = House 
** Incidentally, the code went berserk when I missed the module paremeter, 
adding c200 copies of the new module block. I will track this down and submit 
a fix.

...Still nothing. Konqueror helpfully tells me that the connection to the host 
is broken (which is a lie - it's only that something's going wrong with the 
page).

If I remove the link between the House block at the House section, I get a 
page with an empty center column, so I am fairly sure that the issue is with 
generating the content to go into the House-module block. 

I can't see how to pin it down though.
- I have put a debug line in modules/house/index.php - it is never reached
- debug on propery.php shows module.current == "block" (if I force it to 
'house' I get the glossary search page, but nothing else)

All the debug statements have been removed along the line, so turning debug on 
isnt helping a whole lot.

What else do I need to do? I'm sure it's something pretty simple I've missed 
out...


The benefit of helping me - I will write this up as a how-to for the website 
once everything's working. Unless there is one already, and I've missed it...

Thanks in advance!

Peter

[Phpslash-devel] xdebug php profiler

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

Found this php profiler.  It seems to do what's needed.  Haven't a whole
lot of time messing with it yet though.

	http://www.xdebug.org/

Joe

[Phpslash-devel] release phpSlash 0.8alpha

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

Release Name: 0.8alpha

---------------------------------------------------------------------------
About this release:
---------------------------------------------------------------------------
This release has many new features and bugfixes.
---------------------------------------------------------------------------
Summary of changes since 0.7.2:

File locations moved to be more modular.
All output is rendered through blocks.

For this release, the skins from phpslash-skins cvs tree are incorporated.
The default skin was changed to ShankZen.

There are known deficiencies in this release.  At least a few are:

login page not updated to new format.
related links not generated.
documentation is not generating correctly.
all skins are not complete.
no upgrade path from previous releases.

---------------------------------------------------------------------------
This is a development release to garner more widespread testing and as
such may have unforeseen bugs that could cause data loss.
---------------------------------------------------------------------------
Where to get 0.8alpha: 
---------------------------------------------------------------------------
Main:           http://sourceforge.net/projects/phpslash/

This release has been tagged as PSL_08_ALPHA 

---------------------------------------------------------------------------
Other general info:
---------------------------------------------------------------------------
- Support can be found on php...@li... 
- File bugs at http://sourceforge.net/projects/phpslash/
- We are not affiliated with slashdot, slashcode, squishdot, scoop,
  phpNuke or any other weblog engine.  Please email us not them if you
  have questions about phpSlash, as  they'll probably just delete your
  mail and that wouldn't  be very  helpful, would it?

[Phpslash-devel] Small patch: Set breadcrumb delimiter in config.ini.php

[Peter C. <li...@cr...>]

Hi

I've posted to patches a simple change to functions.inc to allow the 
breadcrumb delimer to be set in config.ini.php:

780c780
<       $delimeter = "->";
---
>       $delimeter = $_PSL['breadcrumb.delimiter'];

You need to add a line like this to config.ini.php:
breadcrumb.delimiter = "  -&gt; "

(Patch applies to -dev module)

P

Re: [Phpslash-devel] embracing the future

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

On Tue, Oct 28, 2003 at 06:09:10PM +0000, Peter Cruickshank wrote:
> 
> But modules are (kind of) registered in the $_PSL['module'] array - that could 
> be used for building a list of directories to look for Block_render_* files 
> in? There may be other reasons not to distribute the block-rendering code 
> around the place tho. 
> 

maybe so.  It's another place that the config file requires editing.

> I'm still getting my head round the move to rending modules through the block 
> mechanism. Seems a great idea tho.
> 

all of us.  That's why I threw out a working example to see what direction
everyone can agree on.

The pages like about.php, poll.php, etc.  are kind of there
for compatibility.  They could be replaced in the menu with different
links.  However, each one of them requires changes for their
forms/arguments to work correctly.

The reason the block_render*.class files aren't needed as much is that for
a module block you can set the module and the php page called from the
module directory.  

There really is all kinds of weird stuff you can do.

> 
> What about getting rid of the option + maybe creating an identity block or 
> making the username available to the templates?
> 

We might be able to put a placeholder for the username in the logout menu
item.

> > > 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.
> 
> OK. It'll see if it stays a problem. (Mozilla 1.3.1 on Mandrake 9.1, rooturl = 
> //192.168.1.100/phpslash) - but I'm not consistently reproducing this 
> behavior, so best leave it for now.
> 
> ...

Might be the ip instead of a host name.  Also might be the attempt to make
all the browsers happy with different rooturl setups.  Mozilla is a little
more strict at deleting cookies than setting them.

Joe

Re: [Phpslash-devel] embracing the future

[Peter C. <li...@cr...>]

On Tuesday 28 Oct 2003 4:45 pm, Joe Stewart wrote:
...

> > 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.

Yup. There may be other tidying up that could be done at the same time?

...

>   {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

I'll have a play.

> > > 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.

But modules are (kind of) registered in the $_PSL['module'] array - that could 
be used for building a list of directories to look for Block_render_* files 
in? There may be other reasons not to distribute the block-rendering code 
around the place tho. 

I'm still getting my head round the move to rending modules through the block 
mechanism. Seems a great idea tho.

> > 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.

What about getting rid of the option + maybe creating an identity block or 
making the username available to the templates?

> > 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.

OK. It'll see if it stays a problem. (Mozilla 1.3.1 on Mandrake 9.1, rooturl = 
//192.168.1.100/phpslash) - but I'm not consistently reproducing this 
behavior, so best leave it for now.

...

> > 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.

You're right - not sure what happended there

A couple of false alarms then!

P
-- 
As in certain cults it is possible to kill a process if you know its true 
name.
		-- Ken Thompson and Dennis M. Ritchie

Re: [Phpslash-devel] embracing the future

[Luis M <le...@ho...>]

>Let's package a development release soon.  The related links need a
>fixing.

Yes, I'm itching to start using phpslash-dev...

>They've got some neat additions.  Peter C. has some base classes that
>hopefully will be backported in some way.  Evan wrote an installer script.
>Maybe you and he can get together to flesh one out for phpSlash.  wiki
>markup understood ( similar to phpBB code or phorumcode).  Subsections.
>etc.

Ok. This sounds perfect. When do we start? #phpslash should be a hangout 
place for all readers of -devel mailing list... and even for -users also.

for the uninitiated:

server: irc.freenode.net
channel: #phpslash

>A developer's reference has been started, but not worked on much.  It's in
>the doc directory or online:
>
>	http://phpslash.sourceforge.net/doc/psldeveloper.html
>
>
>A couple of other wishlist items - webmin module ( perl based), a debian
>package.

Debian package is a definite yes, for as long as the postinst script takes 
care of login to the db and applying the necessary .sql file to it (after a 
big warning giving sysadmins chance to msyql-dump their databases...) :-)


----)(-----
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

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

Re: [Phpslash-devel] embracing the future

[Peter C. <li...@cr...>]

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.

> > 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}/
with a skin.ini that points to:
{rootdir}/include/templates/en/{skinname}/

> 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 
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?)

[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] ...
and once I'm logged in:
[Logout god] [Logout] ...
Which just don't seem right ;-)

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.

...


> > 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 .

> 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!

> > - 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.

[Phpslash-devel] embracing the future

[Mike G. <mi...@op...>]

Hi Luis,

Message: 1 "Luis M" <le...@ho...>:
> >I know nothing about the phpslash-dev site, but I am quite interested in
> >offering what Back-End has learned/used for adding/editing documents.
> People should really start trying phpslash-dev module from the cvs. It's 
> pretty much "stable" enough right now to be used in replacement of 
> phpslash-ft. 

I downloaded it, was impressed.  Only bug was that phpMyAdmin couldn't
incorporate the sql.. I think because of the -- comments rather than ##

> But, remember that's the "experimentation" module. We should 
> probably freeze it as it is right now and do a minor release based on it so 
> that people can try it and we can get an idea of how the migration will be 
> from -ft (current stable release) to -dev. From then on it will be downhill 
> with -dev.

Sounds excellent!

> Remember that -dev is fully modularized. Everything, every block, story, 
> header behaves in this manner... Great level of "granularity" and also a 
> scary thought that if something goes wrong, it might be hard to know from 
> where the error is coming... that's why we need testing, to improve it to 
> the point that we know for sure we are not missing anything and start 
> replacing our own sites (first) with the minor release (fingers crossed) and 
> deal with possible pitfalls.

Yup..  Big upgrades can be a bit scary...

...

> >Back-End has added a wiki text editor mode and an implementation of
> >htmlArea3 to psl's present options.  Giving users options is a good
> >thing.  Adding an option for phorum-like syntax could be a useful option
> >too.  For the wiki text we added an extra column for both the parsed
> >html as well as the original wiki content.
> I really don't know much about what BackEnd is. I guess I jumped in late in 
> the phpslash-* discussions and didn't get the whole scope of it. I keep 
> reading your posts relating to it, but I don't know anything about it. 
> Besides the backend.php script in phpslash which I use for my syndicated 
> news and Mozilla tabs.

Sorry..  It's another CMS built on PSL..  
	http://sourceforge.net/projects/back-end

It's a bit confusing with the Back-End.org & backend.php.. Rather
unfortunate for us.

We've extended PSL to move from a news/slash focus to a hierarchy/cms
focus.  It's also multi-lingual.  

A couple examples of the code:
	http://www.learningpartnership.org/
	http://www.cupe.ca/
	http://www.fairvotecanada.org/

I've been on the psl development list for a while because often I have
questions about psl code & because I'm interested in the direction that
BE is going.  I'd also like to be able to contribute some of what we've
learned back to psl.

> >htmlArea3 is pretty good..  There's even a spell check module.  The best
> >thing is that it works in Mozilla & IE so I can actually test it.
> Sounds like htmlArea3 is the way to go then... Giving users choices is 
> great, but if we could simplify things and at least choose htmlArea3 to be 
> the default and let users turn it off as they get better in using the 
> phpslash interface. 

I've set up some scripts to turn it off for scripts like Galeon too.  I
work in Linux and sometimes like to use Mozilla, but still prefer
Galeon.  It' just defaults to html in a text area box..

> Powerusers should be able to go to their own profiles 
> and turn on or off what they want or don't want. My concern is to make 
> things super clear and super simple for those users who don't have the 
> notion of how computer programs work -- or web interfaces for that manner. 

The ongoing challenge..

> Users who simply have not been exposed to those conventions might not find 
> certain things too intituitive when they first see it. I think, for 
> instance, that php Phorum achieves this instantly. Once you install it and 
> use it, you don't have to know how to do anything (i.e. read any manuals or 
> help), so, users start instantly interacting with others in the site. As an 
> example of this. I setup a Forum using Phorum (redundant sound uh?) here: 
> http://foro.latinomixed.com. In my regular site, dealing with news and howto 
> articles in general, users rarely register as new users or for the mailing 
> list or anything. Whereas within days of activating the forum I got about 27 
> users registered (and counting). In my case, my site aims at those who need 
> help (non-power users) who are looking for ways to improve their computer 
> knowledge. In reality, even power users benefit from having things simpler; 
> that's why Linux users buy Mac laptops with MacOS X on them :-D

It's nice when things just work!  

I think you meant phpBB & not Phorum..  Phorum was another project, not
sure how active it now is.  But phpBB is plenty active:
	http://phpbb.com/

I took a look at an install I had.  Like htmlarea3 it looks like it is
javacript and css that could be easily integrated in psl or BE.  I'm not
sure at this point if it stores the text as html or in the phorum markup
[b]bold this[/b]

> >I also like the idea of being able to just upload the html of a story
> >rather than having to copy/paste it.
> That has already been added to phpslash-dev and it works fine. I ported that 
> from my own site which was based on phpslash-0.6.x and updated the code so 
> that it works with php 4.1  and up -- the reason for this is that I'm using 
> the _FILES array to avoid having users specifically changing their php.ini's 
> or anything else. It works perfectly for as long as you have file upload on 
> in php.ini (of course). 

Very cool!

> Read the comments in 
> include/modules/story/Story_base.class of the phpslash-dev cvs module.
> NOTE: that makes me wonder if there is a way to use Oxygen to generate 
> documentation for php source code the same way that it's used for C++? We 
> should have documentation for the developers as well as for regular users... 
> just a thought...

We've been trying to use:
	http://phpdocu.sourceforge.net/

Which can theoretically generate both from inline code.  Trick is in
trying to consistently put in the function headers.

> >Would be also useful to allow folks to turn on/off modules through the
> >web interface rather than through the config.ini.php
> Wonderful idea. The problem would be where to put the config.ini.php then so 
> that it's writeable by the user that runs the webserver or in the database 
> itself. Maybe we should get rid of the file config.ini.php altogether and 
> put this whole file in a compressed format into a record in the database... 
> gzip compression is done on the fly these days, why not take advantage of 
> that. We could even use jp_cache to cache it for X number of minutes... Joe?

Or store it in the sessions...  It's been discussed..

> >Also, we had talked about an installer in the past for psl/be..
> >Wondered if you had a chance to check out Back-End's new installer
> >script.  Makes an installation pretty quick.
> The script is written in php and runs as a cgi? or is it a Perl script? 

It's just PHP.  Runs through the browser.  It's presently set up so that
if it can't find functions.inc from the info in the config.ini.php that
it redirects the file to config_setup.php

> I 
> did a setup.php script for parsing the config-dist.ini.php file so that 
> users can edit it in their browsers and save this file to a file in their 
> workstations for then uploading that to whatever server they will use... 
> long procedure uh? but works.

This doesn't give them access to all the variables in the
config.ini.php, but makes the install a 2 minute process.  Pretty
critical to get new folks to test out their code.  When you're testing
out code it's easy to have a short attention span.

Message: 2 "Luis M" <le...@ho...>:
> >Back-End has added a wiki text editor mode and an implementation of
> >htmlArea3 to psl's present options.  Giving users options is a good
> >thing.  Adding an option for phorum-like syntax could be a useful option
> >too.  For the wiki text we added an extra column for both the parsed
> >html as well as the original wiki content.
> Ok, I check the htmlarea3 site and I have to admit that it is impressive, 
> but, maybe overkill. Also, it only works on IE and Mozilla version X and 
> up... and to top it all off under BSD license...

It's a modified BSD license so it is GPL compatible.  And although there
are lots of features that you'd never want to use in a slash site, you
can turn them off.

The formatting stuff isn't all that important for a slash site.  fonts &
what not..

But the spell checker would be a total plus!

> I meant something simple like phpBB that only uses standard features. A way 
> to turn of JavaScript should be somewhere in the users profile. 

Ideally advanced users would be able to specify the default editing
type.  

> But, you 
> don't need the javascript part to edit with phpBB, that's just to make your 
> life simpler. That way I could use Opera/Camino/Konqueror/Netscape 3/4/6/7 
> and others from any computer without worrying about having different 
> interfaces to edit the text.

If you don't have a browser that can handle the javascript enhancements,
it should come up in html so that anyone can edit it, right?  

> Just my opinion. I respect people who would use htmlArea -- maybe they come 
> from a Windows background and that interface is intuitive for them; however, 
> for the majority of us, I think that interface is overkill -- bloated.

The majority of the world is more familiar with Windows than any other
Operating System..  That will change with China/India..  But most users
will still be Windows users, and of those most will use IE..

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Beads of Hope Campaign - http://uc.openconcept.ca/petition.php
Nonconformity is the highest evolutionary attainment of social animals -
Aldo Leopold

Re: [Phpslash-devel] embracing the future

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

On Mon, Oct 27, 2003 at 01:45:48PM +0000, Peter Cruickshank wrote:
> On Sunday 26 Oct 2003 4:24 pm, Luis M wrote:
> 
> ...
> 
> > People should really start trying phpslash-dev module from the cvs. It's
> > pretty much "stable" enough right now to be used in replacement of
> > phpslash-ft. But, remember that's the "experimentation" module. We should
> > probably freeze it as it is right now and do a minor release based on it so
> > that people can try it and we can get an idea of how the migration will be
> > from -ft (current stable release) to -dev. From then on it will be downhill
> > with -dev.
> 
> > Remember that -dev is fully modularized. Everything, every block, story,
> > header behaves in this manner... Great level of "granularity" and also a
> > scary thought that if something goes wrong, it might be hard to know from
> > where the error is coming... that's why we need testing, to improve it to
> > the point that we know for sure we are not missing anything and start
> > replacing our own sites (first) with the minor release (fingers crossed)
> > and deal with possible pitfalls.
> 
> I'm just starting a new project, so thought I'd use -dev. It's been a while 
> since I used phpSlash, so I'm sort of coming at it fresh.
> 
> 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 :-)
> 
> 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. 

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.

> - The CVS seems to be missing an install guide
> 

True.

> - the last line of config.ini.php is not needed (the ?> element is 
> automatically assumed by PHP)
> 
> - config.ini.php (or INSTALL) should make it clear that phplib needs to be 
> downloaded separately
> 

This is only for a cvs install.  The releases will include phplib.

> - not clear why config-dist.php isnt just config.php - that way you can get a 
> working site by just editng config.ini.php. 
> 

The releases have config-dist.php copied to config.php.

> - 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.

> Apart from that, the install was pretty smooth.
> 
> 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.

> - 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?

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/


> - Perhaps the date on the 'Congratulations' article should be updated (it says 
> 4-Dec-2000 right now...)
> 
> 
> HTH someone.

thanks for the impression and suggestions.

Joe

> -- 
> Peter
> 
> 

Re: [Phpslash-devel] embracing the future

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

On Sun, Oct 26, 2003 at 11:24:18AM -0500, Luis M wrote:
> >I know nothing about the phpslash-dev site, but I am quite interested in
> >offering what Back-End has learned/used for adding/editing documents.
> 
> People should really start trying phpslash-dev module from the cvs. It's 
> pretty much "stable" enough right now to be used in replacement of 
> phpslash-ft. But, remember that's the "experimentation" module. We should 
> probably freeze it as it is right now and do a minor release based on it so 
> that people can try it and we can get an idea of how the migration will be 
> from -ft (current stable release) to -dev. From then on it will be downhill 
> with -dev.

Let's package a development release soon.  The related links need a
fixing.

> Remember that -dev is fully modularized. Everything, every block, story, 
> header behaves in this manner... Great level of "granularity" and also a 
> scary thought that if something goes wrong, it might be hard to know from 
> where the error is coming... that's why we need testing, to improve it to 
> the point that we know for sure we are not missing anything and start 
> replacing our own sites (first) with the minor release (fingers crossed) 
> and deal with possible pitfalls.
> 

I think maybe we can add a group and permissions to only allow certain
block editors the ability to change some of the module blocks.


> [snip]
> 
> >Why not give your users the option of entering/editing stories using the
> >editing syntax that they choose?
> >
> >Back-End has added a wiki text editor mode and an implementation of
> >htmlArea3 to psl's present options.  Giving users options is a good
> >thing.  Adding an option for phorum-like syntax could be a useful option
> >too.  For the wiki text we added an extra column for both the parsed
> >html as well as the original wiki content.
> 
> I really don't know much about what BackEnd is. I guess I jumped in late in 
> the phpslash-* discussions and didn't get the whole scope of it. I keep 
> reading your posts relating to it, but I don't know anything about it. 
> Besides the backend.php script in phpslash which I use for my syndicated 
> news and Mozilla tabs.
> 

Back-End - http://www.back-end.org.

A cms that has been in the top 9 sf.net projects.  Mike Gifford took the
task of using phpSlash as their development framework.

They've got some neat additions.  Peter C. has some base classes that
hopefully will be backported in some way.  Evan wrote an installer script.
Maybe you and he can get together to flesh one out for phpSlash.  wiki
markup understood ( similar to phpBB code or phorumcode).  Subsections.
etc.

> [snip]
> 
> >htmlArea3 is pretty good..  There's even a spell check module.  The best
> >thing is that it works in Mozilla & IE so I can actually test it.
> 
> Sounds like htmlArea3 is the way to go then... Giving users choices is 
> great, but if we could simplify things and at least choose htmlArea3 to be 
> the default and let users turn it off as they get better in using the 
> phpslash interface. Powerusers should be able to go to their own profiles 
> and turn on or off what they want or don't want. My concern is to make 
> things super clear and super simple for those users who don't have the 
> notion of how computer programs work -- or web interfaces for that manner. 
> Users who simply have not been exposed to those conventions might not find 
> certain things too intituitive when they first see it. I think, for 
> instance, that php Phorum achieves this instantly. Once you install it and 
> use it, you don't have to know how to do anything (i.e. read any manuals or 
> help), so, users start instantly interacting with others in the site. As an 
> example of this. I setup a Forum using Phorum (redundant sound uh?) here: 
> http://foro.latinomixed.com. In my regular site, dealing with news and 
> howto articles in general, users rarely register as new users or for the 
> mailing list or anything. Whereas within days of activating the forum I got 
> about 27 users registered (and counting). In my case, my site aims at those 
> who need help (non-power users) who are looking for ways to improve their 
> computer knowledge. In reality, even power users benefit from having things 
> simpler; that's why Linux users buy Mac laptops with MacOS X on them :-D
> 
> >I also like the idea of being able to just upload the html of a story
> >rather than having to copy/paste it.
> 
> That has already been added to phpslash-dev and it works fine. I ported 
> that from my own site which was based on phpslash-0.6.x and updated the 
> code so that it works with php 4.1  and up -- the reason for this is that 
> I'm using the _FILES array to avoid having users specifically changing 
> their php.ini's or anything else. It works perfectly for as long as you 
> have file upload on in php.ini (of course). Read the comments in 
> include/modules/story/Story_base.class of the phpslash-dev cvs module.
> NOTE: that makes me wonder if there is a way to use Oxygen to generate 
> documentation for php source code the same way that it's used for C++? We 
> should have documentation for the developers as well as for regular 
> users... just a thought...
> 

So far this is what we've  got:

	http://phpslash.sourceforge.net/phpdoc/phpslash-ft/

I'll add one for the -dev tree up soon.


A developer's reference has been started, but not worked on much.  It's in
the doc directory or online:

	http://phpslash.sourceforge.net/doc/psldeveloper.html

> >Would be also useful to allow folks to turn on/off modules through the
> >web interface rather than through the config.ini.php
> 
> Wonderful idea. The problem would be where to put the config.ini.php then 
> so that it's writeable by the user that runs the webserver or in the 
> database itself. Maybe we should get rid of the file config.ini.php 
> altogether and put this whole file in a compressed format into a record in 
> the database... gzip compression is done on the fly these days, why not 
> take advantage of that. We could even use jp_cache to cache it for X number 
> of minutes... Joe?
> 

Matthew was working on getting the PSL array sessionized some.  


A couple of other wishlist items - webmin module ( perl based), a debian
package.

Joe

> >Also, we had talked about an installer in the past for psl/be..
> >Wondered if you had a chance to check out Back-End's new installer
> >script.  Makes an installation pretty quick.
> 
> The script is written in php and runs as a cgi? or is it a Perl script? I 
> did a setup.php script for parsing the config-dist.ini.php file so that 
> users can edit it in their browsers and save this file to a file in their 
> workstations for then uploading that to whatever server they will use... 
> long procedure uh? but works.
>
> ----)(-----
> 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
> 

Re: [Phpslash-devel] embracing the future

[Peter C. <li...@cr...>]

On Sunday 26 Oct 2003 4:24 pm, Luis M wrote:

...

> People should really start trying phpslash-dev module from the cvs. It's
> pretty much "stable" enough right now to be used in replacement of
> phpslash-ft. But, remember that's the "experimentation" module. We should
> probably freeze it as it is right now and do a minor release based on it so
> that people can try it and we can get an idea of how the migration will be
> from -ft (current stable release) to -dev. From then on it will be downhill
> with -dev.

> Remember that -dev is fully modularized. Everything, every block, story,
> header behaves in this manner... Great level of "granularity" and also a
> scary thought that if something goes wrong, it might be hard to know from
> where the error is coming... that's why we need testing, to improve it to
> the point that we know for sure we are not missing anything and start
> replacing our own sites (first) with the minor release (fingers crossed)
> and deal with possible pitfalls.

I'm just starting a new project, so thought I'd use -dev. It's been a while 
since I used phpSlash, so I'm sort of coming at it fresh.

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 :-)

- it would be good if the templates were kept in the module directory too... I 
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)

- The CVS seems to be missing an install guide

- the last line of config.ini.php is not needed (the ?> element is 
automatically assumed by PHP)

- config.ini.php (or INSTALL) should make it clear that phplib needs to be 
downloaded separately

- not clear why config-dist.php isnt just config.php - that way you can get a 
working site by just editng config.ini.php. 

- Not sure what the point of the show_admin_on_navbar option is. The current 
note got me confused...

Apart from that, the install was pretty smooth.

Comments on the example data:

- it would be great if Home was section 1. Put that down to me being 
neurotic...

- 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).

- Perhaps the date on the 'Congratulations' article should be updated (it says 
4-Dec-2000 right now...)


HTH someone.
-- 
Peter

Re: [Phpslash-devel] embracing the future

[Luis M <le...@ho...>]

[snip]
>Back-End has added a wiki text editor mode and an implementation of
>htmlArea3 to psl's present options.  Giving users options is a good
>thing.  Adding an option for phorum-like syntax could be a useful option
>too.  For the wiki text we added an extra column for both the parsed
>html as well as the original wiki content.

Ok, I check the htmlarea3 site and I have to admit that it is impressive, 
but, maybe overkill. Also, it only works on IE and Mozilla version X and 
up... and to top it all off under BSD license...
I meant something simple like phpBB that only uses standard features. A way 
to turn of JavaScript should be somewhere in the users profile. But, you 
don't need the javascript part to edit with phpBB, that's just to make your 
life simpler. That way I could use Opera/Camino/Konqueror/Netscape 3/4/6/7 
and others from any computer without worrying about having different 
interfaces to edit the text.
Just my opinion. I respect people who would use htmlArea -- maybe they come 
from a Windows background and that interface is intuitive for them; however, 
for the majority of us, I think that interface is overkill -- bloated.

----)(-----
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

Re: [Phpslash-devel] embracing the future

[Luis M <le...@ho...>]

>I know nothing about the phpslash-dev site, but I am quite interested in
>offering what Back-End has learned/used for adding/editing documents.

People should really start trying phpslash-dev module from the cvs. It's 
pretty much "stable" enough right now to be used in replacement of 
phpslash-ft. But, remember that's the "experimentation" module. We should 
probably freeze it as it is right now and do a minor release based on it so 
that people can try it and we can get an idea of how the migration will be 
from -ft (current stable release) to -dev. From then on it will be downhill 
with -dev.
Remember that -dev is fully modularized. Everything, every block, story, 
header behaves in this manner... Great level of "granularity" and also a 
scary thought that if something goes wrong, it might be hard to know from 
where the error is coming... that's why we need testing, to improve it to 
the point that we know for sure we are not missing anything and start 
replacing our own sites (first) with the minor release (fingers crossed) and 
deal with possible pitfalls.

[snip]

>Why not give your users the option of entering/editing stories using the
>editing syntax that they choose?
>
>Back-End has added a wiki text editor mode and an implementation of
>htmlArea3 to psl's present options.  Giving users options is a good
>thing.  Adding an option for phorum-like syntax could be a useful option
>too.  For the wiki text we added an extra column for both the parsed
>html as well as the original wiki content.

I really don't know much about what BackEnd is. I guess I jumped in late in 
the phpslash-* discussions and didn't get the whole scope of it. I keep 
reading your posts relating to it, but I don't know anything about it. 
Besides the backend.php script in phpslash which I use for my syndicated 
news and Mozilla tabs.

[snip]

>htmlArea3 is pretty good..  There's even a spell check module.  The best
>thing is that it works in Mozilla & IE so I can actually test it.

Sounds like htmlArea3 is the way to go then... Giving users choices is 
great, but if we could simplify things and at least choose htmlArea3 to be 
the default and let users turn it off as they get better in using the 
phpslash interface. Powerusers should be able to go to their own profiles 
and turn on or off what they want or don't want. My concern is to make 
things super clear and super simple for those users who don't have the 
notion of how computer programs work -- or web interfaces for that manner. 
Users who simply have not been exposed to those conventions might not find 
certain things too intituitive when they first see it. I think, for 
instance, that php Phorum achieves this instantly. Once you install it and 
use it, you don't have to know how to do anything (i.e. read any manuals or 
help), so, users start instantly interacting with others in the site. As an 
example of this. I setup a Forum using Phorum (redundant sound uh?) here: 
http://foro.latinomixed.com. In my regular site, dealing with news and howto 
articles in general, users rarely register as new users or for the mailing 
list or anything. Whereas within days of activating the forum I got about 27 
users registered (and counting). In my case, my site aims at those who need 
help (non-power users) who are looking for ways to improve their computer 
knowledge. In reality, even power users benefit from having things simpler; 
that's why Linux users buy Mac laptops with MacOS X on them :-D

>I also like the idea of being able to just upload the html of a story
>rather than having to copy/paste it.

That has already been added to phpslash-dev and it works fine. I ported that 
from my own site which was based on phpslash-0.6.x and updated the code so 
that it works with php 4.1  and up -- the reason for this is that I'm using 
the _FILES array to avoid having users specifically changing their php.ini's 
or anything else. It works perfectly for as long as you have file upload on 
in php.ini (of course). Read the comments in 
include/modules/story/Story_base.class of the phpslash-dev cvs module.
NOTE: that makes me wonder if there is a way to use Oxygen to generate 
documentation for php source code the same way that it's used for C++? We 
should have documentation for the developers as well as for regular users... 
just a thought...

>Would be also useful to allow folks to turn on/off modules through the
>web interface rather than through the config.ini.php

Wonderful idea. The problem would be where to put the config.ini.php then so 
that it's writeable by the user that runs the webserver or in the database 
itself. Maybe we should get rid of the file config.ini.php altogether and 
put this whole file in a compressed format into a record in the database... 
gzip compression is done on the fly these days, why not take advantage of 
that. We could even use jp_cache to cache it for X number of minutes... Joe?

>Also, we had talked about an installer in the past for psl/be..
>Wondered if you had a chance to check out Back-End's new installer
>script.  Makes an installation pretty quick.

The script is written in php and runs as a cgi? or is it a Perl script? I 
did a setup.php script for parsing the config-dist.ini.php file so that 
users can edit it in their browsers and save this file to a file in their 
workstations for then uploading that to whatever server they will use... 
long procedure uh? but works.

----)(-----
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

[Phpslash-devel] Re: Phpslash-devel digest, Vol 1 #227 - 1 msg

[Mike G. <mi...@op...>]

On Fri, 2003-10-24 at 23:24,
php...@li... wrote:
> > 3. having a way to input data by using JavaScript or whatever is standard 
> > nowadays for all main browsers. again, we will need a way to turn this off 
> > for those who don't care, but for those of us who do, it's just a good 
> > thing to have. it works for Phorum...
> is htmlArea3 released?  If so, we should probably have this as an option
> or installed in one of the distributed skins.

Not yet, but it's pretty good:
	http://dynarch.com/htmlarea/

We incorporated this into Back-End as the default editor..  There's
still a bit of a problem with the full screen mode..  I think the CVS
has some other enhancements in it..   But it's pretty stable..

> I'm going to be working to install memcached (
> http://www.danga.com/memcached/) support into jpcache and slashDB.class.

Very cool!  I hadn't heard of this before..  

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Beads of Hope Campaign - http://uc.openconcept.ca/petition.php
Nonconformity is the highest evolutionary attainment of social animals -
Aldo Leopold

[Phpslash-devel] embracing the future

[Mike G. <mi...@op...>]

Hi Luis,

I know nothing about the phpslash-dev site, but I am quite interested in
offering what Back-End has learned/used for adding/editing documents.

On Tue, 2003-10-21 at 23:24, 
> 1. xml-rpc support: for things like transfering files from one computer to 
> the server and for posting stories in a "blog" kind of way using nifty tools 
> like gnome-blog and/or whatever other xml-rpc-compliant software the user 
> might choose. It's a matter of deciding:
>     a. what protocol to use
>     b. how to implement it in a way that can be easily turned on or off
>     c. having volunteers to work on this (Joe?, myself... etc...)
>     d. try not to reinvent the wheel (copy other GPL projects' ideas if 
> possible)

Well OK..  We've got no experience with this, but sounds great!

> 2. a consistent way to input text when creating new entries for stories, or 
> posting comments, etc... We talked about using Phorum-like syntax: 
> [url][/url] and the like, since that's very common nowadays on the internet.

Why not give your users the option of entering/editing stories using the
editing syntax that they choose?

Back-End has added a wiki text editor mode and an implementation of
htmlArea3 to psl's present options.  Giving users options is a good
thing.  Adding an option for phorum-like syntax could be a useful option
too.  For the wiki text we added an extra column for both the parsed
html as well as the original wiki content.

> 3. having a way to input data by using JavaScript or whatever is standard 
> nowadays for all main browsers. again, we will need a way to turn this off 
> for those who don't care, but for those of us who do, it's just a good thing 
> to have. it works for Phorum...

htmlArea3 is pretty good..  There's even a spell check module.  The best
thing is that it works in Mozilla & IE so I can actually test it.

> Comments anybody? Features I'm missing?

I also like the idea of being able to just upload the html of a story
rather than having to copy/paste it.

Would be also useful to allow folks to turn on/off modules through the
web interface rather than through the config.ini.php

Also, we had talked about an installer in the past for psl/be.. 
Wondered if you had a chance to check out Back-End's new installer
script.  Makes an installation pretty quick.

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Beads of Hope Campaign - http://uc.openconcept.ca/petition.php
Nonconformity is the highest evolutionary attainment of social animals -
Aldo Leopold

Re: [Phpslash-devel] embracing the future

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

On Tue, Oct 21, 2003 at 04:29:07PM -0400, Luis M wrote:
> 
> Hello,
> 
> After seeing the phpslash-dev module lag (and the -ft also) for a few 
> days/weeks, I gave careful thought to improving at least the -dev 
> dramatically and then use that to do new releases. Here are few of the new 
> dramatic ideas (which are not new per se, but needed in order to keep the 
> project current with what other projects are offering):
> (NOTE: order matters)
> 
> 1. xml-rpc support: for things like transfering files from one computer to 
> the server and for posting stories in a "blog" kind of way using nifty 
> tools like gnome-blog and/or whatever other xml-rpc-compliant software the 
> user might choose. It's a matter of deciding:
>    a. what protocol to use
>    b. how to implement it in a way that can be easily turned on or off
>    c. having volunteers to work on this (Joe?, myself... etc...)
>    d. try not to reinvent the wheel (copy other GPL projects' ideas if 
> possible)
> 

Sounds good.  I've had test xmlrpc servers and clients that could talk to
a few phpSlash methods, but no general wrapper to all functionality.

I think blogger-api, possibly wasabii.  I don't know enough about
phpgroupware's except I think their xml-rpca uth mechanism is something we need to look into.

We may also want to provide a xml-rpc API tailored especially for
phpSlash.

> 2. a consistent way to input text when creating new entries for stories, or 
> posting comments, etc... We talked about using Phorum-like syntax: 
> [url][/url] and the like, since that's very common nowadays on the internet.
> 

I'd like to have some kind of plug-in filters either at rendering time or
publishing to do this as well as other kinds of things like add annotation
to links showing the site like slashdot.

> 3. having a way to input data by using JavaScript or whatever is standard 
> nowadays for all main browsers. again, we will need a way to turn this off 
> for those who don't care, but for those of us who do, it's just a good 
> thing to have. it works for Phorum...
> 
> 

is htmlArea3 released?  If so, we should probably have this as an option
or installed in one of the distributed skins.

> Comments anybody? Features I'm missing?
> 
> Some research should go into finding why to use certain protocols for 
> blogging over the others, but, aside from that, I think these should be 
> just one baby step towards keeping phpslash future-proof (for now that is).
> 

Need to investigate use of SOAP too.  Maybe WebDAV down the line.


> P.S. as a side note, I will try to implement all of these and whatever else 
> in phpslash-dev and either commit them to a special area, say "contrib" or 
> allow it to be turned off by using the config file (turned off by default 
> of course). However, with help it will be done faster and we can just move 
> on to do a new release with these features.
> 
> 

I'm going to be working to install memcached (
http://www.danga.com/memcached/) support into jpcache and slashDB.class.

I also need to test a backport of the PEAR phplib changes into
slashTemplate.class ( and then maybe to phplib template.inc).


thanks,

Joe

> ----)(-----
> 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
> 

[Phpslash-devel] Re: Odd Problems with Comments

[Mike G. <mi...@op...>]

Hi Matthew,

the (array) function changed, but didn't resolve the problem with
lib.resources.php

> > > This refers to the following foreach in the
> > lib.resources.php
> > > >
> > > > >       foreach($requirements as $req) {
> > > You might could change this to
> > >           foreach((array)$requirements as $req) {
> 
> Made the change as outlined and get the warning shown below:-
> ===================
> Warning: in_array() [function.in-array]: Wrong datatype for second
> argument in /home/harbour/class/lib.resources.php on line 349
> 
> Warning: load_resource(Array) [function.load-resource]: failed to create
> stream: No such file or directory in /home/harbour/class/lib.resources.php
> on line 350
> 
> Warning: load_resource() [function.load-resource]: Failed opening 'Array'
> for inclusion (include_path='.:/usr/local/apache/php/lib/php') in
> /home/harbour/class/lib.resources.php on line 350
> ====================
> 
> The above is repeated a number of times! Don't know how far this gets us!
> 
> regards
> Rob
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Beads of Hope Campaign - http://uc.openconcept.ca/petition.php
Nonconformity is the highest evolutionary attainment of social animals -
Aldo Leopold