phpwebsite-developers — For our development team.

[Phpwebsite-developers] More documentation and 0.10.3

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

Greg Kludge is back with more documentation!

http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_modules

Please take an opportunity to check out his work.

Also I would like to take a moment to thank Shaun, Michael, and Kenneth
for their work on 0.10.3. Lots of bug features and improvements.

Good work everyone. Thank you for your time and assistance.

Sincerely,
Matt

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

[Phpwebsite-developers] Re: phpWebSite face lift

[Michael H. R. <po...@mi...>]

> I'd personally prefer keeping H1 and H3 instead of introducing H2  
> into the templates as the title and sub title, as that will break  
> less themes and certainly it won't break my themes since I rely on  
> the templates containing H1 and H3. It's a long established tradition  
> I don't think we should change. I use sIFR replacement on H1 and H3 a  
> lot for instance so chaning to H2 will give me crap fonts again.

As I recall, I only changed the heading tag in the Skeleton module (I
really don't understand why H2 has been left out in the beginning). That
said I would never make such a change to any of the other modules. I am
well aware that such a change would result in a great impact, that would
affect sites like yours, running some sort of replacement for the
heading tags.


> You've introduced more tables. Generally, that's to be avoided. In  
> particular, in the comments module, it makes the form wider. Please  
> be aware that some users are using fixed width themes that may only  
> have room for narrow layouts of 400px. Creating forms which have the  
> label alongside the text entry causes problems for those themes. I  
> also think adding tables to layout forms is retrogressive.  
> Personally, I'd be inclined to use a definition list for form layout.

That's right, I have introduced more tables. But I have also removed
some, replacing them with div's. I am trying to go for a design where we
use tables for lists (a list of users, a list of links, a list of notes
etc.) and tables for input forms (add user, add link, add note etc.). If
you look across phpWebsite today you will see 2 different layout
standards for input forms: 1) labels and input fields are listed
vertical and 2) label and input field are listed horizontal in a grid
layout. In the second approach it is rather common to use a table to
construct the grid. Generally we should only use one approach, and I
have chosen to go for the grid layout. The last time this was discussed
I sensed a positive attitude for the grid layout, which is used in a
vast number of CVS designs today, and I certainly don’t find this to be
retrogressive.

I know lots of users a using a fixed width theme. That's why I have
added the style "formtable" to all of the input tables I have created,
and added the class "label" to the first column and "value" to the
second. Using those styles, it should be possible to style the input
forms so they doesn't break a fixed width layout.

I know the change to the comments module is not optimal. I worked with
this small input form for hours, trying different approaches. I finally
decided to stick with the grid layout, but if you could come up with a
more suitable design, please let me know.

If there is a great opposition against the grid layout in the phpWebSite
community, I will be happy to remove it, and change it to a vertical
look. Personally I find the grid layout to be more tempting and I feel
it has a more professional look. But this is my personal opinion, and if
the majority feels different, then I am more than willing to drop the
grid layout.


> If it can be avoided, I'd rather not use inline styles if we're  
> defining a set of classes now. Seems pointless.

Well not to me. I personally think that inline styles can be rather
useful. In an ideal world, I would have reworked the html design
entirely, causing all existing themes to be deprecated, but on the same
time added the ability for styling phpWebSite ala csszengarden. This is
however not a suitable approach. Like I mentioned in my previous mail,
my first priority was to ensure, that almost all of my changes would
work with older css files and those themes already developed to
phpWebSite. That's why I have used some inline styles, which mainly
replaces existing html attributes like valign, align and nowrap.


> I noticed you'd added 'datatable', 'label', 'value' and 'formtable'  
> classes. These need to be formalised and documented so that users who  
> may have defined them already in their own themes know they are used.  
> We shouldn't introduce CSS classes without defining a set that we're  
> going to stick with going forward in to Fallout. Saying that, I don't  
> know if Matt's defined a set yet for Fallout so now is possibly our  
> chance. :-)

I have introduced the classes you mention hoping that they can give
users and designers a more powerful way of styling phpWebSite. It is my
plan that I will try to update the majority of existing 0.10.x modules
to use the new styles. It is very important to me to stress out, that
the new styles are meant to be optional, and that I don't intent to
introduce more styles. Once again I would like to point out, that my
decision is due to the fact that I don't intend to completely rework the
existing design in 0.10.x. I will leave this to Matt and the upcoming
Fallout.

What I have seen in Fallout so far, Matt has given the user interface an
extensive new look and feel. Take the new controlpanel for instance,
with the tabbed interface and matching styles. I am a bit worried about
the consequences if we try to mix styles between 0.10.x and Fallout. I
believe that styling Fallout will be a whole new experience compared to
what we have been used to. I have no plans of revolutionize the look and
feel of 0.10.x, but only intend to give it a small face lift, trying to
achieve a more consistent design between the different modules.

In relation to the naming of the few styles I have introduced, I have
not come across those names in any of the existing modules or any 3rd
party modules. I hope and cross my fingers that it should be safe to go
with the new names.


I would like to say, that in my years of experience working with user
interface and html design, I have realised that this is one of the most
sensitive and controversial areas of developing software. I know that
some of my changes could cause a lot of commotion in the community, but
please keep in mind that I only plan to give phpWebSite a more
consistent look and feel. I do not plan change the overall look of
phpWebSite and I do not plan to introduce a table-less design.

- Michael (TechElephant)

[Phpwebsite-developers] Re: phpWebSite face lift

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

On 26 Feb 2006, at 19:56, Michael H=F8j Rasmussen wrote:

> Hi Shaun and Kenneth.
>
> This just to inform you about some changes I have made today to the
> phpWebSite user interface.
>
> Starting from the article I once wrote about consistent user =20
> interface in
> phpWebSite, and the following discussion in the community, I have =20
> started to
> give phpWebSite a small face lift. I have mainly tried to get a =20
> consistent
> look and feel across lists and input forms.
>
> My first priority was to ensure, that almost all of my changes =20
> would work
> with older css files and those themes already developed to =20
> phpWebSite. My
> second priority was to stay as close to the original layout as =20
> possible. My
> third and final priority has been to open up for some smarter and more
> powerful ways of styling phpWebSite.
>
> I think the most controversial decision I have made so far is the =20
> layout of
> the input forms. Hopefully it won't give to much excitement in the
> community.
>
> I know the release date for 0.10.3 is getting closer. I have only =20
> managed to
> update the templates for linkman, skeleton and users module. =20
> Skeleton is
> only for documentary purpose. I will try to look at the other =20
> modules the
> following days and see how far I get. I do not think we should wait =20=

> for a
> complete face lift of all modules before we release 0.10.3, but =20
> hopefully I
> can manage to get a couple of more modules in, before 0.10.3 is =20
> locked down
> for release candidate 1.
>

Michael, Just looking through these changes so far.

Moving as much html out of the php code as possible is a good idea.

I'd personally prefer keeping H1 and H3 instead of introducing H2 =20
into the templates as the title and sub title, as that will break =20
less themes and certainly it won't break my themes since I rely on =20
the templates containing H1 and H3. It's a long established tradition =20=

I don't think we should change. I use sIFR replacement on H1 and H3 a =20=

lot for instance so chaning to H2 will give me crap fonts again.

You've introduced more tables. Generally, that's to be avoided. In =20
particular, in the comments module, it makes the form wider. Please =20
be aware that some users are using fixed width themes that may only =20
have room for narrow layouts of 400px. Creating forms which have the =20
label alongside the text entry causes problems for those themes. I =20
also think adding tables to layout forms is retrogressive. =20
Personally, I'd be inclined to use a definition list for form layout.

If it can be avoided, I'd rather not use inline styles if we're =20
defining a set of classes now. Seems pointless.

I noticed you'd added 'datatable', 'label', 'value' and 'formtable' =20
classes. These need to be formalised and documented so that users who =20=

may have defined them already in their own themes know they are used. =20=

We shouldn't introduce CSS classes without defining a set that we're =20
going to stick with going forward in to Fallout. Saying that, I don't =20=

know if Matt's defined a set yet for Fallout so now is possibly our =20
chance. :-)

I've copied this to the developers list for further input.



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

Re: [Phpwebsite-developers] non-MySQL Database support in phpWebSite

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

On Tue, 2006-02-21 at 09:31 -0500, Jim Wilson wrote:
> Is 1.x another major rewrite compared to the current release(s)? How much module rework are we talking about?

Yes it is a major rewrite. It is over 3 years old.
I am hoping the module rework won't be too bad.

Modules I don't plan on rewriting for release are here:
http://res.stddev.appstate.edu/cvs/conversions/

PhotoAlbum is the only one at this point.

Here are the docs to convert an old module to work with the new core:
http://res.stddev.appstate.edu/cvs/fallout/docs/Converting_Modules.txt?rev=1.3

The good news is that once you convert, your old module gets all the
bells and whistles of the new core.

I have rewritten all the core modules as well as announcements (now
called Blog), Web Pages, Blocks, Fatcat (now just Categories), What's
Related, and I am in the middle of Calendar.

I have also written the conversion scripts to move the old data over:
http://res.stddev.appstate.edu/cvs/fallout/convert/modules/

I am working on the User conversion but got buried in the foundation
(i.e. users needs the alternate authorization to work properly, so I
reinstalled and noticed a problem with permissions, which had to do with
keys, which had to do with the Database class not performing joins well,
but I digress).

> Please
> let me know how things progress so that I can participate appropriately.

Thanks Jim. I know people have waited so long for 1.x that I can sense
eyerolls every time I say it will be out "soon". That said, it is
getting really close. There is still a lot of work to do but I feel a
release will be coming soon.

Developers out there can help me by testing, questioning, and writing
documentation to fill in the blanks.

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

Re: [Phpwebsite-developers] non-MySQL Database support in phpWebSite

[Jim W. <spi...@us...>]

> From: Matthew McNaney
> 
> > Does there continue to be any interest in making phpWebSite more portable in regards to databases?
> 
> Yes but in 1.x only. I once believed that the pear db class would take
> care of the incompatibilities. How young and naive I was. It wasn't
> Pear's fault as that is not what the class was meant to do.
> 

Makes sense.  Keep us up to date on progress then.  Is 1.x another major rewrite compared to the current release(s)? How much module rework are we talking about?

With my current time availabilty I'll need to wait until there's at least a chance of getting a maintainable site running with a few days effort before jumping in. Unfortunately, at the moment, this is only about producing results. Currently I am mostly working on a java/tapestry based project and cannot afford to put a lot of time into a side project that won't be usable for a year. Please let me know how things progress so that I can participate appropriately.

Thanks,

Jim Wilson

Re: [Phpwebsite-developers] non-MySQL Database support in phpWebSite

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

It would also be useful if we could find out from the DB class which  
DB we're using so that we can automatically use features of MySQL  
that aren't in PostgreSQL for instance, and even which version.

For instance I might want to use UPDATE LOW_PRIORITY for stats  
gathering which MySQL has but PostgreSQL doesn't. At the moment  
there's a config option in phpwsBB to select this.



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

Re: [Phpwebsite-developers] non-MySQL Database support in phpWebSite

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

> Does there continue to be any interest in making phpWebSite more portable in regards to databases?

Yes but in 1.x only. I once believed that the pear db class would take
care of the incompatibilities. How young and naive I was. It wasn't
Pear's fault as that is not what the class was meant to do.

Fallout (1.x) has been programmed and tested with both MySQL and
PostgresSQL.  What I have tried to do is make the installation sql as
vanilla as possible. There are developer guidelines in place to prevent
incompatibilities (table and column name character limits, no walking
case, etc.).
The database class in Fallout will also identify the DB OS and attempt
to "fix" the query before it is put into the database.

Once (if) people start using 1.x, I hope developers will identify what
other databases need to work.



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

Re: [Phpwebsite-developers] non-MySQL Database support in phpWebSite

[Greg M. <drk...@co...>]

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

Jim Wilson wrote:
> <note>
> This was submitted to the list a while back and for some reason (probably a local issue) it did not go through.  Here it is again with a few minor edits.
> </note>
> 
> Does there continue to be any interest in making phpWebSite more portable in regards to databases?
> 
> Originally I was drawn toward phpWebSite for its features and a statement somewhere that it would work with PostgreSQL.  On
> closer examination I found that it did not,  but read somewhere else that it would with minor modifications.  As it turned out the
> modifications were minor, but involved changes on many lines of code.

The problem appears from developers using tools like phpmyadmin to
extract a .sql file for a module.  The tool is a great aid in the
development process but it has some drawbacks. phpmyadmin tacks on
quotes that make the create statement fail on postgresql.  Postgresql
and Oracle then treat these column and table names as mixed case.  If
the double quotes are removed, then they are created as uppercase in the
database.  You can send an undoublequoted table name like MyTableName
and both Oracle and Postgresql will use MYTABLENAME and find the correct
table.

Moreover, these phpmyadmin scripts then create index clauses between the
last column definition and the closing );  MySQl must create these in a
non-standard way.  If the index clauses are moved to table alter
statements after the create table statement, then that makes the .sql
file more portable.

The other problem is that Postgresql and Oracle allow only 32 chars for
a table name whereas mysql allows for 100 or so.  So what is the SQL
standard? Once you add a table prefix, and one for the module,mod_ to a
long table name along with its supporting PEAR autonumber table, then
the 32 char table name limit can be exceeded very quickly.  If Oracle
support is desired, then some of the phpWebSite tables create more than
one text column where a smaller varchar column would work.  Oracle
converts these mysql text columns to their long column format.  Oracle
limits one long column per table because the LONG column supports 2gig+
in characters.  Here's another post with examples
http://sourceforge.net/mailarchive/forum.php?thread_id=7340026&forum_id=34704
.

A 0.10.3 release is in the works.  I'd think that your patches would be
a good idea depending on how far the other developers want to take the
0.10.3 release.  I think I have read in these emails that Matt is
developing the next major release 1.0.0 or fallout on Postgresql.  That
in itself will provide your desired portability.  However, third part
module developers have to get the religion too.  Again I think your
patches would be great addition because the community would gain some
experience with postgresql installs on 0.10.3+ before fallout is released.

In addition, MySql may have added GIS support in 5.x.  I don't recall.
I think some slick business oriented phpWebSite modules could be
developed with PostGIS http://postgis.refractions.net/ .  GIS is not
just for business.  Some slick user modules could be developed too.  At
some point the PostGIS developers plan to submit PostGIS for OGIS
www.opengis.org/ certification.

Again, I'd say it would be a good idea but I do more documenting that
programming on this project.  What do the other developers feel?

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

iD8DBQFD92Txxyxe5L6mr7IRAhPWAJ9joxFO4enCoZQAlF3IEkLTWcUkRQCgmLRS
g7HdrmXadfA5Y+RDmiq4CcY=
=SFkK
-----END PGP SIGNATURE-----

[Phpwebsite-developers] non-MySQL Database support in phpWebSite

[Jim W. <spi...@us...>]

<note>
This was submitted to the list a while back and for some reason (probably a local issue) it did not go through.  Here it is again with a few minor edits.
</note>

Does there continue to be any interest in making phpWebSite more portable in regards to databases?

Originally I was drawn toward phpWebSite for its features and a statement somewhere that it would work with PostgreSQL.  On
closer examination I found that it did not,  but read somewhere else that it would with minor modifications.  As it turned out the
modifications were minor, but involved changes on many lines of code.

At this point I'm trying to decide if I should redo those changes against the latest CVS or if I should just move on and try and
find a project that is more inclined to really support Postgres (and others).

The decision for me really hinges on whether or not the project is willing to accept these modifications.  I've been using a
modified version phpWebSite on several sites for a couple years now with pgsql backends,  backporting some security related
patches as they
came up.  My goal is to run something more in line with phpWebSite releases that uses PostgreSQL.


>From memory, the following problem areas needed to be addressed and were included in the modificatoins I made:

1).  PostgreSQL folds SQL identifiers (table names, column names, index names, function names, etc) to lower case.  This causes a
problem mapping to case sensitive variables in phpWebSite that were coded with camel case.  There seems to be a few ways to
address the problem.

One way (the one I have been using) is to make all the column names and corresponding php class variables lower case.  Basically
I added some underscore characters where CamelCase was previously used (e.g. "AdminEmail" becomes admin_email).  The
main problem with that approach is the fact that the SQL standard is to fold identifiers to UPPER case.  So while this technique
makes both PostgreSQL (that folds to lower) and MySQL (that doesn't fold at all) work,  it would present problems for folks using
Oracle or other systems.

An alternative approach would be to quote all identifiers.  This can bring some of its own issues (e.g. MySQL not in ansi mode).

There are likely other ways of handling this issues,  but I'm willing to implement a fix that makes sense to people.

2).  The function Database::sqlGetIndex(tablename) is a problem because it it uses the "show index" command from MySQL.
  There is no easy fix here.  We either have to restrict modules to always using a primary key column called "id" or
have a way for modules to register primary key column names, either as a property in the data class (e.g. PHPWS_Item) or in some
global location like a database table.

In our local copy I have worked around this with a PostgreSQL method,  but I would lean toward just changing all the modules so
they use "id" for primary key and eliminating the use of sqlGetIndex in the standard modules.

3).  The "Archive" function in phatform uses mysql specific utilities.  Currently we are not using archive on our
sites.  The data dumps are automated daily and the forms so far are fairly static.  In general users are discouraged from messing
with form data and as a result they pretty much limit usage to getting web form submissions via email.  

In order to support multiple databases, we could probably just code recode this function for individual database dump utilties
and simply return a message when the configured database isn't supported for the archive option.


My best recollection is these were the only areas of trouble for getting PostgreSQL to work.  My apologies for the long email,
but I wanted to be specific about my intentions.  Basically I'm volunteering to submit some work,  but before proceeding I need to
find out if the folks at Appalachian State feel that what I'm describing is compatible with the current goals the phpWebSite
project.


Best regards,

Jim Wilson

Re: AW: [Phpwebsite-developers] phpWebSite 0.10.3

[Greg M. <drk...@co...>]

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

Yves Kuendig wrote:
> This same problem is also discussed here:
> http://www.phpwsforums.com/showthread.php?t=2891
> 
> I guess an incomplete install because of max_execution_time of 15 sec
> There is (also) for sure a problem with sessions.
> 
> Yves
<snip>

>>This guy left phpinfo.php available.  I have not had time to try and
>>investigate this error "Fatal error: Call to a member function on a
>>non-object" https://sourceforge.net/forum/message.php?msg_id=3582482 .
>>I used to think that this was a php 5 issue too but his web hosting
>>company is running php 4.4.2
>>http://jonathanhall205.co.uk/PHPSITE/setup/phpinfo.php .  It appears
>>more users are running into this version of php and there's some
>>problem
>>with the current version of phpWebSite.  Do you know if this kind-of
>>error has been addressed.  I asked Jon to provide more info on how he
>>installed phpWebSite in this environment.
> 
> 
> PHP 4.4 introduced a bunch of errors you'd normally only get in PHP5
> which is why I've stuck with PHP 4.3.11 on my servers. 4.4 breaks too
> many 3rd party scripts.  We'll have to get that working though.
> Anyone running the latest v4.4 want to step forward for testing
> purposes?


Sigh...

pfttttttttt....

and I walked away from the keyboard for 15 minutes  hehe.

Yves if you want you can have the privilege of smacking Jon around, then
please do so.  I checked to see if he posted the same question on
phpWebSiteManual.com.  Nope he just posted it in two forums.  ;-)  Ask
Jon how many people he felt entitled to waste their time?

Now looking at the glass as half full--the positive angle--this forum
post shows why I'd like to edit the .txt files and now add Shaun's idea
of a link on the first page of the initial site.  Gosh it almost looks
like I paid jjohall2000 to stage this error. :-)
* So I revised a portion of the install guide based on Jon's post
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=PhpWebSite_Installation#Review_Install_Messages--Step_9
* I can finally piece together where these "Call to a member function on
a non-object" error messages may originate.  Additional FAQs were
created that point to the step 9 page based on this forum post.
* It is my hope that editing the install.txt to point to both the
Installation guide and the FAQ page that users would be more successful
with their installs.  Note that the INSTALL.txt file was referenced in
the phpwsforums post
http://www.phpwsforums.com/showpost.php?p=15157&postcount=6 .  It looks
like the error was made during memory configuration and the number of
modules that were installed.  Thankfully,  Matt has changed the 1.0.0
code to only allow core installs.  You have to boost additional modules
later in fallout.
* Yep! The embellish boost module page
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Boost with
pretty screen shots is referenced in step eight
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=PhpWebSite_Installation#Select_Additional_Modules--Step_8
.  The boost page also references how to install a third party module. I
added this information hoping people would not install every module with
only 8 megs of php memory configured.

So what do you all think?
1. I sense there are some 4.4.x issues that need to be resolved and this
forum post is not a good example of 4.4.x issues.
2. I am still in favor of editing the .txt files to point to pages in
the wiki.  I used these .txt files as the original seed pages of many
parts of the wiki.  So it is hoped that the expanded wiki page provides
additional information and screen shots that the .txt files were never
designed to do.
3. I like Shawn's idea of placing a reference to wiki on a successfully
installed site.  But as we saw in this forum post we need to help users
who do not have expert installers taking care of their installation.
4. If you look at the number of FAQs that I have collected in the
install questions section of the FAQ, then I am wondering if references
to the wiki should be made in each step of the setup.php code
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=User_FAQ#Installation_Questions
.
5. Knowing that those proposed links would not be referenced nor
read--yes I see the glass as half empty now--then the "Go to my
installation" should be disabled if errors occur.  LOL  Look at the gif
Jon posted http://www.jonathanhall205.co.uk/phpwebsiteerror.GIF . The
screen shot shows "Go to my installation"An error occurred.  Yet, this
message may point to the difficulty in trapping all the errors.  The
error message was created after the link was created.

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

iD8DBQFD91Wsxyxe5L6mr7IRAlBQAJ9Q61bUUhg1XncPFiQ/jjY65tUcYgCfduYI
XyM7LDzTlTvts9oB3BhIU+E=
=FPVI
-----END PGP SIGNATURE-----

AW: [Phpwebsite-developers] phpWebSite 0.10.3

[Yves K. <ph...@fi...>]

This same problem is also discussed here:
http://www.phpwsforums.com/showthread.php?t=2891

I guess an incomplete install because of max_execution_time of 15 sec
There is (also) for sure a problem with sessions.

Yves


-----Ursprungliche Nachricht-----
Von: php...@li...
[mailto:php...@li...]Im Auftrag von
Shaun Murray
Gesendet: Samstag, 18. Februar 2006 14:25
An: php...@li...
Betreff: Re: [Phpwebsite-developers] phpWebSite 0.10.3



On 18 Feb 2006, at 07:34, Greg Morgan wrote:
> This guy left phpinfo.php available.  I have not had time to try and
> investigate this error "Fatal error: Call to a member function on a
> non-object" https://sourceforge.net/forum/message.php?msg_id=3582482 .
> I used to think that this was a php 5 issue too but his web hosting
> company is running php 4.4.2
> http://jonathanhall205.co.uk/PHPSITE/setup/phpinfo.php .  It appears
> more users are running into this version of php and there's some
> problem
> with the current version of phpWebSite.  Do you know if this kind-of
> error has been addressed.  I asked Jon to provide more info on how he
> installed phpWebSite in this environment.

PHP 4.4 introduced a bunch of errors you'd normally only get in PHP5
which is why I've stuck with PHP 4.3.11 on my servers. 4.4 breaks too
many 3rd party scripts.  We'll have to get that working though.
Anyone running the latest v4.4 want to step forward for testing
purposes?


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

Re: [Phpwebsite-developers] phpWebSite 0.10.3

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

On 18 Feb 2006, at 07:34, Greg Morgan wrote:
> This guy left phpinfo.php available.  I have not had time to try and
> investigate this error "Fatal error: Call to a member function on a
> non-object" https://sourceforge.net/forum/message.php?msg_id=3582482 .
> I used to think that this was a php 5 issue too but his web hosting
> company is running php 4.4.2
> http://jonathanhall205.co.uk/PHPSITE/setup/phpinfo.php .  It appears
> more users are running into this version of php and there's some  
> problem
> with the current version of phpWebSite.  Do you know if this kind-of
> error has been addressed.  I asked Jon to provide more info on how he
> installed phpWebSite in this environment.

PHP 4.4 introduced a bunch of errors you'd normally only get in PHP5  
which is why I've stuck with PHP 4.3.11 on my servers. 4.4 breaks too  
many 3rd party scripts.  We'll have to get that working though.  
Anyone running the latest v4.4 want to step forward for testing  
purposes?


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

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Greg M. <drk...@co...>]

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

Shaun Murray wrote:

>> I thought I'd test what is in CVS.  Are the files tagged for the next
>> release yet?  Are there any plans to run a few release candidates,  etc?
>>  I would be happy to run some tests on php5 and provide any  feedback if
>> that would help?
>>
> 
> Not yet, probably and yes it would although I think we're still at a 
> php5 impasse with PEAR.

Here's two forum posts that just came in:  I believe this one is a php 5
issue on MS Windows with all the modules installed
https://sourceforge.net/forum/message.php?msg_id=3582968 .  I can get
10.2 to install on 5 if I don't boost calendar.

This guy left phpinfo.php available.  I have not had time to try and
investigate this error "Fatal error: Call to a member function on a
non-object" https://sourceforge.net/forum/message.php?msg_id=3582482 .
I used to think that this was a php 5 issue too but his web hosting
company is running php 4.4.2
http://jonathanhall205.co.uk/PHPSITE/setup/phpinfo.php .  It appears
more users are running into this version of php and there's some problem
with the current version of phpWebSite.  Do you know if this kind-of
error has been addressed.  I asked Jon to provide more info on how he
installed phpWebSite in this environment.

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

iD8DBQFD9s36xyxe5L6mr7IRAv3aAKCGNGu2BwSlSGbu2TGE+uVyh7kQIgCfciMj
m15Rqzdb+1TOLSMpoT0cDeM=
=Cfue
-----END PGP SIGNATURE-----

Re: [Phpwebsite-developers] phpWebSite 0.10.3

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

On 17 Feb 2006, at 21:28, Greg Morgan wrote:
> Shaun Murray wrote:
>>
>> On 17 Feb 2006, at 14:13, Greg Morgan wrote:
>>
>>> The wiki has almost hit 150,00 page views at this point
>>> http://phpwebsite-comm.sourceforge.net/wiki/index.php?
>>> title=Special:Statistics
>>
>>
>> How about we link to the wiki in the text you get on the main page  
>> of  a
>> new installation? I almost always tell people where to go (ahem)   
>> after
>> I've done an install for them.
>
> Well that sounds good too.  But wouldn't the Default theme have to be
> modified to display the link?  In a core only installation all that  
> you
> have on the front page is the copyright at the bottom of the Default
> theme or are you thinking of another place to put a link?
>

No. Put it in the pagemaster install sql where we've got a link to  
the phpwebsite-comm already for themes.

> I thought I'd test what is in CVS.  Are the files tagged for the next
> release yet?  Are there any plans to run a few release candidates,  
> etc?
>  I would be happy to run some tests on php5 and provide any  
> feedback if
> that would help?
>

Not yet, probably and yes it would although I think we're still at a  
php5 impasse with PEAR.


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

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Greg M. <drk...@co...>]

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

Shaun Murray wrote:
> 
> On 17 Feb 2006, at 14:13, Greg Morgan wrote:
> 
>> The wiki has almost hit 150,00 page views at this point
>> http://phpwebsite-comm.sourceforge.net/wiki/index.php?
>> title=Special:Statistics
> 
> 
> How about we link to the wiki in the text you get on the main page of  a
> new installation? I almost always tell people where to go (ahem)  after
> I've done an install for them.

Well that sounds good too.  But wouldn't the Default theme have to be
modified to display the link?  In a core only installation all that you
have on the front page is the copyright at the bottom of the Default
theme or are you thinking of another place to put a link?

I thought I'd test what is in CVS.  Are the files tagged for the next
release yet?  Are there any plans to run a few release candidates, etc?
 I would be happy to run some tests on php5 and provide any feedback if
that would help?

Greg

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

iD8DBQFD9j/ixyxe5L6mr7IRAtieAJ4nH4PUQKK7iEwp34UnPV212reaJQCfaZHa
V9U8/TKbHyvQ/JgWaN/vsX4=
=PclN
-----END PGP SIGNATURE-----

Re: [Phpwebsite-developers] phpWebSite 0.10.3

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

On 17 Feb 2006, at 14:13, Greg Morgan wrote:

> The wiki has almost hit 150,00 page views at this point
> http://phpwebsite-comm.sourceforge.net/wiki/index.php? 
> title=Special:Statistics

How about we link to the wiki in the text you get on the main page of  
a new installation? I almost always tell people where to go (ahem)  
after I've done an install for them.


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

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Verdon V. <ve...@ve...>]

On 17-Feb-06, at 9:13 AM, Greg Morgan wrote:

> I haven't decide yet which is easier programming or writing
> documentation.  ...

LOL. Programming for sure :)

I've got a friend who makes a very good living writing software 
manuals. I wouldn't want his job for the world!

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Verdon V. <ve...@ve...>]

On 17-Feb-06, at 8:52 AM, Shaun Murray wrote:

>
> On 17 Feb 2006, at 13:42, Verdon Vaillancourt wrote:
>>
>> When EZform::saveImage() is used in conjunction with 
>> PHPWS_File::makeThumbnail() to resize the original image and 
>> overwrite it on upload -- as is used in a couple of my modules, as 
>> well as my already committed patch to Announcements, and possibly 
>> others -- there can be an unexpected result if the image being 
>> uploaded has an uppercase extension. This happens because 
>> EZform::saveImage() essentially leaves the filename alone while 
>> PHPWS_File::makeThumbnail() converts the extension to lowercase. The 
>> end result is that 'Image.JPG' gets passed to the image data array 
>> that is saved to the db, while the actual final resized image on the 
>> server is named 'Image.jpg', leading to problems on a case-sensitive 
>> filesystem.
>>
>> My suggestion would be to do something like have EZform::saveImage() 
>> convert filenames to lowercase, or some such thing, and I'm willing 
>> to do it. I just have been too busy and haven't had much time to do 
>> more than a cursory evaluation of the cause/effect.
>
> There was a similar issue with photoalbum a while back which would let 
> through filenames with illegal characters for the file system. eg. on 
> a Mac you can pretty much have anything including quotes, 
> international characters and spaces but not so on Linux. I added in a 
> function to convert the filename to a safe filename based on some code 
> from php.net. Maybe have a look at that and see if it could be 
> expanded.
>
Ya, I was glancing at that filename to safe bit, and thinking along 
those lines too. I am mighty busy, so don't wait for me if you want to 
go, but I will try to have a look at EZform::saveImage() this weekend 
and see if it can't be tweaked a bit.

verdon

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Verdon V. <ve...@gm...>]

On 17-Feb-06, at 9:13 AM, Greg Morgan wrote:

> I haven't decide yet which is easier programming or writing
> documentation.  ...

LOL. Programming for sure :)

I've got a friend who makes a very good living writing software 
manuals. I wouldn't want his job for the world!

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Greg M. <drk...@co...>]

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

Shaun Murray wrote:
> Are we going to do a 0.10.3 release and if so when?
> 
> Are there any other patches, bugs or RFEs that either need to go in  or
> that would be great additions?

I'd like to submit patches for the some of the .txt files before the
0.10.3 release. I'll have them ready over this weekend.  I now have an
extensive list of FAQ questions
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=User_FAQ .
The original INSTALL.txt has morphed into this page
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=PhpWebSite_Installation
. Other install areas are covered here too
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Installation_Guide
.  Most all of my responses in the forums are here look at this page.
It has already been written.  I am hoping people might see links in the
.txt files and find their answer there--I did say hope.  ;-)

I haven't decide yet which is easier programming or writing
documentation.  I find it amazing that after a year's time I am still
trying to revise documentation into some cohesive manuscript.  Gasp! I
haven't really moved on to 1.0.0 pages like I wanted to last November.

The wiki has almost hit 150,00 page views at this point
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Special:Statistics
.

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

iD8DBQFD9dn/xyxe5L6mr7IRAnTZAJwMjZScn/VBB0hfgKDM3W9srd5VBACdEOLD
XW27qYhvVdegfVRWebJskio=
=JD1C
-----END PGP SIGNATURE-----

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Verdon V. <ve...@gm...>]

On 17-Feb-06, at 8:52 AM, Shaun Murray wrote:

>
> On 17 Feb 2006, at 13:42, Verdon Vaillancourt wrote:
>>
>> When EZform::saveImage() is used in conjunction with 
>> PHPWS_File::makeThumbnail() to resize the original image and 
>> overwrite it on upload -- as is used in a couple of my modules, as 
>> well as my already committed patch to Announcements, and possibly 
>> others -- there can be an unexpected result if the image being 
>> uploaded has an uppercase extension. This happens because 
>> EZform::saveImage() essentially leaves the filename alone while 
>> PHPWS_File::makeThumbnail() converts the extension to lowercase. The 
>> end result is that 'Image.JPG' gets passed to the image data array 
>> that is saved to the db, while the actual final resized image on the 
>> server is named 'Image.jpg', leading to problems on a case-sensitive 
>> filesystem.
>>
>> My suggestion would be to do something like have EZform::saveImage() 
>> convert filenames to lowercase, or some such thing, and I'm willing 
>> to do it. I just have been too busy and haven't had much time to do 
>> more than a cursory evaluation of the cause/effect.
>
> There was a similar issue with photoalbum a while back which would let 
> through filenames with illegal characters for the file system. eg. on 
> a Mac you can pretty much have anything including quotes, 
> international characters and spaces but not so on Linux. I added in a 
> function to convert the filename to a safe filename based on some code 
> from php.net. Maybe have a look at that and see if it could be 
> expanded.
>
Ya, I was glancing at that filename to safe bit, and thinking along 
those lines too. I am mighty busy, so don't wait for me if you want to 
go, but I will try to have a look at EZform::saveImage() this weekend 
and see if it can't be tweaked a bit.

verdon

Re: [Phpwebsite-developers] phpWebSite 0.10.3

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

On 17 Feb 2006, at 13:42, Verdon Vaillancourt wrote:
>
> When EZform::saveImage() is used in conjunction with  
> PHPWS_File::makeThumbnail() to resize the original image and  
> overwrite it on upload -- as is used in a couple of my modules, as  
> well as my already committed patch to Announcements, and possibly  
> others -- there can be an unexpected result if the image being  
> uploaded has an uppercase extension. This happens because  
> EZform::saveImage() essentially leaves the filename alone while  
> PHPWS_File::makeThumbnail() converts the extension to lowercase.  
> The end result is that 'Image.JPG' gets passed to the image data  
> array that is saved to the db, while the actual final resized image  
> on the server is named 'Image.jpg', leading to problems on a case- 
> sensitive filesystem.
>
> My suggestion would be to do something like have EZform::saveImage 
> () convert filenames to lowercase, or some such thing, and I'm  
> willing to do it. I just have been too busy and haven't had much  
> time to do more than a cursory evaluation of the cause/effect.

There was a similar issue with photoalbum a while back which would  
let through filenames with illegal characters for the file system.  
eg. on a Mac you can pretty much have anything including quotes,  
international characters and spaces but not so on Linux. I added in a  
function to convert the filename to a safe filename based on some  
code from php.net. Maybe have a look at that and see if it could be  
expanded.

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

Re: [Phpwebsite-developers] phpWebSite 0.10.3

[Verdon V. <ve...@ve...>]

On 17-Feb-06, at 8:08 AM, Matthew McNaney wrote:

> On Fri, 2006-02-17 at 12:45 +0000, Shaun Murray wrote:

>> Are there any other patches, bugs or RFEs that either need to go in
>> or that would be great additions?
>
> None that I am aware of here at the university.
>

There is one that I just discovered recently and haven't put a bug 
ticket in for yet, as I hadn't had time to decide what recommendation 
to make...

The issue is...

When EZform::saveImage() is used in conjunction with 
PHPWS_File::makeThumbnail() to resize the original image and overwrite 
it on upload -- as is used in a couple of my modules, as well as my 
already committed patch to Announcements, and possibly others -- there 
can be an unexpected result if the image being uploaded has an 
uppercase extension. This happens because EZform::saveImage() 
essentially leaves the filename alone while PHPWS_File::makeThumbnail() 
converts the extension to lowercase. The end result is that 'Image.JPG' 
gets passed to the image data array that is saved to the db, while the 
actual final resized image on the server is named 'Image.jpg', leading 
to problems on a case-sensitive filesystem.

My suggestion would be to do something like have EZform::saveImage() 
convert filenames to lowercase, or some such thing, and I'm willing to 
do it. I just have been too busy and haven't had much time to do more 
than a cursory evaluation of the cause/effect.

best regards,
verdon

Re: [Phpwebsite-developers] phpWebSite 0.10.3

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

On 17 Feb 2006, at 13:08, Matthew McNaney wrote:

> On Fri, 2006-02-17 at 12:45 +0000, Shaun Murray wrote:
>> Are we going to do a 0.10.3 release and if so when?
>
> Yes we can release 0.10.3 when you are ready.

When we're ready it is then.

Or more likely, when phpwsBB is ready for me at least.


>
>> The wysiwyg javascript code could do with an update too.
>
> I agree but someone else will need to code this. I don't want to back
> port the Fallout system.
>


Nothing that complex. Just fix the cursor positioning so tags get  
inserted where the cursor is and the page doesn't jump. I think all  
the current browsers can now support detecting the cursor position in  
a textarea now.

Back porting the BBcode parser into parseInput() parseOutput() I  
think is moderately important though. phpwsBB, Wiki and maybe some  
others fall on the basis of bugs in the current implementation.


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

Re: [Phpwebsite-developers] phpWebSite 0.10.3

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

On Fri, 2006-02-17 at 12:45 +0000, Shaun Murray wrote:
> Are we going to do a 0.10.3 release and if so when?

Yes we can release 0.10.3 when you are ready.

> The wysiwyg javascript code could do with an update too.

I agree but someone else will need to code this. I don't want to back
port the Fallout system.

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

None that I am aware of here at the university.

I am very grateful for the work you folks have done tightening up
0.10.x. Since you are steering the ship, just let me or Kevin know when
you think an update is ready for release.

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