phpwebsite-developers

Re: [Phpwebsite-developers] Proposed changes for phpWebSite 1.5.2

[matt <ma...@tu...>]

Hi Olivier,

Welcome to the list.

Olivier Sannier wrote:
 > Blog conversion:
 > Take into account international characters in the content and summary

I'm not sure why this is not working. One of our German developers 
worked with me to get this functioning. I need more information please.

 > url for the key points to message instead of comments which does not 
work anyway.

I don't understand. The key url points to a function in blog called 
view_comments but it displays the blog entry. What does not work?

 > Set summary in the key, it is used by the RSS module.

Fixed.

 > Menu conversion:
 > Take into account the fact that not all keys are to elements of the 
webpage module.

I don't understand.

 > core/class/Init.php:
 > Take into account the fact that the ".UTF8" language Id might not be
 > installed

I have changed it to check for UTF-8, UTF8, or without. Be forewarned 
that having a non-utf8 locale could cause display problems.

 > Look for mo files in the /locale folder by default for all modules,
 > this makes life easier for translators/maintainers

I don't understand. The current file structure is 
/locale/en_US/LC_MESSAGES/modulename.po

If the mo file is moved to the locale directory, then there will only be 
one mo file for all languages. This would require each compiled mo file 
be named after its language. I don't have a huge problem with this but 
it seems to work as is, I haven't heard this from the other translators, 
and there doesn't seem to be much interest in maintaining translations 
as it is. If I can get more translators working with phpWebSite, I would 
be open to accommodating them.

 > .htacess
 > Add the RewriteBase directive, required on most servers

I was trying to get away from writing the .htaccess file but I realize 
this can cause problems. I will add the ability to Access.

 > mod/controlpanel/class/Link.php
 > Translation of label and description at runtime to allow language 
change after installation.
 >
 > mod/controlpanel/class/Tab.php
 >   Translation of tab title at runtime to allow language change after
 > installation.

I don't understand. You can change the control panel links in the module 
itself. You can't change the icons titles and descriptions but I could 
add the ability. I do not want to make them translate dynamically 
because they are saved in the database.


 > mod/blog/class/Blog.php
 >   Encode date/time in UTF-8 as month names may take accented
 > characters

The date/times are returned from strftime. When I change my language to 
German and set the date to March I get "März". It appears accented 
characters are working. What are you seeing?

 > If no content in the post, do not display the "read more" link

This is fixed. I also found a way to prevent FCKeditor from adding those 
blank paragraph tags.

 > mod/blog/class/Blog_User.php
 > Exclude sticky entries from "recent blog entries" block

Good plan. Added.

 > Sticky entries show up on every page.

I will add this to my list of things to do.

 > mod/users/class/Form.php
 > Replace spaces by non breaking spaces in the "Control Panel" link.

I'd prefer people style it with a white-space : no-wrap.

 > mod/rss/class/Channel.php
 > Encode the strings before output in the RSS file to avoid problems
 > with unrecognized entities.

UTF-8 encoding? I have added the ut8_encode to the view function but I'd 
like some more background on the results otherwise.

 > mod/alert/class/Alert_Item.php
 > mod/calendar/class/User.php
 > ...
 > trunk/mod/webpage/class/Volume.php
 >   Encode date/time in UTF-8

See note above in regards to Blog.

 > Modified templates to respect the following structure:
 >
 > <div class="box">
 >   <div class="box-title">
 >     <h1>{PAGE_TITLE}</h1>
 >   </div>
 >   <div class="box-content">
 >   </div>
 > </div>
 >
 > The modified templates are those ones:
 > blog/view.tpl
 > miniadmin/mini_admin.tpl
 > webpage/page/basic.tpl
 > webpage/page/prev_next.tpl
 > webpage/page/short_links.tpl
 > webpage/page/verbose_links.tpl

It is already there.

 > menu/menu_layout/basic/menu.tpl
 > related/bank.tpl
 > related/create.tpl
 > related/edit.tpl

Added classes.

 > users/usermenus/top.tpl

I am trying to move away from this format of menu. There is a new menu 
named css.tpl that allows for very specific theming.

Thanks for the information Olivier. In the future, I would suggest 
submitting bug reports and RFEs to Sourceforge.

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

Re: [Phpwebsite-developers] Proposed changes for phpWebSite 1.5.2

[Olivier S. <ob...@fr...>]

Hi again,

> Olivier Sannier wrote:
>  > Blog conversion:
>  > Take into account international characters in the content and summary
>
> I'm not sure why this is not working. One of our German developers 
> worked with me to get this functioning. I need more information please.
>   
The database content in my 0.10.2 site contains HTML entities, for 
accented characters in particular. If they are not decoded before being 
given to utf8_encode and PHPWS_Text::parseInput you will get wrongly 
displayed characters. I had to develop my own utility function to do 
this decoding properly.
The same issue goes for converting links in the menu conversion by the way.

>  > url for the key points to message instead of comments which does not 
> work anyway.
>
> I don't understand. The key url points to a function in blog called 
> view_comments but it displays the blog entry. What does not work?
>   
It shows the comments just fine, but it breaks the RSS feeds generator 
as the links are not accepted by the RSS validators I tried. And to me, 
it should show the post itself, not the comments.

>  > Menu conversion:
>  > Take into account the fact that not all keys are to elements of the 
> webpage module.
>
> I don't understand.
>   
In my menu items, I have links to items from the article module. And 
those URLs look just like links to items from webpage module. Hence the 
need to read the name of the module in the link and use it in the key 
creation, instead of a hardcoded "webpage" string.

>  > core/class/Init.php:
>  > Take into account the fact that the ".UTF8" language Id might not be
>  > installed
>
> I have changed it to check for UTF-8, UTF8, or without. Be forewarned 
> that having a non-utf8 locale could cause display problems.
>   
Yes, I know that, but it did not show up in my problems.

>  > Look for mo files in the /locale folder by default for all modules,
>  > this makes life easier for translators/maintainers
>
> I don't understand. The current file structure is 
> /locale/en_US/LC_MESSAGES/modulename.po
>
> If the mo file is moved to the locale directory, then there will only be 
> one mo file for all languages. This would require each compiled mo file 
> be named after its language. I don't have a huge problem with this but 
> it seems to work as is, I haven't heard this from the other translators, 
> and there doesn't seem to be much interest in maintaining translations 
> as it is. If I can get more translators working with phpWebSite, I would 
> be open to accommodating them.
>   
No, what I'm saying here is not to go against the 
"LC_MESSAGES/modulename.po" paradigm. What I changed is the place where 
this structure is looked for. Right now in the distribution, there is 
one "locale" folder per module and it is quite hard to find and maintain 
the modulename.po in so many folders. The proposed change is to simply 
look in the /locale/LANGUAGE/LC_MESSAGES/ folder first. This way it is 
possible to place all the .po/.mo files for all modules in the same folder.

>  > .htacess
>  > Add the RewriteBase directive, required on most servers
>
> I was trying to get away from writing the .htaccess file but I realize 
> this can cause problems. I will add the ability to Access.
>   
Thanks.

>  > mod/controlpanel/class/Link.php
>  > Translation of label and description at runtime to allow language 
> change after installation.
>  >
>  > mod/controlpanel/class/Tab.php
>  >   Translation of tab title at runtime to allow language change after
>  > installation.
>
> I don't understand. You can change the control panel links in the module 
> itself. You can't change the icons titles and descriptions but I could 
> add the ability. I do not want to make them translate dynamically 
> because they are saved in the database.
>   
Yes, I know. I changed the code to try to translate the content of the 
database, on the fly. Nothing is stored in the database, nothing is 
changed, it's just at runtime.

>  > mod/blog/class/Blog.php
>  >   Encode date/time in UTF-8 as month names may take accented
>  > characters
>
> The date/times are returned from strftime. When I change my language to 
> German and set the date to March I get "März". It appears accented 
> characters are working. What are you seeing?
>   
I'm seeing little squares and eaten characters because the accented 
character is output directly, without being encoded first. So the 
browser sees it and interprets it as the marker for a multi byte UTF 
character.

>  > If no content in the post, do not display the "read more" link
>
> This is fixed. I also found a way to prevent FCKeditor from adding those 
> blank paragraph tags.
>   
Excellent.

>  > Sticky entries show up on every page.
>
> I will add this to my list of things to do.
>   
If you want the code, I have it here.

>  > mod/users/class/Form.php
>  > Replace spaces by non breaking spaces in the "Control Panel" link.
>
> I'd prefer people style it with a white-space : no-wrap.
>   
Hum, good point indeed. I'll work with this in my own template. Might 
need to be in the default template though.

>  > mod/rss/class/Channel.php
>  > Encode the strings before output in the RSS file to avoid problems
>  > with unrecognized entities.
>
> UTF-8 encoding? I have added the ut8_encode to the view function but I'd 
> like some more background on the results otherwise.
>   
Oh, that's quite simple: Open the XML file generated by the RSS module 
and try to have a look at titles and summaries with UTF-8 encoded 
accented characters and HTML entities. You'll see that the XML file is 
not valid because of the entities. So what I had to do was to decode 
UTF-8, decode entities, restore line breaks via "<br>", encode XML 
special chars (<, >, &...) and finally encode in UTF-8. This way the RSS 
validates and is readable by all RSS readers.
I created a function for this and applied it to Title and Description 
for both the Channel and the Items

>  > users/usermenus/top.tpl
>
> I am trying to move away from this format of menu. There is a new menu 
> named css.tpl that allows for very specific theming.
>   
Ok. I'll look around when it comes out more publicly.

> Thanks for the information Olivier. In the future, I would suggest 
> submitting bug reports and RFEs to Sourceforge.
I was not sure how to go about this, especially because of the upcoming 
1.6 release. Let me know if you want me to add those bugs in the 
trackers at SourceForge.

Cheers
Olivier