phpwebsite-developers — For our development team.

[Phpwebsite-developers] Wish-list for 1.x core

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

Hi all :)

I've been fiddling a bit trying to re-write some of my stuff for 1.x  
and have run into a couple walls in core. I'm not saying any of these  
things are wrong, just that they make it difficult for me to realize  
my vision for my mods. I wanted to start a bit of a wish-list of  
things that I need from core. I hope other developers might  
contribute to the list and Matt, if I say something really stupid,  
please correct me ;-)

In no particular order...

* Ability to choose categories in an anonymous submission, and  
therefore outside the mini-admin
* Configurable ability to protect/hide a mods public resources  
(uploaded images/files) from  File Cabinet
* Core image upload function (perhaps added to core/class/File.php)

Does anyone else have anything to add?

Very best regards,
verdon

Re: [Phpwebsite-developers] Happy New Year!

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

On 2-Jan-07, at 2:28 PM, Matthew McNaney wrote:

> Welcome to 2007!
Right back at ya!

>
> We are back in the office ready to work. There will be about a week's
> delay until I can start hammering on 1.0 again. Short term goals  
> are the
> following:
>
> 1) Versioning for Web Pages
Cool

> 2) Global user log-in for branches
A couple thoughts... When doing this, try to keep it configurable as  
an opt-in if possible. What I mean is that in the old Single Sign On  
hack, it is possible for any given branch to use the hub user db (or  
not) and it is possible to use a group to restrict any admin privs to  
(for any given branch). I have found these pretty useful.

> 3) Anonymous submission rights for calendar and blog
I suspect this will lead to a couple minor core changes in Categories  
that I need for my own mods. I'll touch on this in another letter, in  
a moment.

>
> My longer term goal is to rewrite the Form Generator for 1.0.
Cool... a minor request or two... could the sender address (form  
results on submission) be configurable? fo...@ww... has been  
a PIA. And, it would be handy to have some sort of standard e-mail  
field that could be included in a form, that if used would a) have a  
little bit of verification on it (a regex for valid structure would  
be fine) and b) be used as the from address when sending form results.

>
> The week delay will allow me to catch up on work lost from our
> development server crash. On the plus side since so much data had  
> to be
> recreated, Kevin implemented Subversion to replace CVS. He should have
> the details of that soon.
>
> Best regards,
> Matt
>
Same to you :)
verdon (trying hard not to smoke)

Re: [Phpwebsite-developers] Delivery

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

Morning :)

On 3-Jan-07, at 8:27 AM, Matthew McNaney wrote:

> Good morning.
>
> I am looking for feedback on how the core and modules should be
> distributed.
>
> Initially, modules untarred to their own directory. For example,
> blog_1_3_4.tgz would untar as the directory blog/.
>
> This was confusing some people so I changed it to mod/module_name so
> they could be untarred in the root installation.
Either of these is fine and intuitive for me, but I think mod/ 
module_name seems a more common sort of convention. The only problem  
this might cause is that any 3rd-party mods from the phpws-comm  
project will not follow this convention and that could lead to  
confusion for new users.

>
> As for the core, some people are untarring that distro into the core
> directory when, in fact, it needs to be decompressed and copied  
> into the
> root.
>
> How would you prefer this be done? How would you like the modules and
> core to untar? When decompressed, what should the directories be  
> named?
> Is "core" a misleading name for the base files of phpwebsite?
I must admit to being slightly confused by this the first time. I too  
thought that 'core' meant things in the core directory only. It  
didn't take me long to realize that my assumption was wrong, but I  
can see the confusion :)

Perhaps the word 'core' should be reserved for things in the core dir  
and some other term used for core files not in the core dir ;-)

>
> Any advice would be appreciated.
Ultimately, it doesn't matter what convention you choose, someone  
will misunderstand it.

The most common convention that I see in other projects is that all  
updates and patches and add-ons can be expanded into the root dir and  
the appropriate dir/file structure is reflected in the update/patch/ 
add-on.


salut,
verdon

[Phpwebsite-developers] Delivery

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

Good morning.

I am looking for feedback on how the core and modules should be
distributed.

Initially, modules untarred to their own directory. For example,
blog_1_3_4.tgz would untar as the directory blog/.

This was confusing some people so I changed it to mod/module_name so
they could be untarred in the root installation.

As for the core, some people are untarring that distro into the core
directory when, in fact, it needs to be decompressed and copied into the
root.

How would you prefer this be done? How would you like the modules and
core to untar? When decompressed, what should the directories be named?
Is "core" a misleading name for the base files of phpwebsite?

Any advice would be appreciated.

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

[Phpwebsite-developers] Happy New Year!

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

Welcome to 2007!

We are back in the office ready to work. There will be about a week's
delay until I can start hammering on 1.0 again. Short term goals are the
following:

1) Versioning for Web Pages
2) Global user log-in for branches
3) Anonymous submission rights for calendar and blog

My longer term goal is to rewrite the Form Generator for 1.0.

The week delay will allow me to catch up on work lost from our
development server crash. On the plus side since so much data had to be
recreated, Kevin implemented Subversion to replace CVS. He should have
the details of that soon.

Best regards,
Matt

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

[Phpwebsite-developers] module users/groups api pws1.0

[<hi...@dc...>]

Fighting (with? against?) users/groups api of pws1.0, please Matt would 
you kindly look to my code, because the doc about module users is 
nothing until now. The function calls all defined groups and wants to 
show the members usernames of each group.

*****

	function atMembers() {
	  // touching module users api, show the list of members
       PHPWS_Core::initModClass('users', 'Action.php');
	  // get an array of all groups
       $grplist=User_Action::getGroups('group',array());
	  $content='<pre>';
	  // working with the group object
	  $ug = & new PHPWS_Group('users');
	  // run thru the group list array
	  foreach ($grplist as $id=>$group) {
	    // show the group name
	    $content.=$group.' (id:'.$id.')<br />';
		// set the current group id to the group object
		$ug->setId($id);
		// get an array (in the object) of uids who are members of the group
		$ug->loadMembers();
		// get the array here
		$m=$ug->getMembers();
		// run thru the array of member uids
		if (is_array($m)) {
		  foreach ($m as $k=>$uid) {
		    $us = & new PHPWS_User('users');
			$us->PHPWS_User($uid);
		    // get the username of the uid
		    $memname=$us->getUsername();
			// username null is group (recursion required to solve ...)
			if (is_null($memname)) {
			  $memname='n u l l';
			}
		    $content.='* '.$memname.' (id:'.$uid.')'.'<br />';
		  }
		} else {
		  $content.='* no members in group<br />';
		}
	  }
	  $this->feedContent('MemberList',$content.'</pre>');
	}

*****

The result of the code is (as intended):

grpa (id:3)
* pre1 (id:2)
* n u l l (id:4)
grpb (id:4)
* n u l l (id:5)
grpc (id:5)
* pre (id:1)
grpd (id:6)
* no members in group

I think, the code looks a bit awkward, but works. Is there are ways more 
simple?
regards, Hilmar

[Phpwebsite-developers] Google deprecates their SOAP interface

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

http://radar.oreilly.com/archives/2006/12/ 
google_depreciates_SOAP_API.html

I don't know if anyone's using it in phpwebsite modules but they  
suggest using their AJAX api, which is obviously not quite as useful  
for non AJAX apps.


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

Re: [Phpwebsite-developers] Icons

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

On Thu, 2006-12-14 at 16:46 +0000, Shaun Murray wrote:
> One of the comments I had from users I've shown v1.0 to has been that  
> the icons are awful. Much worse than 0.10.x.

People are mean.

> So I went looking for some better ones.
> 
> http://tango.freedesktop.org/Tango_Desktop_Project

I like them. I will try swapping them out for 1.0.1.

> Very nice. Almost as nice as OSX icons. Under a Creative Commons  
> Share-Alike licence
> 
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> aegis hosting - http://www.aegishosting.co.uk
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> 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

[Phpwebsite-developers] Icons

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

One of the comments I had from users I've shown v1.0 to has been that  
the icons are awful. Much worse than 0.10.x.

So I went looking for some better ones.

http://tango.freedesktop.org/Tango_Desktop_Project

Very nice. Almost as nice as OSX icons. Under a Creative Commons  
Share-Alike licence


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

Re: [Phpwebsite-developers] Need help

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

Thank you for testing. Could you please send me a database dump so I can
test locally?

Matt

On Sat, 2006-12-09 at 13:17 +0100, Yves Kuendig wrote:
> Hi Matt
> 
> I'm not familiar enough with fallout code to present a real fix, but i
> played around a bit with the conversion and utf-8 problem.
> 
> The answers i found (maybe not complete) are the following:
> The database table's charset and collation did not affect my results.
> Your conversion script did work allmost fine. The characters where stored in
> the database
> either if the table was with latin1_german2_ci or with utf8_unicode_ci
> collation.
> But the text displayed on the webpage was garbage.
> I found, the page was displayed ok, if i change the browser to ISO-8859-1
> encoding ?!
> So i started to investigate the connection and the output (layout).
> 
> Things i tried:
> I sent "SET NAMES utf8" to mysql direct after 'connect'; in
> convert/class/Convert.php and also in pear/DB/mysql.php .
> This is probably not needed. (But not yet investigated).
> I added this line:
> 	$text = utf8_encode($text);	//yok
> at line 66 in layout/class/Layout.php before:
> 	Layout::_loadBox($text, $module, $content_var);
> 
> Thereafter the output on the website (only webpage tested) was fine.
> 
> But PhpWebSite is still not fixed. If i enter a text now inside phpws
> (webpages) the output of it is garbage. The database content shows ä
> instead of the real lowercase_a_umlaut. This makes me believe, the content
> is html-encoded and not utf-8.
> 
> Conclusion:
> The database seems not to be the problem, if mysql is newer than 4.1.x . But
> the mysql-server has to know wich encoding on the client-side is used. It
> handles the tables and it's collation on whatever setup. This is imho good
> news, because lot of users out there get a preconfigured db from the host
> and are not able to change charset nor collation.
> Since the server knows the client-encoding, he is translating the db-content
> to it (eg. utf-8).
> But what we have to do now, is to make sure, all the ingoing and outgoing
> content inside phpws is encoded as correct utf-8 also.
> 
> Maybe we have to use a function to check the content if it is allready
> encoded?!
> eg. (not mine, somewhere from the net):
> 
> /**
> * Checks if String is UTF-8 Encoded
> * @param string $string string to check
> * @return boolean
> */
> function is_utf8($string)
> {
> return preg_match('%^(?:
> [\x09\x0A\x0D\x20-\x7E] # ASCII
> | [\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte
> | \xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs
> | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte
> | \xED[\x80-\x9F][\x80-\xBF] # excluding surrogates
> | \xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3
> | [\xF1-\xF3][\x80-\xBF]{3} # planes 4-15
> | \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16
> )*$%xs', $string);
> }
> 
> and convert if not:
> 
> /**
> * Encodes String to UTF8
> * @param string $string
> * @return string
> */
> function cms_utf8_encode($string)
> {
> if(is_utf8($string))
> {
> return $string;
> } else {
> if(function_exists('mb_convert_encoding'))
> {
> return mb_convert_encoding($string,'utf-8');
> } else {
> return utf8_encode($string);
> }
> }
> }
> 
> 
> We should also double-check the headers and meta-tags of the output:
> eg: <meta http-equiv="content-type"
> content="application/xhtml+xml;charset=utf-8" />
> eg: header('content-type: text/html; charset=utf-8');
> and maybe also in css ???
> eg: @charset "utf-8";
> 
> And last but not least; to work with forms, the charset should be defined:
> <form accept-charset="utf-8" method= ...>
> 
> 
> All this is 'only' some kind of brainstorming. But maybe the direction,
> where to go, to handle different languages, charsets and encodings...
> 
> Regards
> Yves
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> 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

[Phpwebsite-developers] Image Uploads / FC Questions

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

Hi fellow devs,

... still working on re-writing the first of my modules for phpws  
1.x ... many new habits to learn, but I want to get it right and not  
just do a quick conversion :)

I have questions about image uploads and best practices.

I don't want to use File Cabinet (FC) in this case. I want this mod's  
images to be separate. I want any logged in user to be able to upload  
an image without special permissions, and also, I don't want users  
posting to this mod to have access to any other images on the site.

That raises another point I hadn't thought of at first... I don't  
want other mods having access to the images uploaded by this mod, via  
FC, for use in other parts of the site either. At first glance,  
although I really like a lot of what FC has to offer, it seems to  
give pretty broad access to the resources of all modules, to any  
module where it is used and I guess that's the point. However, I can  
imagine scenarios where a Profiler user might inadvertently delete an  
image used in some other mod, while poking around for an image for  
the profile being edited, not to mention being able to upload in any  
mod's image dir. What if for some reason, while adding Profiler  
records, I upload all my images in the blog image dir. Then later on,  
an admin un-installs blog, not knowing that the Profiler editor  
wasn't very bright :)

A couple thoughts come to mind (and I am just thinking out-loud)...

1) It might be useful if mods had to be registered (or not) with FC  
at boost or perhaps later with settings within FC. This would allow a  
mod developer to protect the resources of their mod from other mods'  
users via FC. If these was achieved with settings within FC, perhaps  
it would only apply to  non-diety users.

2) Maybe it would be better if there were two sorts of upload  
scenarios to FC. By that I mean, if the image/file upload screen is  
invoked from within some other module (like Profiler does for images)  
then only the image/file directory for the invoking mod is allowed  
for uploading to. If FC is accessed directly (Control Panel >  
Administration > FC) then all image/file dirs are available for upload.

Anywise, back to saving images in my mod, assuming I'm not going to  
use FC. I used to use EZform::saveImage() but that no longer exists.  
I can write my own function and have been looking around for  
examples, mostly trying to figure out what FC is doing when uploading/ 
saving an image. It would be really useful if there was a saveImage()  
function in /core/class/File.php. Perhaps if I write a solid enough  
function for my mod it can be moved to core in future versions :)

Does anyone have any advice as to whether I should use the old  
EZform::saveImage() as a starting point, or if I should further  
explore what FC's image/file class is doing? It looks like FC is  
passing a lot of stuff off to Pear functions and I haven't followed  
that thread yet. I'm starting to lose sight of the forest for the  
trees ;-)

Best regards,
verdon

Re: [Phpwebsite-developers] Need help

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

Hi Matt

I'm not familiar enough with fallout code to present a real fix, but i
played around a bit with the conversion and utf-8 problem.

The answers i found (maybe not complete) are the following:
The database table's charset and collation did not affect my results.
Your conversion script did work allmost fine. The characters where stored in
the database
either if the table was with latin1_german2_ci or with utf8_unicode_ci
collation.
But the text displayed on the webpage was garbage.
I found, the page was displayed ok, if i change the browser to ISO-8859-1
encoding ?!
So i started to investigate the connection and the output (layout).

Things i tried:
I sent "SET NAMES utf8" to mysql direct after 'connect'; in
convert/class/Convert.php and also in pear/DB/mysql.php .
This is probably not needed. (But not yet investigated).
I added this line:
	$text = utf8_encode($text);	//yok
at line 66 in layout/class/Layout.php before:
	Layout::_loadBox($text, $module, $content_var);

Thereafter the output on the website (only webpage tested) was fine.

But PhpWebSite is still not fixed. If i enter a text now inside phpws
(webpages) the output of it is garbage. The database content shows ä
instead of the real lowercase_a_umlaut. This makes me believe, the content
is html-encoded and not utf-8.

Conclusion:
The database seems not to be the problem, if mysql is newer than 4.1.x . But
the mysql-server has to know wich encoding on the client-side is used. It
handles the tables and it's collation on whatever setup. This is imho good
news, because lot of users out there get a preconfigured db from the host
and are not able to change charset nor collation.
Since the server knows the client-encoding, he is translating the db-content
to it (eg. utf-8).
But what we have to do now, is to make sure, all the ingoing and outgoing
content inside phpws is encoded as correct utf-8 also.

Maybe we have to use a function to check the content if it is allready
encoded?!
eg. (not mine, somewhere from the net):

/**
* Checks if String is UTF-8 Encoded
* @param string $string string to check
* @return boolean
*/
function is_utf8($string)
{
return preg_match('%^(?:
[\x09\x0A\x0D\x20-\x7E] # ASCII
| [\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte
| \xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs
| [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte
| \xED[\x80-\x9F][\x80-\xBF] # excluding surrogates
| \xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3
| [\xF1-\xF3][\x80-\xBF]{3} # planes 4-15
| \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16
)*$%xs', $string);
}

and convert if not:

/**
* Encodes String to UTF8
* @param string $string
* @return string
*/
function cms_utf8_encode($string)
{
if(is_utf8($string))
{
return $string;
} else {
if(function_exists('mb_convert_encoding'))
{
return mb_convert_encoding($string,'utf-8');
} else {
return utf8_encode($string);
}
}
}


We should also double-check the headers and meta-tags of the output:
eg: <meta http-equiv="content-type"
content="application/xhtml+xml;charset=utf-8" />
eg: header('content-type: text/html; charset=utf-8');
and maybe also in css ???
eg: @charset "utf-8";

And last but not least; to work with forms, the charset should be defined:
<form accept-charset="utf-8" method= ...>


All this is 'only' some kind of brainstorming. But maybe the direction,
where to go, to handle different languages, charsets and encodings...

Regards
Yves

Re: [Phpwebsite-developers] Need help

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

On 8 Dec 2006, at 20:06, Verdon Vaillancourt wrote:

>
> One other hurdle you might run into is different character encodings.
> Anything newer and default should be UTF-8 but I don't think you can
> count out running into data in other encodings. I know at one time I
> had a few sites, that likely started as .9.x sites, that I converted
> from ISSO-8859-1 to UTF-8. I suppose it could even be possible to run
> into both in a site that's been updated a few times.
>

I've a few like that though I've tended to stick with ISO and strip  
out the code in phpwebsite that does anything with UTF. Most of them  
were MySQL 4.0 too so no character set support. I don't think it's  
actually worth using UTF unless you're on MySQL 4.1 or later. Most of  
the time the one I come up against is pound signs of course.

Again though, I'm not likely to be converting them for quite some  
time. 0.10.x just has a lot more features at present and a couple of  
important modules that aren't on 1.0.

I'm starting a proper 1.0 project now though so that I can work out  
what needs doing.


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

Re: [Phpwebsite-developers] Need help

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

Hi Matt,

I haven't tried converting any sites and don't really foresee any in  
the immediate future to be honest. Too many 3rd party mods in use,  
not to mention my own that aren't converted yet ;-)

That said, I can provide some dumps of some pagemaster pages and  
announcements and maybe fatcats in French if you just need some to try.

One other hurdle you might run into is different character encodings.  
Anything newer and default should be UTF-8 but I don't think you can  
count out running into data in other encodings. I know at one time I  
had a few sites, that likely started as .9.x sites, that I converted  
from ISSO-8859-1 to UTF-8. I suppose it could even be possible to run  
into both in a site that's been updated a few times.

Anywise, if you want some dumps but no examples, let me know.

On 8-Dec-06, at 2:42 PM, Matthew McNaney wrote:

> Hi all,
>
> Some users are having problems converting from 0.10.x to 1.0.0. The
> conversion was mangling accented characters.
>
> If someone could please send me a small db dump of their 0.10.x web
> pages written in German, French, Dutch, etc., I'd appreciate it.  
> Please
> include a text file with good examples of broken words and  
> characters so
> I can cross reference.
>
> BTW - I uploaded a new core today that converts branches. Check Boost
> for details.
>
> Thanks
> Matt
>
> -- 
> Matthew McNaney
> Electronic Student Services
> Appalachian State University
> http://phpwebsite.appstate.edu
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Need help

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

Hi all,

Some users are having problems converting from 0.10.x to 1.0.0. The
conversion was mangling accented characters.

If someone could please send me a small db dump of their 0.10.x web
pages written in German, French, Dutch, etc., I'd appreciate it. Please
include a text file with good examples of broken words and characters so
I can cross reference.

BTW - I uploaded a new core today that converts branches. Check Boost
for details.

Thanks
Matt

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

Re: [Phpwebsite-developers] Categories in 1.x

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

Hi again Matt,

The more I play with categories, the more I think that just putting  
the link to categorize (as opposed to a multi-select list) right in  
my module's add/edit screen would be enough. I'm beginning to like  
the categorize pop-up window the more I use it. I just wanted it more  
obvious in my module's form, and something that would be available to  
an anonymous submitter. The problem in all this is that in the case  
of a new record, there is no id or key_id set, until the new mod item  
has been saved.

Just thinking out loud,
verdon


> Hi Matt,
>
> Yes, in a similar manner as the old fatcat. It would be nice if it  
> was a multi-select list :)
>
> salut,
> verdon
>
>
> On 4-Dec-06, at 1:26 PM, Matthew McNaney wrote:
>
>> So you just want to be able to set a category outside of the  
>> MiniAdmin
>> interface?
>>
>> Matt
>>
>> On Sun, 2006-12-03 at 22:39 -0500, Verdon Vaillancourt wrote:
>>> Hi :)
>>>
>>> Can anyone help me impliment categories in 1.x? I can't find any
>>> examples of categories is use in a mod, except in the miniadmin, and
>>> the instructions in /docs/Categories.txt aren't getting me anywhere.
>>> It's sounds straight fwd, but  I'm just missing something :)
>>>
>>> I'd like to include a multiple select list, or some such thing, in a
>>> typical add/edit item form, made up of available categories.
>>>
>>> Any pointers?
>>>
>>> Thanks,
>>> verdon
>>>
>>
>> -- 
>> Matthew McNaney
>> Electronic Student Services
>> Appalachian State University
>> http://phpwebsite.appstate.edu
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Phpwebsite-developers mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] A couple early observations while modding for 1.x

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

Matt,

I see that the patch is in CVS. Cool :)

I might suggest that the readme.txt file also gets updated to reflect
the new variable.

salut,
verdon

On 12/4/06, Verdon Vaillancourt <ve...@ve...> wrote:
> Matt,
>
> HTH :)
>
> Are you referring to the DHTML calendar patch going into CVS? I just
> want to be sure I can code against it being there.
>
> Thanks,
> verdon
>
> On 4-Dec-06, at 1:25 PM, Matthew McNaney wrote:
>
> > Verdon,
> >
> > Thank you for that fix! I have committed it to CVS. It will be
> > included
> > with the next core release.
> >
> > Matt
> >
> > On Sun, 2006-12-03 at 22:06 -0500, Verdon Vaillancourt wrote:
> >> Hi :)
> >>
> >> A couple early observations while writing a mod for the new version.
> >> Matt, if you're reading and would like me to put these in a tracker,
> >> I will. Let me know where.
> >>
> >> First, I'm having fun! I also appreciate the documentation that has
> >> already been done. It has really helped getting going.
> >>
> >> 1) Location of settings.php in docs/Settings_Class.txt is wrong,
> >> still says to put settings.php in /mod/mymod/conf and it should say /
> >> mod/mymod/inc
> >>
> >>
> >> 2) It would be nice if there was a way to have /core/class/Form.php
> >> prepend a required indicator to a field label. Maybe something like
> >> '<span class="error">*</span>&nbsp;' could be prepended to a field
> >> label if the label was called like...
> >>
> >> $form->setLabel('email', _('Contact E-mail'), $required) or...
> >>
> >> $form->setLabel('email', _('Contact E-mail'))
> >> $form->setRequired('email')
> >>
> >> ... at first I tried just adding it to my label string, not realizing
> >> the basic label value also gets added as a var to the actual
> >> field. Doh!
> >>
> >>
> >> 3) The DHTML Calendar js_calendar, as it currently is, cannot be used
> >> on a page that has more than one form, unless your form happens to be
> >> the first one on the page. It took me a while to figure out why I
> >> couldn't get this to work (couldn't see the forest for the trees) but
> >> the fix seems simple enough. What I outline below works fine for me.
> >> I don't know if it would cause problems min browsers that I don't
> >> have, but I don't think so...
> >>
> >> i) Add...
> >>
> >> if (!isset($data['form_name'])) {
> >>      $data['form_name'] = '0';
> >> } else {
> >>      $data['form_name'] = $data['form_name'];
> >> }
> >>
> >> ...near the top of /javascript/js_calendar/default.php
> >>
> >>
> >> ii) Then in body.js, and body2.js in /javascript/js_calendar/ change
> >> all instances of forms[0] to forms['{form_name}']
> >>
> >>
> >> iii) Now a mod developer can send
> >>
> >> $js_vars['form_name'] = 'my_form_name';
> >> $js_vars['date_name'] = 'my_date';
> >> $js_vars['type']      = 'text';
> >> $template['PICK_CAL'] = javascript('js_calendar', $js_vars);
> >>
> >>
> >> 4) Now I have to figure out the best way to work with image uploads.
> >>
> >> Cheers,
> >> verdon
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ----
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to
> >> share your
> >> opinions on IT & business topics through brief surveys - and earn
> >> cash
> >> http://www.techsay.com/default.php?
> >> page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> 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
> >
> >
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?
> > page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>

Re: [Phpwebsite-developers] A couple early observations while modding for 1.x

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

Matt,

HTH :)

Are you referring to the DHTML calendar patch going into CVS? I just  
want to be sure I can code against it being there.

Thanks,
verdon

On 4-Dec-06, at 1:25 PM, Matthew McNaney wrote:

> Verdon,
>
> Thank you for that fix! I have committed it to CVS. It will be  
> included
> with the next core release.
>
> Matt
>
> On Sun, 2006-12-03 at 22:06 -0500, Verdon Vaillancourt wrote:
>> Hi :)
>>
>> A couple early observations while writing a mod for the new version.
>> Matt, if you're reading and would like me to put these in a tracker,
>> I will. Let me know where.
>>
>> First, I'm having fun! I also appreciate the documentation that has
>> already been done. It has really helped getting going.
>>
>> 1) Location of settings.php in docs/Settings_Class.txt is wrong,
>> still says to put settings.php in /mod/mymod/conf and it should say /
>> mod/mymod/inc
>>
>>
>> 2) It would be nice if there was a way to have /core/class/Form.php
>> prepend a required indicator to a field label. Maybe something like
>> '<span class="error">*</span>&nbsp;' could be prepended to a field
>> label if the label was called like...
>>
>> $form->setLabel('email', _('Contact E-mail'), $required) or...
>>
>> $form->setLabel('email', _('Contact E-mail'))
>> $form->setRequired('email')
>>
>> ... at first I tried just adding it to my label string, not realizing
>> the basic label value also gets added as a var to the actual  
>> field. Doh!
>>
>>
>> 3) The DHTML Calendar js_calendar, as it currently is, cannot be used
>> on a page that has more than one form, unless your form happens to be
>> the first one on the page. It took me a while to figure out why I
>> couldn't get this to work (couldn't see the forest for the trees) but
>> the fix seems simple enough. What I outline below works fine for me.
>> I don't know if it would cause problems min browsers that I don't
>> have, but I don't think so...
>>
>> i) Add...
>>
>> if (!isset($data['form_name'])) {
>>      $data['form_name'] = '0';
>> } else {
>>      $data['form_name'] = $data['form_name'];
>> }
>>
>> ...near the top of /javascript/js_calendar/default.php
>>
>>
>> ii) Then in body.js, and body2.js in /javascript/js_calendar/ change
>> all instances of forms[0] to forms['{form_name}']
>>
>>
>> iii) Now a mod developer can send
>>
>> $js_vars['form_name'] = 'my_form_name';
>> $js_vars['date_name'] = 'my_date';
>> $js_vars['type']      = 'text';
>> $template['PICK_CAL'] = javascript('js_calendar', $js_vars);
>>
>>
>> 4) Now I have to figure out the best way to work with image uploads.
>>
>> Cheers,
>> verdon
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> 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
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Fallout Settings class - text strings

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

Hi Matt,

I had to uninstall / reinstall my mod in progress, but yes, that did  
the trick.

Thanks :)
verdon


On 4-Dec-06, at 12:46 PM, Matthew McNaney wrote:

> That's a bug. You should be able to store null values.
>
> Please try the following cvs commit:
> http://tinyurl.com/y9pabx
>
> I will update core if all is well.
>
> Thanks,
> Matt
>
> On Sun, 2006-12-03 at 22:06 -0500, Verdon Vaillancourt wrote:
>> Hi :)
>>
>> I am working on my first mod for phpws 1.x. My module has some
>> settings that are text strings. I don't seem to be able to set these
>> to NULL or empty strings. For example, by default, these settings
>> should return NULL. What they are returning is 0. Maybe I'm
>> misunderstanding, but I don't think 0 is the same as NULL in this
>> instance.
>>
>> I have tried in my inc/settings.php setting them as
>>
>> $settings['custom_1_label'] = NULL;
>>
>> and as
>>
>> $settings['custom_1_label'] = '';
>>
>> In either case, when I bring these values up in a settings edit form
>> in this manner,
>>
>> $form->addText('custom_1_label', PHPWS_Settings::get('ssclassifieds',
>> 'custom_1_label'));
>> $form->setSize('custom_1_label', 40, 255);
>> $form->setLabel('custom_1_label', _('Custom field 1 label'));
>>
>> The form will have a 0 in the field. If I remove the zero, and save
>> the settings, and then bring up the edit screen again, the 0 is back.
>>
>> Is this normal behaviour? If it is, I can likely work with it, but it
>> would be more familiar to me if the setting contained NULL or an
>> empty string.
>>
>> Thanks for any input into this and very  best regards,
>> verdon vaillancourt
>
> -- 
> Matthew McNaney
> Electronic Student Services
> Appalachian State University
> http://phpwebsite.appstate.edu
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] A couple early observations while modding for 1.x

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

Verdon,

Thank you for that fix! I have committed it to CVS. It will be included
with the next core release.

Matt

On Sun, 2006-12-03 at 22:06 -0500, Verdon Vaillancourt wrote:
> Hi :)
> 
> A couple early observations while writing a mod for the new version.  
> Matt, if you're reading and would like me to put these in a tracker,  
> I will. Let me know where.
> 
> First, I'm having fun! I also appreciate the documentation that has  
> already been done. It has really helped getting going.
> 
> 1) Location of settings.php in docs/Settings_Class.txt is wrong,  
> still says to put settings.php in /mod/mymod/conf and it should say / 
> mod/mymod/inc
> 
> 
> 2) It would be nice if there was a way to have /core/class/Form.php  
> prepend a required indicator to a field label. Maybe something like  
> '<span class="error">*</span>&nbsp;' could be prepended to a field  
> label if the label was called like...
> 
> $form->setLabel('email', _('Contact E-mail'), $required) or...
> 
> $form->setLabel('email', _('Contact E-mail'))
> $form->setRequired('email')
> 
> ... at first I tried just adding it to my label string, not realizing  
> the basic label value also gets added as a var to the actual field. Doh!
> 
> 
> 3) The DHTML Calendar js_calendar, as it currently is, cannot be used  
> on a page that has more than one form, unless your form happens to be  
> the first one on the page. It took me a while to figure out why I  
> couldn't get this to work (couldn't see the forest for the trees) but  
> the fix seems simple enough. What I outline below works fine for me.  
> I don't know if it would cause problems min browsers that I don't  
> have, but I don't think so...
> 
> i) Add...
> 
> if (!isset($data['form_name'])) {
>      $data['form_name'] = '0';
> } else {
>      $data['form_name'] = $data['form_name'];
> }
> 
> ...near the top of /javascript/js_calendar/default.php
> 
> 
> ii) Then in body.js, and body2.js in /javascript/js_calendar/ change  
> all instances of forms[0] to forms['{form_name}']
> 
> 
> iii) Now a mod developer can send
> 
> $js_vars['form_name'] = 'my_form_name';
> $js_vars['date_name'] = 'my_date';
> $js_vars['type']      = 'text';
> $template['PICK_CAL'] = javascript('js_calendar', $js_vars);
> 
> 
> 4) Now I have to figure out the best way to work with image uploads.
> 
> Cheers,
> verdon
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> 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

Re: [Phpwebsite-developers] Fallout Settings class - text strings

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

Thanks,

I'll try this tonight after my bush-league hockey game. I have  
meetings up my ... (well you know) this afternoon.

rgds,
verdon


On 4-Dec-06, at 12:46 PM, Matthew McNaney wrote:

> That's a bug. You should be able to store null values.
>
> Please try the following cvs commit:
> http://tinyurl.com/y9pabx
>
> I will update core if all is well.
>
> Thanks,
> Matt
>
> On Sun, 2006-12-03 at 22:06 -0500, Verdon Vaillancourt wrote:
>> Hi :)
>>
>> I am working on my first mod for phpws 1.x. My module has some
>> settings that are text strings. I don't seem to be able to set these
>> to NULL or empty strings. For example, by default, these settings
>> should return NULL. What they are returning is 0. Maybe I'm
>> misunderstanding, but I don't think 0 is the same as NULL in this
>> instance.
>>
>> I have tried in my inc/settings.php setting them as
>>
>> $settings['custom_1_label'] = NULL;
>>
>> and as
>>
>> $settings['custom_1_label'] = '';
>>
>> In either case, when I bring these values up in a settings edit form
>> in this manner,
>>
>> $form->addText('custom_1_label', PHPWS_Settings::get('ssclassifieds',
>> 'custom_1_label'));
>> $form->setSize('custom_1_label', 40, 255);
>> $form->setLabel('custom_1_label', _('Custom field 1 label'));
>>
>> The form will have a 0 in the field. If I remove the zero, and save
>> the settings, and then bring up the edit screen again, the 0 is back.
>>
>> Is this normal behaviour? If it is, I can likely work with it, but it
>> would be more familiar to me if the setting contained NULL or an
>> empty string.
>>
>> Thanks for any input into this and very  best regards,
>> verdon vaillancourt
>
> -- 
> Matthew McNaney
> Electronic Student Services
> Appalachian State University
> http://phpwebsite.appstate.edu
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Categories in 1.x

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

Hi Matt,

Yes, in a similar manner as the old fatcat. It would be nice if it  
was a multi-select list :)

salut,
verdon


On 4-Dec-06, at 1:26 PM, Matthew McNaney wrote:

> So you just want to be able to set a category outside of the MiniAdmin
> interface?
>
> Matt
>
> On Sun, 2006-12-03 at 22:39 -0500, Verdon Vaillancourt wrote:
>> Hi :)
>>
>> Can anyone help me impliment categories in 1.x? I can't find any
>> examples of categories is use in a mod, except in the miniadmin, and
>> the instructions in /docs/Categories.txt aren't getting me anywhere.
>> It's sounds straight fwd, but  I'm just missing something :)
>>
>> I'd like to include a multiple select list, or some such thing, in a
>> typical add/edit item form, made up of available categories.
>>
>> Any pointers?
>>
>> Thanks,
>> verdon
>>
>
> -- 
> Matthew McNaney
> Electronic Student Services
> Appalachian State University
> http://phpwebsite.appstate.edu
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Categories in 1.x

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

So you just want to be able to set a category outside of the MiniAdmin
interface?

Matt

On Sun, 2006-12-03 at 22:39 -0500, Verdon Vaillancourt wrote:
> Hi :)
> 
> Can anyone help me impliment categories in 1.x? I can't find any  
> examples of categories is use in a mod, except in the miniadmin, and  
> the instructions in /docs/Categories.txt aren't getting me anywhere.  
> It's sounds straight fwd, but  I'm just missing something :)
> 
> I'd like to include a multiple select list, or some such thing, in a  
> typical add/edit item form, made up of available categories.
> 
> Any pointers?
> 
> Thanks,
> verdon
> 

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

Re: [Phpwebsite-developers] Fallout Settings class - text strings

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

That's a bug. You should be able to store null values.

Please try the following cvs commit:
http://tinyurl.com/y9pabx

I will update core if all is well.

Thanks,
Matt

On Sun, 2006-12-03 at 22:06 -0500, Verdon Vaillancourt wrote:
> Hi :)
> 
> I am working on my first mod for phpws 1.x. My module has some  
> settings that are text strings. I don't seem to be able to set these  
> to NULL or empty strings. For example, by default, these settings  
> should return NULL. What they are returning is 0. Maybe I'm  
> misunderstanding, but I don't think 0 is the same as NULL in this  
> instance.
> 
> I have tried in my inc/settings.php setting them as
> 
> $settings['custom_1_label'] = NULL;
> 
> and as
> 
> $settings['custom_1_label'] = '';
> 
> In either case, when I bring these values up in a settings edit form  
> in this manner,
> 
> $form->addText('custom_1_label', PHPWS_Settings::get('ssclassifieds',  
> 'custom_1_label'));
> $form->setSize('custom_1_label', 40, 255);
> $form->setLabel('custom_1_label', _('Custom field 1 label'));
> 
> The form will have a 0 in the field. If I remove the zero, and save  
> the settings, and then bring up the edit screen again, the 0 is back.
> 
> Is this normal behaviour? If it is, I can likely work with it, but it  
> would be more familiar to me if the setting contained NULL or an  
> empty string.
> 
> Thanks for any input into this and very  best regards,
> verdon vaillancourt

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

Re: [Phpwebsite-developers] A couple early observations while modding for 1.x

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

On 4 Dec 2006, at 03:06, Verdon Vaillancourt wrote:

>
> 2) It would be nice if there was a way to have /core/class/Form.php
> prepend a required indicator to a field label. Maybe something like
> '<span class="error">*</span>&nbsp;' could be prepended to a field
> label if the label was called like...
>
> $form->setLabel('email', _('Contact E-mail'), $required) or...
>
> $form->setLabel('email', _('Contact E-mail'))
> $form->setRequired('email')
>
> ... at first I tried just adding it to my label string, not realizing
> the basic label value also gets added as a var to the actual field.  
> Doh!
>

How about using <label> for labels and using <label class="required">  
where you set the class of the label in the setLabel function. That  
would be more flexible, and semantically correct.

ie. $form->setLabel('email', _('Contact E-mail'), $class)



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