phpwebsite-developers — For our development team.

[Phpwebsite-developers] $nukeurl

[Eric W. <ecr...@ya...>]

Can we please do away with $nukeurl being a variable
name.  How about $phpwsurl? Anything other than
*nuke*. As this code is continually becoming better
and better, I hate seeing that reminder of phpnuke.  


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

[Phpwebsite-developers] Templates, tables and CSS

[Eric W. <ecr...@ya...>]

I have a question about the proposed template
implementation.  

Will the script files themselves still be littered
with html?  

Here is my line of thinking.  I think that phpWebsite
should work on completely separating structure from
the content, i.e., removing all of the tables that
holds the basic design together.  Instead the design
should be controlled through the theme css file.

Related to this are calls the css file for font specs.
 All calls to the css file for a specific class should
be controlled by the theme not by the php script.  

As a proof of concept, I have been rewriting all the
code to use css for structure and not the tables.  My
work can be seen at my site ecrosstexas.com.  I am not
finished on this yet, but I would really like to see
the entire project move in this direction.

Thanks,
Eric Wallace

ecr...@ya...
http://www.ecrosstexas.com/



__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: [Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

[Philip M. <lis...@li...>]

I hope you don't mind me throwing my 2p in here, but the subject of
localisation is one that has been a major part of my career for the last 2
years.

This mail is not intended to sway you one way or the other, but I guess,
just to reassure you that any localisation effort runs into exactly the same
problems and other people have "been there before" :-)

As you no doubt know by now, localisation is never an easy task and there is
never one 'catch all' solution that caters for all situations, most often it
is a matter or compromise.

As a quick background on my experience in localisation:

I work for a B2B ASP providing ticketing software in 8 different languages
to a global audience.

The previous version of our software used a build-time translation system
only. The current version uses run-time translation combined with
user-configured, multilingual text.

The software provides the facility to change the language of the front-end
at any time during the purchase process.


Obviously, localisation incorporates more than just translations and we
regularly have to deal with different timezones and currency issues. I skim
over these as I don't think them relevant to phpWS.

The number of distinct phrases within our application is now within the
order of tens of thousands This affected our choice of how to deal with
translation.

We use a combination of translation agencies and in-house translation staff
to deal with translating the phrases, and the phrases are provided in the
form of a CSV file of the format:

placeholder,language_code,Phrase to translate,Context of the phrase.

'placeholder' is our system code for the text, and our pages have
translatable placeholders in them rather than English. Not so far removed
from phpWS, and pretty much the standard way of localising a product :-)

'language_code' is the language the phrase is in, be it en_GB es_ES, nl_NL,
pt_PR etc.

'Phrase to translate' is pretty self-explanatory.

'Context of the phrase' is important to translators as it gives them an
indication of the use of a phrase within the system.

e.g. The phrase 'Your account' comes with an attached context of 'This text
is a link. The user can click on this link to access their previous purchase
history, billing details and contact details.' It just helps to pin the
phrase down for accurate translation :-)

This allows us to:

* Split out translations for each language code
* Retain the placeholder -> phrase mapping
* Give the translator both the phrase to translate and the context of that
phrase.

We did toy around with other ideas for translation systems, but these were
ditched due to time constraints.

The best all-round idea that we came up with was to create a new user-level
for a translator.

This translator user would be shown the same interface as a normal user, but
as well as having the text in the right places in the interface, would be
presented with text boxes (alongside or below the translatable text) to
allow them to translate the phrase directly on the page, thus allowing the
translator to view the context of that phrase in-situ.

This is, however, not an easy feat. The best compromise is to try and give a
context for the phrase so that it can be accurately translated. :-)

IMHO, I agree with Brian that a build-time translation system is much more
suited to the needs of phpWS since there is no perceived need to change
languages on the fly.

However, I would also like to see a system where the admin could change the
wording of phrases within the user-facing portion of phpWS. I.e. the ability
to change the wording of 'Main Menu' or the 'sign up now' wording to suit
their needs, without having to hack the code directly. This could be done
with an include file...

There is no reason why this has to be run-time either. There is nothing to
stop someone setting up an online phpWS translation tool where any user can
alter the phrasing of a base language file to suit their needs, and then
download the result to plug into their system.

Finally, the result of spending 1/4 of my work time for the last 2 years on
product localisation has taught me that there are only 2 ways to release
apps in multi-lingual form:

1) Release the default language ahead of the others and then release the
translated versions when the translations are in.

2) Create a code-freeze deadline and have the phrases translated while the
software is in the testing phase, then release all languages simultaneously.

Case 1 allows development to continue regardless of the state of other
localised releases, while case 2 ties the development schedule into
translation deadlines but results in a better overall product.

I sincerely hope I didn't sound as if I was on a high horse here, and it was
not my intention to step on anyone's toes. I just thought you might like
some reassurance that localisation is a common and ongoing problem. With the
Web being global, respect is rightfully deserved by those that realise this
and work towards global solutions :-)

Regards, Phil
--
Philip McAllister
ph...@li...
"All I ask is the chance to prove that money can't make me happy." - Spike
Milligan

Re: [Phpwebsite-developers] CVS stabilization, bugs sweeping and my

[Alessandro P. (T. / J578) <al...@ti...>]

On Fri, 2001-11-30 at 17:04, Brian W. Brown wrote:
> See:
> 
> http://www.k-fish.de/krabutzig/phpwebsite/devdoc.html
> 
> and
> 
> http://res1.stddev.appstate.edu/cvs/checkout.php/phpwebsite/docs/MODULES_README?r=1.10
> and
> 
> http://phpwebsite.appstate.edu/mod.php?mod=userpage&menu=1503&page_id=21

Thanks....
but I think we need to add to these guidelines a raccomandation on $op :
bug #486810 show us that admitting case-sensitive $op can cause problem
when third-party themes or modules are not very well written.
The user who reported #486810 suggested to force switch(strtolower($op))
intead of the current switch($op), but this would require a lot of
changes in both phpWS core and modules; furthermore it can breaks up
backward-compatibility.

Any idea/comments on this?

Kind Regards,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

Re: [Phpwebsite-developers] CVS stabilization, bugs sweeping and my

[Brian W. B. <br...@tu...>]

>> Well, should be cleaned up anyway, I guess. Do we have a
>> coding
>> guideline for this case (too lazy to look right now)? If
>> not, we should raise the issue on the dev list more
>> offensive...
> I agree. We need a coding guideline for $op... I forward
> this topic to the dev mail-list.

See:

http://www.k-fish.de/krabutzig/phpwebsite/devdoc.html

and

http://res1.stddev.appstate.edu/cvs/checkout.php/phpwebsite/docs/MODULES_README?r=1.10
and

http://phpwebsite.appstate.edu/mod.php?mod=userpage&menu=1503&page_id=21
(Note that we *really* need to try to bring things up to the
PEAR standards...)

Brian

-- 
Brian W. Brown
Director, Electronic Student Services
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608
vox: 828-262-7124
fax: 828-262-2585

L  I  N  U  X
     .~.
     /V\
    // \\
   /(   )\
    ^^-^^
Love the Penguin

[Phpwebsite-developers] Hello from Florida!

[Jason C. <cam...@xp...>]

Hey guys!  I haven't posted anything on here in a long time.  Thought I'd
just pop in and say hey!  I've been working on a few different projects,
one being Sinapze, a CMS system from scratch....anyways...

One thing I did see discussion about was on-the-fly language system.  I
currently have this type of system built into Sinapze.  Brian is right
about just having strings like "Main Menu" show up in a native language
could be possibly pointless.

The way I currently have it setup in Sinapze is with the module being one
class and the language file(s) being a class within the module's class,
based on the user's language that language file is the extension of the
module's class.  This makes the calls to the variables really easy $this-
>menutitle for example.  The language file(s) for the module are more or
less just glorified text files that just happen to be classes.

The way I have this setup for users, they can switch from language to
language on the fly from the user control panel or the admin can force the
users to all use the same language.  I think just having all the
actual "text" displaying stuff out of the actual module code is time saving
in itself and easier to maintain it that way.

Just my two cents on everything....keep up the good work guys!!

-- 
Jason Campbell
Soarion Technologies
www.soarion.com
www.sinapze.com

Re: [Phpwebsite-developers] CVS stabilization, bugs sweeping and my todo (status report)

[Alessandro P. (T. / J578) <al...@ti...>]

On Fri, 2001-11-30 at 16:04, Karsten Dambekalns wrote:
> On Fri, Nov 30, 2001 at 03:21:44PM +0100, Alessandro Pisani (TXM / J578) wrote:
> > On Fri, 2001-11-30 at 15:17, Karsten Dambekalns wrote:
> > > On Fri, Nov 30, 2001 at 12:35:31PM +0100, Alessandro Pisani (TXM / J578) wrote:
> > > 
> > > > I'm also investigation on a bug which fix should require all $op to be
> > > > lowercase. This change would avoid broken themes etc. to create some
> > > > common errors. What d'you think of it? It would be okay to operate this
> > > > change? - Bug is #486810
> > > 
> > > I would go for it. Calling strtolower on $op seems to be a good thing,
> > > it makes the system far more robust. And it shoudl break next to
> > > nothing - relying on case-sesitivity when distinguishing operations
> > > would seem unlikely.
> > This should require changes in about 90% of modules, so this is why I
> > was asking comments on how to move :>
> 
> Huh?!? [grumblegrumble] Oh no!
> 
> You are right. Maybe I should have looked at the switches spread all
> over the place one more time. Indeed, a wild mixture of "ChangePoll"
> and "menu_post" style statements. Hmmm.
> 
> Well, should be cleaned up anyway, I guess. Do we have a coding
> guideline for this case (too lazy to look right now)? If not, we
> should raise the issue on the dev list more offensive...
I agree. We need a coding guideline for $op... I forward this topic to
the dev mail-list.

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

Re: [Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

[Karsten D. <k.d...@tu...>]

On Fri, Nov 30, 2001 at 09:40:27AM -0500, Brian W. Brown wrote:
> > Ah, about the language system: yes, it may generally
> > cause a performance slowdown... this
> > could be considered by some people a right price to pay
> > to have runtime per-user localization.
> 
> Obviously, the current language system could use some
> improvement. I do, however, very much like a package-time
> translation system. A few thoughts:
[...]
> o I have never understood the need for runtime translation (if
> someone wants to explain, please do). What good is the ability
> to display, say the text "Main Menu" in many different
> languages when all of your content is locked-in to the
> language in which it was written?

I agree. This would in no way be of any help. But I would love to see
even that: multi language content. As soon as the "core language" can
be set during run time, it (would|should) be relatively easy to add a
"lang" field to e.g. the article database to distinguish between
different version of one article (one would have to connect those,
etc., but you get the point).

And voila - a multi language capable CMS. Which is not too useful for
a university setting (you might argue), unless you consider students
from foreign countries (who, again, should speak the language of their
university's country, ok :-).

But we were asked to set up phpWS for a school here in Germany, and
they want to have the thing multi-language (that might rule out phpWS,
although this would be sad) because this is a german-italian
school. Or think about international partnerships between whatever you
can imagine...

Thoughts?

Regards,
Karsten
-- 
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w³: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

[Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

[Brian W. B. <br...@tu...>]

> Ah, about the language system: yes, it may generally
> cause a performance slowdown... this
> could be considered by some people a right price to pay
> to have runtime per-user localization.

Obviously, the current language system could use some
improvement. I do, however, very much like a package-time
translation system. A few thoughts:

o A web-based, password protected, centralized language DB. A
translator could log in and see/translate the most recent
untranslated strings. This would also keep translators from
duplicating effort.

o System would continue to generate *.pp files for
package-time translation.

o Ship a "raw" version of phpWebSite. Running your own
translation is not hard...

o I have never understood the need for runtime translation (if
someone wants to explain, please do). What good is the ability
to display, say the text "Main Menu" in many different
languages when all of your content is locked-in to the
language in which it was written?

o Having our output be a simple string (i.e. there is no
"language engine" handling this output) allows for rather
simple customization. For example, if I really did not like
the term "Main Menu" it is easy for me to change this to read
"Navigation". While it is true that I would need to do this
each time I upgrade, it is a trival thing to do.

I welcome any and all thoughts on this. I would like to see
our methods for maintaining the language files improved, but I
remain unconviced as to the benefit of a runtime translation
system. To those who feel differently, please convince me!
phpWebSite is a team effort and I welcome debate and
discourse.

Kind Regards,
Brian Brown
phpWebSite Project Manager



-- 
Brian W. Brown
Director, Electronic Student Services
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608
vox: 828-262-7124
fax: 828-262-2585

L  I  N  U  X
     .~.
     /V\
    // \\
   /(   )\
    ^^-^^
Love the Penguin

Re: [Phpwebsite-developers] One among many

[Karsten D. <k.d...@tu...>]

On Fri, Nov 30, 2001 at 08:19:31AM -0500, Matthew McNaney wrote:
[...]
> Banner Management
> 
> number of views, click thoughs, number of views or click thoughs it has
> before it becomes inactive
> 
> -------> Probably should be a mod. Would like to see this taken out
> of core> (it won't be in the rewrite) but more flexible.

I am working on fixing this a little right now. Since the call to the
banner function will be moved to the theme anyway, we can as well make
the thing a module. I will look at this and hereby volunteer to do the
rewrite :-)

Before that I will fix the current state, to make sure the next
version at least has bug less...

Karsten
-- 
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w³: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

Re: [Phpwebsite-developers] CVS stabilization, bugs sweeping and my todo (status report)

[Karsten D. <k.d...@tu...>]

On Fri, Nov 30, 2001 at 12:35:31PM +0100, Alessandro Pisani (TXM / J578) wrote:

> I'm also investigation on a bug which fix should require all $op to be
> lowercase. This change would avoid broken themes etc. to create some
> common errors. What d'you think of it? It would be okay to operate this
> change? - Bug is #486810

I would go for it. Calling strtolower on $op seems to be a good thing,
it makes the system far more robust. And it shoudl break next to
nothing - relying on case-sesitivity when distinguishing operations
would seem unlikely.

Karsten
-- 
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w³: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

[Phpwebsite-developers] One among many

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

For those unaware phpBB is working on a CMS front end for their BB system.

Here is an interesting post of what they one person wanted in it along with
some of my comments:
---------------------------------------------------------
News

Print News option
Email a friend option
Add a comment about News

User posts news, news wait in a queue, moderator approves certain news,
approved news appear on certain page.

------> So far we do this

The ablity to take user submitted news and point it to be displayed on the
correct page.

Make all the seprate "news" pages (i.e. hardware, software, cars, etc) run
off of phpBB 2.0 user groups.

------> Brian and I talked about this yesterday. Basically we could attach
certain topics to certain groups. Should work in the new version

Ability to add pictures to news posts, resize them etc.

Ability to set the order news appears on the site
------> I would like to see this as well

Polls
(of course building upon the phpbb system) - Part of phpBB 2.0
------> Ryan had some good improvements to polls but we could add more
eventually


Calendar

private and public events

name, time, venue, contact, description, type of event (list of categories
from drop down?), price?

Calendar Archive

Mass delete events by user, group, date, etc.

The calendar is viewable by month, week, and or day.

Permissions to add events to the calendar are given by User Group and
Individual.

Public events are viewable to everyone, while Private events are visible
only to members of the user group it was posted for.

A modulefor the front page that allows you to see upcoming events for the
week and or day. (if your logged in you see your group events here too, if
not you see only public events.)

The ability to make events reaccuring on a daily, weekly, bi-weekly,
monthly, or anual basis. (You get the point.)

The ability to put e-mail notification on an event, and the ability for
users to decide whether or not they wish to recieve event alerts. They
should be able to decide this on a user group level, so they can choose to
ignore alerts from user group #1 but still get all of the alerts for user
group #2.

-------> This is either built in or planned. I will not work on calendar
however until the core is finished.


Downloads

Stats on DLs

Number of downloads, click counting, file size, option of screen shot
display, categories & subcategories, user comments, rate download, top 10
files

-------> I've heard this before, in fact one of you guys or gals said they
might work on this


Forum

Banner Management

number of views, click thoughs, number of views or click thoughs it has
before it becomes inactive

-------> Probably should be a mod. Would like to see this taken out of core
(it won't be in the rewrite) but more flexible.


Language Support

Review System
Movies, Books, CD's etc.
-------> Mod again

User Accounts - A lot of this is already supported by phpBB 2.0

maybe change the theme, as in phpBB, but also change the colors to one's
preference

-------> In the new core. Working on making this VERY secure and flexible.

Online layout customisation (limited to very basic changes, otherwise it
would be far too hard to make)

-------> Bleh Don't like this idea. Not worth the hassle.


Logging in on any page
-------> In the new core.

Site search
Easy interface as to not confuse the user
-------> Done


Templates (Already in phpBB2)
-------> In the new core with plans to make as flexible as the skills of
the developer. Alex is developing a theming mechanism as well I think.


Admin Tools

fully templatable (system already in place )
extensive News-System
combined phpbb/pp User management
Some or all portal functions accessible from an integrated control panel

-------> Again, new core except the BB


(using the "drop in" modular format of the v2 admin panel)

Administrator has the option to set "extra" viewing options

(for when users are browsing the board via the portal-ie. don't show the
page-header, etc.)
-------> In the new core currently

Online content management through forms etc. (another very obvious one),
with bbcode or similar (ppcode)

User Groups - In phpBB 2.0

certain sections of the page available to only usergroups, so a certain
group can get access to certain areas, where another group could have
access to different areas, or even a little overlapping of other groups.

certain groups have access to post a new topic other groups only have
access to post a reply
----> Can be don with the new core but would have to be built into the
module


menu management
Add categories, link on right or left side of site
-----> Block code already done by Mike

File language
Have an option to say a file, article, can be found in english, german,
french etc. basically be able to turn on and off a link that translates the
article (templates?)
-------> A few of you have asked about this and I guess we should pow wow
on it. IMO dynamic language slows down the site. However we have thought
about compromises and new ideas to make languages easier to use.

Statictics
Public stats
topic (thread/news/picture/any item) X times seen, X timesdownloaded, X
times commented, X timesprinted. Top 10 of those, ie.
Private stats
only for admins. Dtailed stats on page views, user's browsers, OSes, etc.
Also a user rating (who did what most).

-------> Mod based




Other Misc Features
Browsing forum from portal (with portal menu bars etc still visible)
Feedback form
also has to mail the admins all feedbacks
(could utilise hidden boards in forum for displaying)
-------> Possible, again mod based


Uploading of attachments, or images, but with per-directory, per-user
access customisation

Ability to run without dependance on forums.

Shoutbox
much like a chat, does not require login, just type your name and msg and
submit. Last shouts appear on the homepage. Nice way for dropping a quick
note for other online members.
-----> Interesting, could be abused but we have some ideas to build abuse
protection into the new core.

User last seen (or last logged in)
a list of 20 (30, 50, 100) users, sorted by time of login, and more
------> Good idea, I will go ahead and implement a time stamp so a module
can access something like this.

Image Gallery
Ability to upload images resize them if need be to create an image gallery
-------> We have 2 galleries I believe. Jeremy is working on the resizing
code I think.

Link System
Ability to add links to a link page, seprated by categories
-------> Yes Web Links must die. Very old Nuke code needs to be put out of
its misery. Any developer that wants to recode this, be our guest.


PDA version of portal
Low Graphics version of portal
--------> Should be theme based, no biggie

Some good stuff overall. Please comment on what you like, what you don't
like etc.

Matt


Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493

[Phpwebsite-developers] CVS stabilization, bugs sweeping and my todo (status report)

[Alessandro P. (T. / J578) <al...@ti...>]

I've just committed two small fixes to stabilize upgrade from
0.8.1-official to CVS and to complete a previous fix in polls.
As far as I can see, upgrading from 0.8.1 to CVS is now safe.
I'm also investigating old (zombies) pending bugs, support requests and
features requests (some of them had been superceded by 0.8.x releases) :
expect a loss of opened-items in the next days... I hope :>
Today I'm going to officially start work onto the new themes
configuration module, along with a minor enhancement to userpages
editor.

I'm also investigation on a bug which fix should require all $op to be
lowercase. This change would avoid broken themes etc. to create some
common errors. What d'you think of it? It would be okay to operate this
change? - Bug is #486810

Ah, last but not least: I would thank all those people who sent me (both
in ml, both privately) feedback on the planned language system : I'll
soon post a detailed plan about it.

Regards,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

RE: [Phpwebsite-developers] About bug #485294: banner is inserted outside

[Vlad S. <vl...@hu...>]

aSBhZ3JlZSAtIGkgdGhpbmsgdGhlIGJhbm5lciBjYWxsIHNob3VsZCBnbyBpbnRvIHRoZSB0aGVt
ZSBkZWZpbml0aW9uIHJlZ2FyZGxlc3MuLi4NCg0KdG9wIG9mIHRoZSBwYWdlIGlzIGNvbnNpZGVy
ZWQgc2FjcmVkIGZvciBhIGxvdCBvZiBhZXN0aGV0aWNhbGx5IGluY2xpbmVkIHdlYiBkZXZlbG9w
ZXJzLiBCYW5uZXIgb24gdG9wIGVhdHMgdXAgcXVpdGUgYSBiaXQgb2YgaGVhZGVyIHNwYWNlIGFu
ZCBzaGlmdHMgbW9yZSBpbXBvcnRhbnQgY29udGVudCBkb3duLiBzbywgd2h5IG5vdCBsZXQgdGhl
IGRldmVsb3BlciBkZWNpZGUgd2hlcmUgdGhlIGJhbm5lciBzaG91bGQgZ28/Li4NCg0KDQpWbGFk
DQoNClAuUy4gUEhQV2Vic2l0ZSBpcyBhIGtpY2sgYXNzIHByb2R1Y3QuIEkndmUgdHJpZWQgYWJv
dXQgMzAgZGlmZmVyZW50IEdQTCBhbmQgbm9uLUdQTCBDTVMncyAsIGFuZCBmcmFua2x5LCBtb3N0
IG9mIHRoZW0gc3VjayAodXN1YWxseSBlaXRoZXIgc3BlZWQgb3IgZWFzZSBvZiBtYWludGVuYW5j
ZSBpc3N1ZXMpLiBrZWVwIHVwIHRoZSBnb29kIHdvcmsuIA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gRnJvbTogcGhwd2Vic2l0ZS1kZXZlbG9wZXJzLWFkbWluQGxpc3RzLnNv
dXJjZWZvcmdlLm5ldA0KPiBbbWFpbHRvOnBocHdlYnNpdGUtZGV2ZWxvcGVycy1hZG1pbkBsaXN0
cy5zb3VyY2Vmb3JnZS5uZXRdT24gQmVoYWxmIE9mDQo+IE1hdHRoZXcgTWNOYW5leQ0KPiBTZW50
OiBUaHVyc2RheSwgTm92ZW1iZXIgMjksIDIwMDEgMTA6MzQgYW0NCj4gVG86IHBocHdlYnNpdGUt
ZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gU3ViamVjdDogUmU6IFtQaHB3ZWJz
aXRlLWRldmVsb3BlcnNdIEFib3V0IGJ1ZyAjNDg1Mjk0OiBiYW5uZXIgaXMNCj4gaW5zZXJ0ZWQg
b3V0c2lkZQ0KPiANCj4gDQo+IEhleSBLYXJzdGVuLA0KPiANCj4gPiBUaGUgb25seSB3YXkgdG8g
c29sdmUgdGhpcywgaXMgdG8gcHV0IHRoZSBjYWxsIHRvIHRoZSBiYW5uZXIgZnVuY3Rpb25zDQo+
ID4gaW50byB0aGUgdGhlbWUncyBoZWFkZXIgZmlsZSAocmlnaHQgYWZ0ZXIgdGhlIG9wZW5pbmcg
Ym9keSB0YWcpLiBXaGlsZQ0KPiA+IHRoaXMgd29ya3MgZm9yIG1lIHdpdGhvdXQgYSBoaXRjaCwg
aXQgd291bGQgbmVlZCBtb2RpZmljYXRpb25zIHRvIGFsbA0KPiA+IGV4aXN0aW5nIHRoZW1lcyAo
YXQgbGVhc3QgdGhlIG9uZXMgd2hvc2UgYXV0aG9ycyB3YW50IHRoZWlyIHRoZW1lcyB0bw0KPiA+
IHN1cHBvcnQgYmFubmVycykuDQo+ID4gV2hhdCBkbyB5b3UgdGhpbms/IElzIHRoaXMgYSBzaG93
LXN0b3BwZXI/IE9yIGFyZSBib3RoIHN0YXRlcyBlcXVhbGx5DQo+ID4gYmFkIChoYXZpbmcgdG8g
Y2hhbmdlIGFsbCB0aGVtZXMgdnMuIGhhdmluZyBpbnZhbGlkIFhIVE1MIHdoZW4gdXNpbmcNCj4g
PiBiYW5uZXJzKT8NCj4gDQo+IEkgdGhpbmsgY2hhbmdpbmcgdGhlIGluZGl2aWR1YWwgdGhlbWUg
bWlnaHQgYmUgdGhlIGJlc3Qgcm91dGUuIFdlIA0KPiB3aWxsIGp1c3QNCj4gbmVlZCB0byBtYWtl
IG1lbnRpb24gb2YgaXQgdG8gdGhlIHBlb3BsZSB3aG8gdXBncmFkZS4gSSBhbSBndWVzc2luZyB0
aGUNCj4gY29kZSB3aWxsIHByb2JhYmx5IGJlIHByZXR0eSBzaG9ydC4NCj4gDQo+ID5Gcm9tIGEg
UFIgcG9pbnQgb2Ygdmlldywgd2UgbWlnaHQgd2FudCB0byBtYWtlIGEgc2FtcGxlIHRoZW1lIA0K
PiB0aGF0IHVzZXMgdGhlDQo+IGJhbm5lciBlZmZlY3RpdmVseS4gQ3VycmVudGx5LCB0aGUgYmFu
bmVyIGlzIHByZXR0eSBtdWNoIG91dCBvZiBwbGFjZS4gSWYNCj4gd2UgaW50cm9kdWNlIGl0IGlu
IHRoZSB0aGVtZS9mb28vaGVhZGVyLnBocCBmaWxlIHlldCBpbmNvcnBvcmF0ZSANCj4gaW5zdGVh
ZCBvZg0KPiBpdCBzaXR0aW5nIG91dHNpZGUgdGhlIHRoZW1lIChhcyBpdCBkb2VzIGN1cnJlbnRs
eSkgcGVvcGxlIG1heSBhcHByZWNpYXRlDQo+IGl0IG1vcmUuDQo+IA0KPiBCZXN0IHJlZ2FyZHMs
DQo+IE1hdHQNCj4gDQo+IE1hdHRoZXcgTWNOYW5leQ0KPiBJbnRlcm5ldCBTeXN0ZW1zIEFyY2hp
dGVjdA0KPiBFbGVjdHJvbmljIFN0dWRlbnQgU2VydmljZXMNCj4gRW1haWw6IG1hdHRAdHV4LmFw
cHN0YXRlLmVkdQ0KPiBVUkw6IGh0dHA6Ly9waHB3ZWJzaXRlLmFwcHN0YXRlLmVkdQ0KPiBQaG9u
ZTogODI4LTI2Mi02NDkzDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IFBocHdlYnNpdGUtZGV2ZWxvcGVycyBtYWlsaW5nIGxp
c3QNCj4gUGhwd2Vic2l0ZS1kZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRw
czovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9waHB3ZWJzaXRlLWRldmVs
b3BlcnMNCj4g

Re: [Phpwebsite-developers] About bug #485294: banner is inserted outside

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

Hey Karsten,

> The only way to solve this, is to put the call to the banner functions
> into the theme's header file (right after the opening body tag). While
> this works for me without a hitch, it would need modifications to all
> existing themes (at least the ones whose authors want their themes to
> support banners).
> What do you think? Is this a show-stopper? Or are both states equally
> bad (having to change all themes vs. having invalid XHTML when using
> banners)?

I think changing the individual theme might be the best route. We will just
need to make mention of it to the people who upgrade. I am guessing the
code will probably be pretty short.

From a PR point of view, we might want to make a sample theme that uses the
banner effectively. Currently, the banner is pretty much out of place. If
we introduce it in the theme/foo/header.php file yet incorporate instead of
it sitting outside the theme (as it does currently) people may appreciate
it more.

Best regards,
Matt

Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493

Re: [Phpwebsite-developers] About bug #485294: banner is inserted outside of body

[Alessandro P. (T. / J578) <al...@ti...>]

On Thu, 2001-11-29 at 16:59, Karsten Dambekalns wrote:
> The only way to solve this, is to put the call to the banner functions
> into the theme's header file (right after the opening body tag). While
> this works for me without a hitch, it would need modifications to all
> existing themes (at least the ones whose authors want their themes to
> support banners).
> 
> What do you think? Is this a show-stopper? Or are both states equally
> bad (having to change all themes vs. having invalid XHTML when using
> banners)?
> 
> Looking forward to your opinions!
> Karsten
This is not a problem, IMHO.
The themes structure had yet changed from 0.8.1 to CVS to include new
features (such as poll-docking) and others assorted fixes; it also
changed both during 0.7.x branch (as far as I could see) and 0.8.x, so
definitively making it "stable" with all the changes that are needed is
not a backward-compatibility problem (anymore).

>Why do we have to hide from the police, daddy?
>Because we use emacs, son. They use vi.
LOL! Btw I'm a policeman: i've ever hated emacs (maybe I'm too stupid to
understand it ? ...who knows...) ;->

Kind Regards,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

[Phpwebsite-developers] About bug #485294: banner is inserted outside of body

[Karsten D. <k.d...@tu...>]

Hi!

I started working on my bug "#485294 banner is inserted outside of
body", and came across the following:

The banner is included before the call to head, this way it has to be
just after the xml declaration and even before the html tag.

The only way to solve this, is to put the call to the banner functions
into the theme's header file (right after the opening body tag). While
this works for me without a hitch, it would need modifications to all
existing themes (at least the ones whose authors want their themes to
support banners).

What do you think? Is this a show-stopper? Or are both states equally
bad (having to change all themes vs. having invalid XHTML when using
banners)?

Looking forward to your opinions!
Karsten
-- 
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w³: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

Re: [Phpwebsite-developers] Re: request for comments ^_^

[Alessandro P. (T. / J578) <al...@ti...>]

On Thu, 2001-11-29 at 14:52, Matthew McNaney wrote:
> > Hi all.
> > Thinking about post bug-#486233-defeat (i'm working on it) times, I
> > have some ideas about next items in my todo list, and I would love to
> > hear your comments about them.
> >
> > 1- an on-the-fly themes configuration system: to change themes from the
> > admin panel instead of having to edit config.php
> 
> Yes agreed.
Okay... I'll start working on this as soon as possible (= when the bugs
i'm working on could be considered "fixed")

> Nuke did this and it slowed down the system with a huge switch statement. I
> was talking to Brian about having a built in system for compiling the
> program into a certain language. You could then run the compile again later
> if you wanted another language. The language file could also possibly help
> you write a translate file and identify phrases not yet translated. Overall
> though, it would keep the translation straight HTML.
I was thinking about something smarter than Nuke's system: I said and
hereby say that I do not like Nuke (and its derivates) at all :>
I though about a new runtime system which can use the existing .pp
files, without having to rewrite/rearrange them... but I need to make a
detailed masterplan on this. As soon as I have time to do it (I hope
this weekend), I'll post it to all of us.

> > 3- a native downloads module: i'm pretty unhappy with the existing
> > downloads plugins which are ported from phpNuke/postNuke.
> 
> Not familiar with this really although I have heard there are problems with
> security with this. Let me know more.
Well... it depends on implementation.... I have to think about this...
again, as soon as I have a project, I'll discuss it with all the other
developers...

> > Please anyone feel free to make comments, suggestions, criticisms (even
> > rude ones...), etc...
> 
> Rude ones? Who would do such a thing?
LOL :> I was joking.... ;->

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

Re: [Phpwebsite-developers] [Fwd: Valid XHTML? Please check your php code again.]

[Alessandro P. (T. / J578) <al...@ti...>]

On Thu, 2001-11-29 at 14:43, Matthew McNaney wrote:
>Anyway, Captain Ego has uncovered a problem with articles. It is
>striping
>quotation marks from the submitted form. This causes it not to comply.
>I have also heard that articles is striping all HTML tags. Has anyone
>fixed this or is it still present? If so or not, please let me know.

As I said in m-l this morning, I fixed HTML tag striping from
articles.... but it is to deep-test:to fix it, I had to remove
htmlspecialchars() call, a function which converts for example & in
&, > in < and so on.
I'm gonna improving it, due to this "polite" (ehm ehm!) bug notification
from THJ you forwarded to us :>

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

[Phpwebsite-developers] Re: request for comments ^_^

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

> Hi all.
> Thinking about post bug-#486233-defeat (i'm working on it) times, I
> have some ideas about next items in my todo list, and I would love to
> hear your comments about them.
>
> 1- an on-the-fly themes configuration system: to change themes from the
> admin panel instead of having to edit config.php

Yes agreed.

> 2- an on-the-fly translation system: instead of having localized
> builds, I thought it would be nice to have such a thing...eventually
> with the possibility to switch language from the admin panel.

Nuke did this and it slowed down the system with a huge switch statement. I
was talking to Brian about having a built in system for compiling the
program into a certain language. You could then run the compile again later
if you wanted another language. The language file could also possibly help
you write a translate file and identify phrases not yet translated. Overall
though, it would keep the translation straight HTML.

> 3- a native downloads module: i'm pretty unhappy with the existing
> downloads plugins which are ported from phpNuke/postNuke.

Not familiar with this really although I have heard there are problems with
security with this. Let me know more.

> Please anyone feel free to make comments, suggestions, criticisms (even
> rude ones...), etc...

Rude ones? Who would do such a thing?

Matt



Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493

[Phpwebsite-developers] =?iso-8859-1?Q?[Fwd:_Valid_XHTML=3F__Please_check_your_php_code_again.]?=

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

I received this delightful letter this morning.

-------------------------------------------------------------------

Dear PHP website Team:

Below is presumably not what you mean by valid XHTML.

The refc delimiter error amounts [pretty much] to just an unescaped (sic) &
on
the XHTML code level when you want &  [or &].   (The second
prevalent error below, the unknown entity error, piggybacks on the refc
delimiter error).

You need & as data for the link, but not the unescaped & as XHTML code.
Otherwise, a device that takes XML seriously will think that the
[unescaped] & starts an entity you forgot (1) to define; and  then (2) to
end with a semicolon.

Please clean this up.  As promised.

Who am I?  Someone with a [simple] PHP/MySQL content management site for
which the output does validate as XHTML and CSS, as well conforming to
WAI-AA.   All claims, incidently(sic), made by you for phpwebsite.

If I can get this right by myself, a collection of smart folks like
yourselves should have no problems doing the same.

[For your amusement, my simple site:
http://www.bittersweetmindcandy.com/labrat/ ]

I look forward to using phpwebsite very soon, for a much larger project,
after it has gone thru just one more iteration.

Best regards,

TJH
------------------------------------------------------------------

This letter reminds of a character in Kids in the Hall that had a
neurological disorder that caused everything he said to be stated
with a sarcastic tone. He ends the skit by whining "I'm so lonely..."

Anyway, Captain Ego has uncovered a problem with articles. It is striping
quotation marks from the submitted form. This causes it not to comply. I
have also heard that articles is striping all HTML tags. Has anyone fixed
this or is it still present? If so or not, please let me know.

Thanks for being polite =)
Matt

Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493

[Phpwebsite-developers] please check

[Alessandro P. (T. / J578) <al...@ti...>]

I've just committed two fixes:

1) fix in mod.php which should fix bug 486233 "mods can be called even
if deactivated"

2) fix in comment.php which should fix bug 486798 "comments pass through
html tags"

Please check them both!
Ah, I hereby admit that the first fix is a really dirty trick based on
$HTTP_SERVER_VARS, I'm not so sure it works in every environment, as it
should... plz don't blame me too much :>

PS: For some unknown reasons this morning I'm unable to change bugs on
Sourceforge.... I'll set these two as "closed" as soon as Sourceforge
let me do it :>

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

RE: [Phpwebsite-developers] request for comments ^_^

[Alessandro P. (T. / J578) <al...@ti...>]

On Thu, 2001-11-29 at 01:13, Vlad Sedov wrote:
> 1 - would there be a performance loss if you pulled default theme name (and other vars) from a SQL table? it'd be easier to set it thru admin panel that way and you won't have to have config.php webserver-writeable...
This is the way I was thinking about.
I thinks there shouldn't be any performance loss doing that, but I'll do
lots of testing to be sure.
Having a web-server writable config.php at run-time is both dangerous
and bad ^_-

> 
> 2 - what about the way Nuke does translation?...
I'll analize it

> no comment on #3, though i agree that the a-la-nuke download mods leave somethng a bit better to be desired. For one thing, if you're not hosting some enormously huge downloads, form post uploading works reasonably well, and allows for   (almost) completely FTP-free site maintenance.

xxxNuke modules are always overhelmed with lots feature which are rarely
used and also have some most-wanted features, but they are really
bad-written. I was thinking my download modules as a small,efficient
module with a limited set of features (at least in its initilial
release).

What about writing about a "wish-list" of the future downloads module?
Any suggestion, wish, etc.etc. will be largely appreciated!

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

Re: [Phpwebsite-developers] request for comments ^_^

[Scott R. <sc...@sc...>]

Hey,

I don't talk much on this forum, or contribute a whole lot (a couple of b=
ug=20
reports), I would like to see a 'native' phpwebsite downloads module.  I'=
ve=20
been evaluating different ones, and they all leave something to be desire=
d. =20

Scott Rogers

P.S. If you want to see what I've done with phpwebsite check out=20
www.highcountryrugby.com=20

It's my rugby club.


On Wednesday 28 November 2001 18:31, Alessandro "Pisani (TXM / J578)" wro=
te:
> Hi all.
> Thinking about post bug-#486233-defeat (i'm working on it) times, I hav=
e
> some ideas about next items in my todo list, and I would love to hear
> your comments about them.
>
> 1- an on-the-fly themes configuration system: to change themes from the
> admin panel instead of having to edit config.php
>
> 2- an on-the-fly translation system: instead of having localized builds=
,
> I thought it would be nice to have such a thing...eventually with the
> possibility to switch language from the admin panel.
>
> 3- a native downloads module: i'm pretty unhappy with the existing
> downloads plugins which are ported from phpNuke/postNuke.
>
> Please anyone feel free to make comments, suggestions, criticisms (even
> rude ones...), etc...
>
> bye,
> Alessandro

[Phpwebsite-developers] request for comments ^_^

[Alessandro P. (T. / J578) <al...@ti...>]

Hi all.
Thinking about post bug-#486233-defeat (i'm working on it) times, I have
some ideas about next items in my todo list, and I would love to hear
your comments about them. 

1- an on-the-fly themes configuration system: to change themes from the
admin panel instead of having to edit config.php

2- an on-the-fly translation system: instead of having localized builds,
I thought it would be nice to have such a thing...eventually with the
possibility to switch language from the admin panel.

3- a native downloads module: i'm pretty unhappy with the existing
downloads plugins which are ported from phpNuke/postNuke.

Please anyone feel free to make comments, suggestions, criticisms (even
rude ones...), etc...

bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
INWO Project coordinator http://www.inwoproject.f2s.com

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]