phpwebsite-developers Mailing List for phpWebSite Content Management System (Page 19)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Passing this on if anyone is interested.
-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Are we going to do a 0.10.3 release and if so when?

If you're following the Changelog, there's been a lot of changes  
since 0.10.2, mostly added by myself getting as many patches that  
make sense or are easy enough to add from Sourceforge submissions.  
Thanks everyone for those.

I'd like to get one more change in so that Menu Manager has the same  
module/page allow system as Block Maker got  last week. Should get  
that in in the next few days. Also, phpwsBB needs a bit more work  
after the v1.0.4 beta I announced last week and adding that in to a  
0.10.3 release would seem like a good idea. That might take a while  
as I'd like to back port the BBCode parser from fallout into  
phpwebsite 0.10.3 and ditch the PEAR BBCode class, which has fallen  
way out of date and contains numerous bugs. If someone else would  
like to pick up that task, then all the better.

The wysiwyg javascript code could do with an update too. Browsers  
have progressed quite a bit since it was written and IE, Firefox,  
Safari (which was always the laggard) and Opera all have pretty good  
javascript and DOM now for better inline editing at the cursor  
instead of adding to the end of the textarea. Alongside BBCode  
revisions, it'd be a good update, particularly for the forum mod. I'm  
no Javascript wizz though.

Are there any other patches, bugs or RFEs that either need to go in  
or that would be great additions?

Wendall - phpwsRSSFeeds converting international characters to  
HTMLEntities/XML is a major one for me and currently the module won't  
install from a scratch 0.10.2 install because it's installed before  
Menuman in the install sequence. You have to Boost it afterwards.

Changelog -

http://res.stddev.appstate.edu/cvs/phpwebsite/docs/CHANGELOG.txt? 
rev=HEAD&content-type=text/vnd.viewcvs-markup

(Everything from 24 October 2005 on is for the next release)

Looking ahead, I'm presuming we'll have a 0.10.4 release, but more  
than likely, that will be more maintenance led as more and more devs  
move over to Fallout and modules get converted or replaced. I'm sure  
the two will coexist for some time until it's as painless a process  
as possible to upgrade.

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

For those of you getting warnings on zero length templates,  
particularly in menuman.

I guess we should update the included phpWebSite PEAR libraries to  
include this latest fix. Note: this bug doesn't affect the Sigma  
engine used in Fallout.

Begin forwarded message:

> From: PEAR Bug Database <pe...@li...>
> Date: 17 February 2006 12:00:56 GMT
> To: sh...@ae...
> Subject: [PEAR-BUG] Bug #6084 [Opn->Csd]: fread now gives a warning  
> on zero length templates
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
> http://pear.php.net/bugs/bug.php?id=6084&edit=2
>
>
>  ID:               6084
>  Updated by:       pa...@ph...
>  Reported By:      shaun at aegisdesign dot co dot uk
> -Status:           Open
> +Status:           Closed
>  Id:               6084
>  Type:             Bug
>  Package:          HTML_Template_IT
>  Operating System: Linux
>  PHP Version:      4.3.11
> -Assigned To:
> +Assigned To:      pajoye
>  New Comment:
>
> This bug has been fixed in CVS.
>
> If this was a documentation problem, the fix will appear on
> pear.php.net by the end of next Sunday (CET).
>
> If this was a problem with the pear.php.net website, the change should
> be live shortly.
>
> Otherwise, the fix will appear in the package's next release.
>
> Thank you for the report and for helping us make PEAR better.
>
>
>
>
> Previous Comments:
> ---------------------------------------------------------------------- 
> --
>
> [2005-11-26 19:14:48] shaun at aegisdesign dot co dot uk
>
> Description:
> ------------
> The behaviour of fread changed recently in PHP so that it now
>
> gives a warning error when you read in zero length files.
>
>
>
> This change in behaviour has been fixed in the Sigma engine
>
> but not in IT.
>
>
>
> See
>
> http://pear.php.net/bugs/bug.php?id=4896
>
> ---------------------------------------------------------------------- 
> --
>
>

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

Sounds good. If there aren't any problems, go ahead and commit it to the
main distro.

On Wed, 2006-02-08 at 12:19 +0000, Shaun Murray wrote:
> One of the things that's always bugged me with phpWebSite was that if  
> you added a new module after you've selected all the modules in  
> 'Allow View' in blockmaker or menuman, the block/menu wouldn't appear  
> alongside the new module you added. I've been testing out a revised  
> blockmaker that solves this problem by having an 'all' setting.
> 
> I've also modified the interface somewhat and added the ability to  
> hide blocks from anon users and to show blocks alongside web pages also.
> 
> More details at http://www.aegisdesign.co.uk/announcement10.html
> 
> I'd appreciate comments on this and would of course love to see it  
> rolled into the main distribution. There's a number of modules with a  
> similar interface that could benefit from a unified approach. I can  
> do the same for menuman. phpwsRSSFeeds is the other one I know of  
> that already has the module/page selection happening.
> 
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> aegis hosting - http://www.aegishosting.co.uk
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

One of the things that's always bugged me with phpWebSite was that if  
you added a new module after you've selected all the modules in  
'Allow View' in blockmaker or menuman, the block/menu wouldn't appear  
alongside the new module you added. I've been testing out a revised  
blockmaker that solves this problem by having an 'all' setting.

I've also modified the interface somewhat and added the ability to  
hide blocks from anon users and to show blocks alongside web pages also.

More details at http://www.aegisdesign.co.uk/announcement10.html

I'd appreciate comments on this and would of course love to see it  
rolled into the main distribution. There's a number of modules with a  
similar interface that could benefit from a unified approach. I can  
do the same for menuman. phpwsRSSFeeds is the other one I know of  
that already has the module/page selection happening.

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

http://www.tranxactglobal.com/forum/showthread.php?t=866

These guys are who I use for a data centre in the USA. If there's  
anyone after a tech job in Atlanta then give them a try. Then if you  
get the job I can prod you on IRC if my phpWebSite installs are  
down. ;-)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.

It seems that php 4.4.1 has issues that create error messages similar to
php5.  Please see
https://sourceforge.net/forum/message.php?msg_id=3504295 .  The php4.4.1
issue appears to be a bug as reported on the Squirrelmail site.

It is known that the PEAR libraries cause the majority of grief with
phpWebSite on php5.  The module with the most problems is the calendar
modules--its just not usable.  What's note worthy here is that more
users and ISPs want to push to php5.  That can develop into a larger
satisfaction issue with phpWebSite.  I don't know if some of these
problems in phpWebSite can be addressed yet.  There may be more pressure
from users to do so.

Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDu0/mxyxe5L6mr7IRAtYQAJsF1Q9LCvpnRJKI0uOlerSupzH7mQCfUpgH
+P4xuM3P/H1p+KZiz1VsAxg=
=z3Dk
-----END PGP SIGNATURE-----

On 3 Jan 2006, at 13:19, Matthew McNaney wrote:

> Shaun,
>
> Happy New Year!
>
> I was fixing a bit of code in the Users module and I started getting
> some errors after I updated.
>
> show_link could not locate a help label 'approvals' for the 'users'
> module.
>
> I reloaded the help file but it didn't fix it. Could you take a look
> please?
>

Reloading works for me.

I've added in the extra code in boost/update.php to reload the help  
data.

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

Shaun,

Happy New Year!

I was fixing a bit of code in the Users module and I started getting
some errors after I updated.

show_link could not locate a help label 'approvals' for the 'users'
module.  

I reloaded the help file but it didn't fix it. Could you take a look
please?

thanks,
Matt

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shaun Murray wrote:
> Ensuring all posted form data comes from a browser and not a bot is
> another method used by some systems. Adding these into phpWebSite
> instead of into something like Apache's mod_security would be useful.

b2evolution also does check the referrer when a comment is submitted.,
and it has to be the comment page itself.

- --
Don Seiler
do...@se...

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7  207C 76AC 5DA2 FC87 F041
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDoHYKdqxdovyH8EERAm5LAJ4q1DyFHq7aWXW53Jn+SAxKSje7qACgpFh/
yPZ6aRhepzuCGn06QLOK08g=
=V0Qh
-----END PGP SIGNATURE-----

On 14 Dec 2005, at 14:29, Don Seiler wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Matthew McNaney wrote:
>> Adding the no-follow rel to a link is no problem. Of course the  
>> author
>> of the above link feels this will do little prevent spam.
>
> This is what b2evolution does, seems to have worked alright for me.

It didn't for me with an Advanced Guestbook install. I think that  
once your site is known, it doesn't make a difference. The trick is  
stopping yourself from being known and letting the spammer know what  
your site is running.

Googling for 'Powered by blah-blah vX.X' is how many of the spammers  
find a victim which is why I usually remove the attribution rather  
than any copyright thing. I've got mod_security rules on my servers  
to stop that for customers who use the more frequently spammed  
software without knowing what they are doing. phpBB is *THE* biggest  
culprit for spam and hackers and I really wish I could dissuade  
people from using it at all. YABBse gets close too and fixed less often.

The Advanced Guestbook install I had problems with now gets zero spam  
just because it now asks you to enter an extra field that the spambot  
doesn't know about, but that's not going to work for phpWebsite in  
general.

So, a captcha for registrations is a must.

A spam flood filter that stops new users from posting spam in quick  
succession?

Maybe have some kind of grace period / sin bin whereby new users go  
through approval and you can sin-bin existing ones if they abuse the  
site.

Engadget.com, TUAW.com and the other weblogs inc. sites let you post  
anonymously but every post has to be approved by clicking on an email  
sent to you. That seems to stop most spam.

Ensuring all posted form data comes from a browser and not a bot is  
another method used by some systems. Adding these into phpWebSite  
instead of into something like Apache's mod_security would be useful.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew McNaney wrote:
> Adding the no-follow rel to a link is no problem. Of course the author
> of the above link feels this will do little prevent spam.

This is what b2evolution does, seems to have worked alright for me.

- --
Don Seiler
do...@se...

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7  207C 76AC 5DA2 FC87 F041
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDoCxddqxdovyH8EERApwfAKCbrBAtu7O+mbHJbd+cHfsd2nfhrQCcDHfP
4Fx5YIY4T+FDVB4gFU1mth0=
=fSD1
-----END PGP SIGNATURE-----

I would like some suggestions of how we could prevent comment spam.

http://www.kuro5hin.org/story/2005/1/19/35627/2443

Adding the no-follow rel to a link is no problem. Of course the author
of the above link feels this will do little prevent spam.

So does anyone have other ideas? Off the top of my head without
considering the consequences - let users determine what is spam. If
enough different users vote on a user spamming, the comments module
could automatically disable their ability to post clickable links. This
decision could be reversed by the admin of course.

That is just one example. Any more ideas?

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

An interesting article on how to get people to solve CAPTCHA logins for
the spammer.

http://www.boingboing.net/2004/01/27/solving_and_creating.html

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

This is my response to a letter Shaun Murray sent me. I thought it may
interest the devs list so please comment. Thanks to Shaun for bringing
it up.
-----------------------------------------------------------------------

On Wed, 2005-12-14 at 10:27 +0000, Shaun Murray wrote:
> A while back you were playing around with captcha code to stop spammers.
> 
> Well, This guy reckons he can get past those...
> 
> http://sam.zoy.org/pwntcha/
> 
> You can upload test images to see if he can decode them.
> 

Well crap.

I have been using PEAR's implementation for Fallout. I haven't really
played with backgrounds or font alteration/deformation.

I went back and read the W3C recommendations.

I think there are two main reasons CAPTCHA is used:
1) To prevent brute force password guessing
2) To prevent comment spam

Perhaps we should address the problem directly.

1) Set a password limit. Go over that limit and the account is locked
and the ip logged.

2) Set a comment limit per user.

This would require:

1) Administrative attention for those who simply forgot their password.
To try and prevent this, a notice could appear:
"You have one more chance to enter your password. If you fail, your
account will be disabled. We suggest you use the 'Forgot my Password'
link."
I suppose it could also just email the user a link to unlock their
account.

2) Again possible admin attention. A good site user can easily go over
your "reasonable" limit. So, their limit would need to be raised
administratively. Alternately, the system would need some sort of logic
to approve them automatically. Nothing comes to mind that couldn't be
overcome with spam logic.

Now we _could_ stick with the CAPTCHA method and try to make it as crazy
as possible. Unfortunately, its inaccessibility bothers me.

I would like to have something in place before we ship instead of having
a wait and see attitude. This is assuming that 1.0 will be popular
enough for us to have to worry about it :)

Matt

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Just in case people are trying to run phpwebsite on php v5.1.0 and  
having problems with dates. IIRC we use PEAR's date class.

Note that 5.1.0 also breaks SquirrelMail according to the CPanel guys  
and some other well known scripts. Best stick with v4.3.11 still.  
HTTP_AUTH is apparently broken also.

Begin forwarded message:

> From: Ilia Alshanetsky <il...@pr...>
> Date: 28 November 2005 15:59:47 GMT
> To: php...@li...
> Subject: [ANNOUNCE] PHP 5.1.1 Released!
>
> The PHP Development Team would like to announce the immediate  
> release of
> PHP 5.1.1.
>
> This is a regression correction release aimed at addressing several
> issues that may cause issues for some applications. The main fixes
> found in this release include the following:
>
> * Native date class is withdrawn to prevent namespace conflict with
> PEAR's date package.
> * Fixed fatal parse error when the last line of the script is a PHP  
> comment.
> * eval() hangs when the code being evaluated ends with a comment.
> * Usage of \{$var} in PHP 5.1.0 resulted in the output of {$var}  
> instead
> of the $var variable's value enclosed in {}.
> * Fixed inconsistency in the format of PHP_AUTH_DIGEST between  
> Apache 1
> and 2 sapis.
> * Improved safe_mode/open_basedir checks inside the cURL extension.
>
> The full details of the changes in PHP 5.1.1 can be found here:
> http://www.php.net/ChangeLog-5.php#5.1.1
>
>
> PHP Development Team.
>
> -- 
> PHP Announcements Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

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

> Michael H. Rasmussen
> TechElephant
> said some good stuff about templating

There is very little html in the php code. If there is any, it means I was
lazy and need to check it :)

One thing I would like to ask of the community as we get close to 1.x is
to look at the style sheet in the default theme.

I am defining some style classes to be picked up by developers for use in
their style sheets. For example:
<div class="box">
  <div class="box-title">Title</div>
  <div class="box-content">Content</div>
</div>

The above is the new boxstyles. New themes don't have box templates, you
just define the box style depending on where in the theme it is located.

In other words, I would like feedback so that there is a concise and
useful set of definitions that developers can count on for their
templates. This will cut down on module style sheets and extra css classes
per module.

This can help XHTML compatiblity because it will keep the class
definitions lower plus with our default themes we can lead by example.

Thanks,
Matt

> I wasn't
> sure if there was interest by the devs and/or the community to get
> 0.10.x to validate as Strict.  Of course, this assumes there would be
> another 0.10.x release before 1.0.  Any thoughts?

I would like 1.x to be strict. 0.10.x will have to stand as is.

Matt

Hello Greg.

I would like to point out, that I think you are touching a very crucial
point when it comes to building the page content, seen from an
architectural point of view.

In an idealistic framework, all of the html code should come from the
template files. That would give the designers and theme developers the
opportunity to change every single html statement, without making
changes in the php files.

When I develop 3rd party modules, I try to get as much as possible of
the html code into the template files. Sometimes I find the need of
constructing some part of the html statements within my php file,
particularly when it comes to the top menu, anchor tags and image tags.

I think a far better solution would be if there was some core
functionality (like the Database.php class) I could call, which could
help me create the html code I need. That would remove the html code
inside my on module (besides the template files of course), and there
would only be one place to look, if for example the structure of the
anchor statement should be changed.

Besides construction simple html tags, the "html helper" could construct
more complex html structures like the top menu, which almost every
module use today. Another candidate could be the action part of a list
with the "show/hide | view | edit | delete" part.

Regards

Michael H. Rasmussen
TechElephant

> Hello all,
> 
> I've been spending the last few weeks working on my theme-making
> skills.   One thing I noticed during this adventure is that it is
> currently not possible to get the 0.10.x core to validate as XHTML
> Strict - only Transitional.  I discovered that tweaking templates only
> solved half the problem.  It took some tweaking of module php files
> before I got my personal site to validate as Strict.
> 
> I've been making notes along the way of what needs to be changed in
> the core.  Its not a complete list by far (as I don't use all the
> modules and I only validated the pages the public can see).  I wasn't
> sure if there was interest by the devs and/or the community to get
> 0.10.x to validate as Strict.  Of course, this assumes there would be
> another 0.10.x release before 1.0.  Any thoughts?
> 
> In addition, are there plans to make Fallout Strict compliant?  I
> think it should be.  The core should not prevent people from making
> their site Strict if they want it to be.
> 
> Regards,
> Greg Meiste
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 

-- 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew McNaney wrote:
> On Wed, 2005-11-02 at 15:12 +0000, Shaun Murray wrote:
> 
> 
>>Is there some way we could have both local versions and remote versions?
> 
> 
> Yes there could be local copies of the files. I would start by writing
> my documentation. Then we could have occasional wiki exports to replace
> these files.
> 

I like this idea but I think there are issues with it.

So depending on the level of "local" documentation, the user will still
post the same FAQ question on the forum over and over again.  They may
hit the local text file before the updated wiki file.

If there is a glaring issue with the "local" file, then how long will it
be before the "local" file is fixed and a new release has the needed
change?  Moreover, how long before the user upgrades to see the change?
 Most of phpWebSite users are not going to cvs co the latest text files.

Finally, for all intents and purposes I believe those local files will
not be updated.  If Matt has to choose between publishing code or
writing documentation verses conducting an on-site training at campus,
my bets are on the code and the on-site class.  The documentation slips
another week and then month and then year and then years.  That
shouldn't be taken as bashing Matt.  I think it reflects the reality of
corporate America. Matt will work on what pays the bills.  If I felt the
local files would be updated, then wouldn't these local files be updated
http://phpwebsite.appstate.edu/manual/html/bk01.html .  Those came
out--for 0.9.3 or so?  How long has it been since the existing text
files have been updated?

I agree that it is a good idea, but I don't think it will happen.  We
don't have the Apple dollars to risk diffusing the documentation effort
between a local and remote copy of the same documentation.

> 
> 
>>With sites for non-geeks, it's been very important to provide jargon  
>>free documentation and site specific documentation to get people  
>>using a site. Although the community wiki is excellent, it's  
>>sometimes too indepth for users.
> 
> 
> I have heard that as the argument FOR using Wiki instead of local docs. 
> People have read my docs and said I make too many assumptions on the
> ability of the reader.

Part of it may be the market Matt serves.  There's a world of difference
when you can put out a text file of minimal instructions, then walk down
the hall and help the Appstate campus user design a new theme.  Matt can
make those assumptions of the user because if the user he's standing in
front of doesn't get a concept, then Matt can go install the software
for them, for example.

I don't think that the depth is an issue.  If fact I see the opposite.
The depth is too much for someone like, Wendall911, mhnoyes, or
singletrack.  However, the wiki is filling the gap that the existing
text files don't cover. I use wiki pages URLs to use in forum posts to
answer the questions that the text file does not have.  That's the whole
point behind of this page
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=User_FAQ .
Please look at the history page here
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=User+FAQ&action=history&limit=100&offset=0
.  The FAQ points back to a pin point location for the user to solve
their problem.  Text files cannot do this.  I can instantaneously refine
documentation, create diffs, update "CVS", create FAQs with the press of
a wiki save button verses learn docbook, try to get the local catalog
straight, compile it, fix the tag errors, CVS update, learn another
docbook favorable editor, perform a unified diff, submit a bug or RFE
for the txt file change....  It looks like the User FAQ page alone has
had around 100 updates between Jan 30 and Oct 30 of this year.  Most of
the text files are were last updated circa version 0.9.3.

> 
> 
>>If we could allow a local tailored  
>>copy of the docs but provide pointers to online resources that would  
>>be very useful.
> 
> 
> I guess a setting for using local docs instead of wiki. Perhaps this
> should be a per document setting?
> 
> Thanks Shaun.
> 
> Any other suggestions or additions?
> 

Perhaps one final page to make the en_* concept more concrete.  Take a
look at this page
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Quick_Index
and imagine that is the language pages have a similar page.  This would
one would be en_*

Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDawgvxyxe5L6mr7IRAoWLAJ9bYE+rl66bADHEYqTo+L/XuMcRzQCgmZlV
fwGiUHi7govT0dVYoph0eU8=
=wGtF
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregory Meiste wrote:
> A few quick thoughts:
> 
> I thought "Fallout" was our code name for phpWebSite code still in
> development and that it was not specific to the 1.x code.  For
> example, phpWebSite 2.0 would be called Fallout when it is in
> development. (when can we expect this Matt?  ;-)
> 
> If that's true, should the wiki page really be called:
> http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout

This page will always be a quick and dirty how to install fallout page
regardless of the version.  It can be updated to 2.x whenever that
happens.  Perhaps the idea will be clear when you look at the bottom of
the install page
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Installation_Guide#Other_Installations
.  The installation type is called Beta Version Installations i.e.
[[fallout | Beta Version Installations]].  It will always be the fallout
page.

Here's the sample seed page for the 1.x version
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_database.
 Note mediawiki initcaps the title but you can still reference the page
as en_database or "en database" without the quotes.  Note that the
existing 0.9.x to 0.10.x will still be available here as
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Database_Configuration
.  I will borrow heavily from Database Configuration to add to the 1.x
en database page.

Note that the French page would be fr database.  That way the
application code won't have to worry about the using fr le database, etc.

> 
> Also, before we start putting links to the wiki in 1.x code, should we
> decide if we were sticking with Mediawiki or if we were finally going
> to change to the wiki module for phpwebsite?  The more places we put
> links to the wiki now, the more we will have to change if we ever
> convert the wiki in the future.

I recommended that the phpWebSite code use a constant of
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title= in one
place.  Hopefully the en_database name would be unchanged regardless of
the wiki engine used.  If the wiki changes to, say,
"http://phpwebsite.sf.net/wiki/index.php?title=" then just one location
in the code has to change.  The URL constant and the desired page are
concatenated to form the wiki link.

Guys I am fired up and ready to go for the 1.x release.  After I made
the fallout page last Sunday, I realized how close it was to consider
release issues.  I don't plan to update the existing pages for 0.10.x.
I really want to have documentation ready for the users by the time the
final 1.x release candidate hits the streets.  I believe I can have a
working en_* system by the end of this weekend.  Blindman, I don't see
those people who want all of the dog food to be eaten contributing to
the dog food documentation while you are coding.  I seeded the page here
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Wiki but no
one else is contributing.  Just as bitkeeper was used to fill a need
before git could self host the kernel or CVS was used until subversion
was ready, I want to use something now to get going on 1.x.  Again, the
fallout wiki page changed my course of action.  I don't plan on
answering many 0.10.x forum posts or create/edit any more 0.10.x wiki
pages.  Someone else needs to figure out the way of doing business with
the wiki engine, fatcat, and photoalbums.
> 
> Other than that, I like the idea of using the wiki as the
> documentation.  Much easier to keep up-to-date.
> 
Yep! Kind-of like giving users access to RoboHelp so that they can
change the F1 help key help documentation.

Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDawQpxyxe5L6mr7IRAqCnAJ0Z0SdYAmxPnAdUgMwbKmCNIp4nDQCfReya
001JSZjduYk3+LDyiPm11C4=
=PDeX
-----END PGP SIGNATURE-----

Hello all,

I've been spending the last few weeks working on my theme-making
skills.   One thing I noticed during this adventure is that it is
currently not possible to get the 0.10.x core to validate as XHTML
Strict - only Transitional.  I discovered that tweaking templates only
solved half the problem.  It took some tweaking of module php files
before I got my personal site to validate as Strict.

I've been making notes along the way of what needs to be changed in
the core.  Its not a complete list by far (as I don't use all the
modules and I only validated the pages the public can see).  I wasn't
sure if there was interest by the devs and/or the community to get
0.10.x to validate as Strict.  Of course, this assumes there would be
another 0.10.x release before 1.0.  Any thoughts?

In addition, are there plans to make Fallout Strict compliant?  I
think it should be.  The core should not prevent people from making
their site Strict if they want it to be.

Regards,
Greg Meiste

On Wed, 2005-11-02 at 15:12 +0000, Shaun Murray wrote:

> Is there some way we could have both local versions and remote versions?

Yes there could be local copies of the files. I would start by writing
my documentation. Then we could have occasional wiki exports to replace
these files.

> With sites for non-geeks, it's been very important to provide jargon  
> free documentation and site specific documentation to get people  
> using a site. Although the community wiki is excellent, it's  
> sometimes too indepth for users.

I have heard that as the argument FOR using Wiki instead of local docs. 
People have read my docs and said I make too many assumptions on the
ability of the reader.

> If we could allow a local tailored  
> copy of the docs but provide pointers to online resources that would  
> be very useful.

I guess a setting for using local docs instead of wiki. Perhaps this
should be a per document setting?

Thanks Shaun.

Any other suggestions or additions?

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

On 2 Nov 2005, at 14:40, Matthew McNaney wrote:

>
> My thought is that the config file would determine where the help  
> would
> be located. That way people could use mirrors, their own wiki, or
> whatever.

Is there some way we could have both local versions and remote versions?

Like in Apple's help system where it lists the local copy first and  
below that any relevant articles on Apple's support site.

With sites for non-geeks, it's been very important to provide jargon  
free documentation and site specific documentation to get people  
using a site. Although the community wiki is excellent, it's  
sometimes too indepth for users. If we could allow a local tailored  
copy of the docs but provide pointers to online resources that would  
be very useful.

And I'd vote for using out own software every time.

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

On Wed, 2005-11-02 at 08:20 -0600, Gregory Meiste wrote:
> A few quick thoughts:
> 
> I thought "Fallout" was our code name for phpWebSite code still in
> development and that it was not specific to the 1.x code.

Fallout will become phpWebSite when it completely replaces the current
software.

>   For
> example, phpWebSite 2.0 would be called Fallout when it is in
> development. (when can we expect this Matt?  ;-)

2 weeks after the release of 1.0.

> 
> If that's true, should the wiki page really be called:
> http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout
> 
> Also, before we start putting links to the wiki in 1.x code, should we
> decide if we were sticking with Mediawiki or if we were finally going
> to change to the wiki module for phpwebsite?  The more places we put
> links to the wiki now, the more we will have to change if we ever
> convert the wiki in the future.

My thought is that the config file would determine where the help would
be located. That way people could use mirrors, their own wiki, or
whatever. I just need the first format. I assume it would be something
like:

$url =
sprintf('http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=%
s', $filename);

> 
> Other than that, I like the idea of using the wiki as the
> documentation.  Much easier to keep up-to-date.

I agree.

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

2001	Jan	Feb (1)	Mar (265)	Apr (166)	May (25)	Jun (17)	Jul (20)	Aug (47)	Sep (6)	Oct (14)	Nov (66)	Dec (64)
2002	Jan (109)	Feb (64)	Mar (34)	Apr (23)	May (64)	Jun (9)	Jul (13)	Aug (6)	Sep (33)	Oct (272)	Nov (67)	Dec (75)
2003	Jan (264)	Feb (244)	Mar (171)	Apr (119)	May (54)	Jun (93)	Jul (51)	Aug (48)	Sep (14)	Oct (49)	Nov (47)	Dec (15)
2004	Jan (13)	Feb (27)	Mar (18)	Apr (44)	May (35)	Jun (24)	Jul (39)	Aug (142)	Sep (35)	Oct (34)	Nov (49)	Dec (24)
2005	Jan (60)	Feb (71)	Mar (19)	Apr (27)	May (68)	Jun (4)	Jul (30)	Aug (10)	Sep (23)	Oct (24)	Nov (13)	Dec (6)
2006	Jan (4)	Feb (46)	Mar (64)	Apr (18)	May (16)	Jun (37)	Jul (7)	Aug (19)	Sep (9)	Oct (8)	Nov (3)	Dec (23)
2007	Jan (25)	Feb (21)	Mar (32)	Apr (36)	May (12)	Jun (1)	Jul (7)	Aug (15)	Sep (13)	Oct (1)	Nov	Dec
2008	Jan (3)	Feb (5)	Mar (1)	Apr (2)	May	Jun (1)	Jul (2)	Aug (7)	Sep	Oct (5)	Nov (1)	Dec
2009	Jan (7)	Feb (1)	Mar	Apr	May (1)	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec (3)
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec

phpwebsite-developers Mailing List for phpWebSite Content Management System (Page 19)

phpwebsite-developers — For our development team.