phpwebsite-developers — For our development team.

Re: [Phpwebsite-developers] htmlArea and phpWS

[George B. <gbr...@lu...>]

Good thought, but ... sigh.  The toolbar icons don't display properly in Mac
Mozilla 1.6.

On 8/11/04 4:35 PM, "Shaun Murray" <sh...@ae...> wrote:

> I'll add this one to the list as well...
> 
> http://www.fckeditor.net/
> 
> Looks very comprehensive. Doesn't work on Safari but nothing does until
> they implement contentEditable. It falls back nicely though. Works
> great in Firefox and pretty snappy to load.
> 
> Includes image upload and management as well.

______________________________________
George Brackett, Principal
George Brackett Associates
617 413 4316 / gbr...@lu...
http://www.luceatlux.com/gba/

Re: [Phpwebsite-developers] htmlArea and phpWS

[Shaun M. <sh...@ae...>]

I'll add this one to the list as well...

http://www.fckeditor.net/

Looks very comprehensive. Doesn't work on Safari but nothing does until 
they implement contentEditable. It falls back nicely though. Works 
great in Firefox and pretty snappy to load.

Includes image upload and management as well.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] htmlArea and phpWS

[George B. <gbr...@lu...>]

On 8/11/04 3:54 PM, "Shaun Murray" <sh...@ae...> wrote:

> At one point the candidate for inclusion was HyperTextArea which
> generated much more compact code than HTMLArea. See
> http://sourceforge.net/projects/hypertextarea/
> 
Apparently Matthew McNaney investigated it.  He told me it was buggy.  I
didn't play with it long enough to say one way or the other.

Re: [Phpwebsite-developers] htmlArea and phpWS

[Shaun M. <sh...@ae...>]

There's a whopping great big list of these tools at 
http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html and that's out of 
date. I bet everyone has their favourites.

At one point the candidate for inclusion was HyperTextArea which 
generated much more compact code than HTMLArea. See 
http://sourceforge.net/projects/hypertextarea/


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] htmlArea and phpWS

[Mike N. <mh...@us...>]

On Wed, 2004-08-11 at 12:40, George Brackett wrote:
> On 8/11/04 2:55 PM, "Mike Noyes" <mh...@us...> wrote:
> > Have you evaluated Kupu?
> > 
> I looked at it (at your suggestion), but couldn't figure out how to
> integrate it without more of a knowledge of JavaScript.  Since I had a leg
> up with htmlArea, I stayed with that.  What makes you so fervent about kupu?

George,
Integration shouldn't require javascript modification. Did you look at
the docs?

        http://codespeak.net/svn/kupu/trunk/kupu/doc/

Main reasons for advocating: Plone, Silva, and Lenya have standardized
on Kupu, and it makes use of css.

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

Re: [Phpwebsite-developers] htmlArea and phpWS

[George B. <gbr...@lu...>]

On 8/11/04 2:55 PM, "Mike Noyes" <mh...@us...> wrote:

> George,
> Did you report these issues to the htmlarea project?

I'm sure they're aware of the general issues, and the ones particular to
phpWS don't concern them directly.  But I've spent time mostly on the
interactivetools forum, where there's lots of discussion of issues,
including the popup window issue and the multiple textarea issue.
> 
> Have you evaluated Kupu?
> 
I looked at it (at your suggestion), but couldn't figure out how to
integrate it without more of a knowledge of JavaScript.  Since I had a leg
up with htmlArea, I stayed with that.  What makes you so fervent about kupu?

George

Re: [Phpwebsite-developers] htmlArea and phpWS

[Mike N. <mh...@us...>]

On Wed, 2004-08-11 at 11:14, George Brackett wrote:
> I am currently using hmtlArea 3.0 beta on a fairly large school site (phpWS
> 0.9.3-3), and applaud the idea that it might be incorporated in phpWS 0.9.4.
> I've had a few difficulties, though, and thought I'd note them for the
> record here.

George,
Did you report these issues to the htmlarea project?

        https://sourceforge.net/projects/itools-htmlarea/


> Some of the above can surely be overcome in a more extensive phpWS
> implementation; I have all the faith in the world in the development team!
> Others remain sticky.  But htmlArea is the best I've found, and I'm sticking
> with it, at least for the moment.

Have you evaluated Kupu?

        http://kupu.oscom.org/
        irc://freenode.net/%23kupu

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

Re: [Phpwebsite-developers] htmlArea and phpWS

[George B. <gbr...@lu...>]

I've actually used only the older www.phpwebsitemanual.com method for
installing htmlArea, not the one posted on January 22nd '04 that uses the
file loadhtmlarea.js.  The problem of multiple areas should still be there
using this approach, however.

On 8/11/04 2:14 PM, "George Brackett" <gbr...@lu...> wrote:

> 4.  I have not yet found a way to enable two text areas to be edited by
> htmlArea on the same page -- only one actually delivers its results on
> Submit.  And since the technique kindly supplied on www.phpwebsitemanual.com
> for installing htmlArea replaces ALL text areas on a page with htmlAreas if
> only one is desired, one is stuck not using htmlArea at all on pages with
> more than one text area.  (Sometimes you can replace one text area with a
> text field, but that requires modifying the module code, something I don't
> like to do.)  There's quite a bit of conversation about this problem on the
> forum at interactivetools, but no solution readily applies to phpWS in my
> opinion.

______________________________________
George Brackett, Principal
George Brackett Associates
617 413 4316 / gbr...@lu...
http://www.luceatlux.com/gba/

[Phpwebsite-developers] htmlArea and phpWS

[George B. <gbr...@lu...>]

I am currently using hmtlArea 3.0 beta on a fairly large school site (phpWS
0.9.3-3), and applaud the idea that it might be incorporated in phpWS 0.9.4.
I've had a few difficulties, though, and thought I'd note them for the
record here.
1.  Macintosh Mozilla (I know, you guys disdain Macs.  But my school has
lots of iBooks and I have a TiBook.) opens the various popups (text color,
for example) BEHIND the main window.  It takes a second click to show them.
2.  Mac Mozilla 1.6 crashes on editing text with an embedded image; 1.7
doesn't.  Who knows why.  I've simply disabled the image embedding control,
since most places it makes sense already provide for adding an image.
3.  The cut, copy and paste controls cannot be enabled in Mac Mozilla (and
maybe other versions too).  That's okay, really; people should use the key
controls anyway.
4.  I have not yet found a way to enable two text areas to be edited by
htmlArea on the same page -- only one actually delivers its results on
Submit.  And since the technique kindly supplied on www.phpwebsitemanual.com
for installing htmlArea replaces ALL text areas on a page with htmlAreas if
only one is desired, one is stuck not using htmlArea at all on pages with
more than one text area.  (Sometimes you can replace one text area with a
text field, but that requires modifying the module code, something I don't
like to do.)  There's quite a bit of conversation about this problem on the
forum at interactivetools, but no solution readily applies to phpWS in my
opinion.
5.  Only those modules which already employ the standard phpWS wysiwyg
buttons can have htmlArea installed by the technique mentioned above.
Adding htmlArea to other modules thus requires (minor) modifications to
module code.  (The essence is that the module must use
PHPWS_WizardBag::js_insert(), which normally inserts the JavaScript for the
regular buttons.)
6.  Any effort to customize or improve htmlArea requires an understanding
far exceeding mine of high-level object-oriented JavaScript.  I limp along
in PHP/MySQL and minimal JavaScript, so I don't know what to do when a
window opens behind, for example.

Some of the above can surely be overcome in a more extensive phpWS
implementation; I have all the faith in the world in the development team!
Others remain sticky.  But htmlArea is the best I've found, and I'm sticking
with it, at least for the moment.

George
______________________________________
George Brackett, Principal
George Brackett Associates
617 413 4316 / gbr...@lu...
http://www.luceatlux.com/gba/

Re: [Phpwebsite-developers] Edited Web Pages get published without approval

[Ryan R. <to...@gm...>]

On Wed, 11 Aug 2004 17:06:32 +0100, Shaun Murray
<sh...@ae...> wrote:
> On 9 Aug 2004, at 17:31, Julie J. wrote:
> 
> > I'm working on a large site for a private catholic highschool using
> > phpwebsite 0.9.3-3.  They need web pages created or edited by one user
> > (editor) to be approved by another (publisher) before getting
> > published.
> > I have the editor user set as an administrator, belonging to a group
> > with preferences all unchecked except for:
> >
> >  Web Pages
> >  Create Pages
> >  Edit Pages
> >  Delete Pages
> >
> >  which all have been checked.
> >
> >  When I create a new web page as an editor user I get told it has been
> > sent to the administrator for approval.
> 
> Really? I wouldn't have thought it would do that with 'Create Pages'
> checked? I would have thought they'd go straight through without
> touching the approval mod. Also with the editor set as 'Admin' I'd have
> thought they'd be able to get to the approval mod themselves.

Actually, the 'Pre-Approved'  permission is what allows it to go
through without sitting in the approval queue, Admin or not.

> 
> > However when I edit an exsisting page created by any user (including
> > the editor user) it gets saved to the database. This occurs in web
> > pages NOT set as a mainpage. Is this a bug or just not a feature? Or
> > am I missing something?
> >

No, I noticed this same issue.  As Shaun stated, this is a workflow
problem that I have decided to wait for 0.9.4 to hopefully eliminate. 
The major complication is that approval queues and change queues with
at least single layer rollback is complicated functionality in and of
itself, especially when you're having to touch several different
modules in the process.  Matt would have more insight on workflow
handling in 094.

> 
> I think you'll have to wait until there's some decent workflow and
> revision control in phpWebSite before it'll work fully as the current
> system is just a permission based system rather than forcing changes to
> go through Approval.
> 
> Incidentally team, if your listening, take a look at Bricolage -
> http://www.bricolage.cc/ which has very good workflow.
> 
> > I'd convert the web pages into articles for this functionality, but
> > there are already over at least 30 of them.
> >
> 
> Eloi added some revision control in the Article mod in the last
> version. It has a conversion script to convert existing pagemaster
> pages. I'm not sure if it'll solve the workflow problem though.
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>

Re: [Phpwebsite-developers] Edited Web Pages get published without approval

[Shaun M. <sh...@ae...>]

On 9 Aug 2004, at 17:31, Julie J. wrote:

> I'm working on a large site for a private catholic highschool using 
> phpwebsite 0.9.3-3.  They need web pages created or edited by one user 
> (editor) to be approved by another (publisher) before getting 
> published.
> I have the editor user set as an administrator, belonging to a group 
> with preferences all unchecked except for:
>
>  Web Pages
>  Create Pages
>  Edit Pages
>  Delete Pages
>
>  which all have been checked.
>
>  When I create a new web page as an editor user I get told it has been 
> sent to the administrator for approval.

Really? I wouldn't have thought it would do that with 'Create Pages' 
checked? I would have thought they'd go straight through without 
touching the approval mod. Also with the editor set as 'Admin' I'd have 
thought they'd be able to get to the approval mod themselves.


> However when I edit an exsisting page created by any user (including 
> the editor user) it gets saved to the database. This occurs in web 
> pages NOT set as a mainpage. Is this a bug or just not a feature? Or 
> am I missing something?
>

I think you'll have to wait until there's some decent workflow and 
revision control in phpWebSite before it'll work fully as the current 
system is just a permission based system rather than forcing changes to 
go through Approval.

Incidentally team, if your listening, take a look at Bricolage - 
http://www.bricolage.cc/ which has very good workflow.

> I'd convert the web pages into articles for this functionality, but 
> there are already over at least 30 of them.
>

Eloi added some revision control in the Article mod in the last 
version. It has a conversion script to convert existing pagemaster 
pages. I'm not sure if it'll solve the workflow problem though.

Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] add module default

[Don S. <do...@se...>]

You need to have a conf/menuman.php file for your module.

Don.

On 09:11 Tue 10 Aug     , Oosterhoff, Ton wrote:
>    A number of modules can be connected to a menu item by choosing 'add
>    module default' in menu manager. In menu manager you can choose from a
>    list of modules.
>    My question is, what makes modules appear in this list? For example, a
>    (great) 3rd party module like Mailinglists only appears on the
>    homepage and does not appear in this list.
>    How can I change (hack?) a module to make it appear in the list of
>    modules in menumanager under 'add module default'?
>=20
>    Ton Oosterhoff

--=20
Don Seiler
do...@se...

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7  207C 76AC 5DA2 FC87 F041

Re: [Phpwebsite-developers] add module default

[Matthew M. <ma...@tu...>]

Here's a good example.

http://res1.stddev.appstate.edu/horde/chora/co.php/announce/conf/menuman.php

Just put this file in your module's conf directory.
 
-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

Re: [Phpwebsite-developers] More phpWS and OOP

[Eloi G. <el...@re...>]

> I always thought blank lines between blocks of text was the best way 
> of indicating they are a separate block of text. Some people call them 
> paragraphs. Not sure it'll catch on though. ;-)


Wow.  There's an actual *name* for them?!?!
Note: For those who aren't sure if we're joking or not, I was more 
referring to those instances where you wanted your users to be able to 
make a sidebar that sticks to the right side with a company logo 
background/watermark and an image rollover as the title.  All they'd 
have to do is select that template and enter the text.

> It's a pity to have to make a section of users 'second class' by 
> implementing a solution that works for the majority of users but the 
> simple answer is
>
> a) switch javascript on
> b) Use Firefox


Naw, we're still back at square one because a lot of corporations 
prohibit the use of javascript on the company-mandated browser (usually 
IE).  My sitelogs show that most browsing is being done between 9-4 on 
Mondays through Fridays on the bosses' high-bandwidth line.  It's 
weird.  You can actually set your watch by looking at where users are 
logging in from.


> Then you're down to just the special cases of providing access for the 
> disabled and I can't imagine that a wysiwyg tool is any worse than the 
> textarea/buttons we have now.


I think it would be worse in the sense that the exsistence of a wysiwyg 
tool encourages people to use more markup, making a text version more 
unreadable.  Take a look at 
http://www.interactivetools.com/products/htmlarea/index.html#demo using 
FireFox.  Takes you a while to understand where to edit what.  A blind 
editor would be dealing with that all day long.

 

Re: xml-rpc / Atom API was: Re: [Phpwebsite-developers] More phpWS and OOP

[Mike N. <mh...@us...>]

On Tue, 2004-08-10 at 09:41, Shaun Murray wrote:
> The Atom API seems to be where everyone is heading and that apparently 
> will support image uploads embeded in the content but for the life of 
> me I can't make head nor tail of their docs. 
> http://www.atomenabled.org/

Shaun,
Yes, and an Atom IETF working group was just approved.

        http://www.ietf.org/html.charters/atompub-charter.html

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

Re: [Phpwebsite-developers] More phpWS and OOP

[Mike N. <mh...@us...>]

On Tue, 2004-08-10 at 05:20, Matthew McNaney wrote:
> > Maybe that is actually best served by a wysiwyg tool like 
> > htmlarea/hypertextarea as it looks like Word rather than them having to 
> > work out templates and sections.
> 
> We are trying to implement htmlarea within 0.9.4. It needs more testing
> but it appears to work well.

Matt,
It's unfortunate you weren't able to get Kupu to integrate smoothly. I
like the approach the kupu team is taking.

        http://kupu.oscom.org/

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs

xml-rpc / Atom API was: Re: [Phpwebsite-developers] More phpWS and OOP

[Shaun M. <sh...@ae...>]

On 10 Aug 2004, at 15:44, Eloi George wrote:
>
> Yes, I remember looking at the ones you'd suggested some time ago.  
> They didn't seem to support images without ftp'ing them up manually.  
> Whatever solution is used has to be integrated in such a way that the 
> module knows which pictures to delete/archive when it deletes/archives 
> the article.  Can you point me to one that does?  Or at least reports 
> where the pics were uploaded to?
>

Done some more digging.

Kung-Log has become ecto and now also runs on Windows as well. See 
http://ecto.kung-foo.tv/

The metaWebLog API supports image upload via this API 
http://www.xmlrpc.com/discuss/msgReader$2393
Full API at http://www.xmlrpc.com/metaWeblogApi

By all accounts it's quite horrible but Dave Winer's API's generally 
aren't regarded too highly. He's also responsible for RSS 2.0. It does 
however work and is supported by a large number of tools.

The Atom API seems to be where everyone is heading and that apparently 
will support image uploads embeded in the content but for the life of 
me I can't make head nor tail of their docs. 
http://www.atomenabled.org/

There are however a couple of good articles on xml.com.

http://www.xml.com/pub/a/2003/10/15/dive.html - a nice overview of 
pervious apis used and why Atom is the dogs danglies.

http://www.xml.com/pub/a/2004/04/14/atomwiki.html - Atom added to a 
wiki. It's obviously still not without problems.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] More phpWS and OOP

[Shaun M. <sh...@ae...>]

On 10 Aug 2004, at 15:44, Eloi George wrote:
>
> Well, that and to allow easy layout of entire blocks of text without 
> showing the underlying html, but your statement of the problem is 
> correct.  We have to find a way to shield the user from having to 
> learn (or look at) any form of markup language.
>

I always thought blank lines between blocks of text was the best way of 
indicating they are a separate block of text. Some people call them 
paragraphs. Not sure it'll catch on though. ;-)



>> Maybe that is actually best served by a wysiwyg tool like 
>> htmlarea/hypertextarea as it looks like Word rather than them having 
>> to work out templates and sections.
>
>
> I just looked at that again.  I like it, but I'm still worried about 
> non-jscript (or browser-) compatible users being exposed to all that 
> underlying markup.  Maybe I'm making too big a deal out of it -- I 
> mean, what's the odds of a sight-disabled user having to edit an 
> article created by someone who likes to "put lots of pretty colors" in 
> the text?
>

It's a pity to have to make a section of users 'second class' by 
implementing a solution that works for the majority of users but the 
simple answer is

a) switch javascript on
b) Use Firefox

Then you're down to just the special cases of providing access for the 
disabled and I can't imagine that a wysiwyg tool is any worse than the 
textarea/buttons we have now.

>
>> MacIE is a dead product anyway.
>
> I've been saying that about Macs in general for years.   People still 
> keep buying the damn things.

Yep. More this year than they did last year. Then again, there's more 
people buying Windows than they did last year also. :-(

>> Oh, and I forgot one of the points whilst I was typing. IME the 
>> easiest method for newbies is to remove the editing of pages from the 
>> browser completely and give them a client side app and an XML-RPC 
>> blogger style editing interface. There's loads of really nice wysiwyg 
>> tools for layout outside the web. Adding XML-RPC onto announce, 
>> article and pagemaster for submitting pages would make a few of my 
>> users more than happy.
>
>
> Yes, I remember looking at the ones you'd suggested some time ago.  
> They didn't seem to support images without ftp'ing them up manually.  
> Whatever solution is used has to be integrated in such a way that the 
> module knows which pictures to delete/archive when it deletes/archives 
> the article.  Can you point me to one that does?  Or at least reports 
> where the pics were uploaded to?
>

KungLog. It's ace. Oh, you need a Mac. ;-)

AFAIK the blogger/metaweblog or whatever apis don't support picture 
uploads so all the offline tools do it by ftp. Maybe the newer Atom API 
does with newer blog software.



Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Re: Phpwebsite-developers digest, Vol 1 #678 - 1 msg

[Shaun M. <sh...@ae...>]

On 10 Aug 2004, at 14:56, Eloi George wrote:
> The last time I looked at a PageMaster installation (admittedly a long 
> time ago), it had a default template, but it didn't seem to have a way 
> to choose another one.

That was fixed quite a while ago. The problem was that the 'Edit Page 
Info' link that linked to where you selected the template, category, 
title etc was in the title of the box and if you didn't want 
'Pagemaster vx.x' in your box title you selected a default_empty 
boxstyle. The templates were changed to have the link inside the 
content area.

Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] More phpWS and OOP(HTML Area)

[Spiggy T. <sp...@vi...>]

>> MacIE is a dead product anyway.
>
> I've been saying that about Macs in general for years.   People still
> keep buying the damn things.

Hehe. MacIE and a Mac is a slightly different thing :)

> Use of htmlArea would certainly allow that to happen.

> Yes, I remember looking at the ones you'd suggested some time ago.  They
> didn't seem to support images without ftp'ing them up manually.
> Whatever solution is used has to be integrated in such a way that the
> module knows which pictures to delete/archive when it deletes/archives
> the article.  Can you point me to one that does?  Or at least reports
> where the pics were uploaded to?
>

there is an image manager/uploader addon available. its a bit buggy
though. we (here at work) are moving from devedit (commercial) to htmlarea
and we have a working addon thingy done, with http upload. the htmlarea
code is really nice to work with but you have to be up to par with
highlevel object oriented javascript code.

paivi
-- 
Give a man a match, and he'll be warm for a minute, but set him on fire,
and he'll be warm for the rest of his life. (Terry Pratchett)

Re: [Phpwebsite-developers] More phpWS and OOP

[Eloi G. <el...@re...>]

> Since the sections are mostly a way to manage and layout images 
> alongside text rather than to divide text into sections, the problem 
> is really to solve an easy way for newbies to insert and manage images 
> without knowing html.


Well, that and to allow easy layout of entire blocks of text without 
showing the underlying html, but your statement of the problem is 
correct.  We have to find a way to shield the user from having to learn 
(or look at) any form of markup language.

> Maybe that is actually best served by a wysiwyg tool like 
> htmlarea/hypertextarea as it looks like Word rather than them having 
> to work out templates and sections.


I just looked at that again.  I like it, but I'm still worried about 
non-jscript (or browser-) compatible users being exposed to all that 
underlying markup.  Maybe I'm making too big a deal out of it -- I mean, 
what's the odds of a sight-disabled user having to edit an article 
created by someone who likes to "put lots of pretty colors" in the text?

Hmm.  I just realized that I'm going to have to start callling the 
module "phpwsArticle Manager." [groan]

> MacIE is a dead product anyway.

I've been saying that about Macs in general for years.   People still 
keep buying the damn things. 

> Personally, I end up ftping my images up and typing in the html myself 
> and not using sections a lot of the time. Maybe there should be an 
> 'advanced' interface which just simply had a method of uploading 
> images and a simple 'click on the thumbnail' interface that inserted 
> the html at the cursor.


Use of htmlArea would certainly allow that to happen.

> Oh, and I forgot one of the points whilst I was typing. IME the 
> easiest method for newbies is to remove the editing of pages from the 
> browser completely and give them a client side app and an XML-RPC 
> blogger style editing interface. There's loads of really nice wysiwyg 
> tools for layout outside the web. Adding XML-RPC onto announce, 
> article and pagemaster for submitting pages would make a few of my 
> users more than happy.


Yes, I remember looking at the ones you'd suggested some time ago.  They 
didn't seem to support images without ftp'ing them up manually.  
Whatever solution is used has to be integrated in such a way that the 
module knows which pictures to delete/archive when it deletes/archives 
the article.  Can you point me to one that does?  Or at least reports 
where the pics were uploaded to?

Re: [Phpwebsite-developers] Re: Phpwebsite-developers digest, Vol 1 #678 - 1 msg

[Eloi G. <el...@re...>]

>That sounds like a very interesting approach.  But I don't quite understand,
>Eloi, what you mean by asking whether Pagemaster 'fully supports page
>templates now'.
>

The last time I looked at a PageMaster installation (admittedly a long 
time ago), it had a default template, but it didn't seem to have a way 
to choose another one.  The function of the page template is to lay out 
the sections, so if there's any tags you have to enclose the page in or 
non-section-specific information (like date published, category 
information, nav links, common javascript, etc.), that can all be 
specified here so you don't have to mess around with the various themes. 

>ultimately Pagemaster just strings all those sections (each sitting in a
>table) in a line down the page.  It's not clear to me how one would put that
>in a two-column layout without modifying the PageMaster code.
>

It strings the -html- in a line down the page.  The tags contained 
therein specifies how the sections will be laid out.

>  Most of the
>options I can think of for a series of section templates like the one you
>suggest would make individual templates sensitive to the proper use of other
>templates (e.g. one template starts a <div> and another finishes it).
>  
>
For the more complex layouts, yes. 

Re: [Phpwebsite-developers] More phpWS and OOP

[Matthew M. <ma...@tu...>]

> Maybe that is actually best served by a wysiwyg tool like 
> htmlarea/hypertextarea as it looks like Word rather than them having to 
> work out templates and sections.

We are trying to implement htmlarea within 0.9.4. It needs more testing
but it appears to work well.



Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu

[Phpwebsite-developers] add module default

[Oosterhoff, T. <ton...@dh...>]

A number of modules can be connected to a menu item by choosing 'add =
module default' in menu manager. In menu manager you can choose from a =
list of modules.
My question is, what makes modules appear in this list? For example, a =
(great) 3rd party module like Mailinglists only appears on the homepage =
and does not appear in this list.
How can I change (hack?) a module to make it appear in the list of =
modules in menumanager under 'add module default'?


Ton Oosterhoff

=20

Re: [Phpwebsite-developers] More phpWS and OOP

[Shaun M. <sh...@ae...>]

On 8 Aug 2004, at 21:28, Eloi George wrote:

>
> Personally, I think our collective coding time would be better spent 
> on quite a few other core class ideas than a universal section class.  
> There are only a very few possible uses for the page/section paradigm, 
> and I'm constantly looking for an easy-to-use, 
> non-javascript-intensive way to get away from it and still retain the 
> layout flexibility.
>

Oh, and I forgot one of the points whilst I was typing. IME the easiest 
method for newbies is to remove the editing of pages from the browser 
completely and give them a client side app and an XML-RPC blogger style 
editing interface. There's loads of really nice wysiwyg tools for 
layout outside the web. Adding XML-RPC onto announce, article and 
pagemaster for submitting pages would make a few of my users more than 
happy.

Shaun
aegis design - http://www.aegisdesign.co.uk