phpwiki-talk

Re: [Phpwiki-talk] css classes, ids in markup

[Matt B. <ma...@ma...>]

On Thu, 2005-10-13 at 11:00 +0100, John Kershaw wrote:

> What I'm proposing (and using on some of my ancient phpwiki 1.3.0's) 
> is 100% about keeping markup separate from content. CSS classes and 
> ID attributes allow my users to add semantic meaning to their content 
> without having to worry about how it's going to presented, either now 
> or after some future site-wide stylesheet alterations.

OK. At least we're heading for the same goal here, 100% agree that good
classes and IDs on attributes are necessary, but I have some
reservations about allowing arbitrary specification....

> For instance, my <div> code looks like this:
> 
> ==== pullquote
> What a great idea
> ====
<snip other examples>
> BTW The markup used is entirely up for discussion - I'm only talking 
> about the validity of the approach.

OK. I think you've mostly convinced me that I do agree with what you're
proposing, I probably misunderstood the initial post a little. 

I'm still vaguely uncomfortable with the idea of allowing users to add
arbitrary classes to objects. I can't pinpoint exactly why though. I
guess it's the whole trade off between flexibility and correctness. If
you let users define arbitrary classes/ids you can bet it's going to be
misused quicker than you can blink your eye. I'm not sure that that is a
strong argument against your proposal though... just thinking aloud
here.

Could it be split into two parts?
- Some extra syntactical features to define some commonly used page
elements 
- An extra plugin that when included allows precise specification of
class names / ids for attributes.

Regards

-- 
Matt Brown
ma...@ma...
Mob +64 275 611 544 www.mattb.net.nz

Re: [Phpwiki-talk] css classes, ids in markup

[John K. <jo...@ke...>]

At 21:42 +1300 13/10/05, Matt Brown wrote:
>On Wed, 2005-10-12 at 13:51 +0200, Joel Uckelman wrote:
>>  {{foo #bar: Here is some text of class foo with id bar.}}
>>
>>would give you a span
>>
>>  <span class="foo" id="bar">Here is some text of class foo with id 
>>bar.</span>
>>
>>1. Do we want to extend the markup syntax to permit this?
>
>My feeling is no. It breaks the fundamental concept of separating markup
>from content. This concept is one of the huge strengths of a wiki.

Matt,

What I'm proposing (and using on some of my ancient phpwiki 1.3.0's) 
is 100% about keeping markup separate from content. CSS classes and 
ID attributes allow my users to add semantic meaning to their content 
without having to worry about how it's going to presented, either now 
or after some future site-wide stylesheet alterations. For instance, 
my <div> code looks like this:

==== pullquote
What a great idea
====

which renders as <div class="pullquote"> and produces a pullquote. As 
far as the user is aware, this markup is defining what the item *is*, 
not how it should look or where it should appear on the page - which 
is what classes & ids are all about, eg http://csszengarden.com

Surely the beauty of wiki is it allows the html-phobic (or html 
people who want something faster, more fluid - wiki=quick) to create 
the pages they want to create, in as simple a form as possible? I'd 
also advocate extending the markup to allow classes & id tags to be 
applied to every existing wiki markup item, eg:

! Ingredients List

should generate*

<h2 id='Ingredients-List'>Ingredients List</h2>

On a modern, aggressively standards compliant, CSS-driven web-site, 
these kinds of things are essential. If my users want their 
Ingredients listed in a blue box with a graphical image-replacement 
gizmo in the site's font, I should be able to let them have that, 
seamlessly, and without them needing to learn any new syntax.

But I believe there should also be the option, for power users who 
use wiki because it's a fast way to build & maintain a web site, who 
can happily handle increased complexity, to directly add ids & 
classes to *any* markup, maybe something like:

Example 1:
!{appendix less-important #app1} Appendix A
would render as
<h1 id='app1' class="appendix" class="less-important">Appendix A</h1>

(space separated classes followed by a single #id since it must be unique)

Example 2:
this is *{warning}so dangerous* => this is <strong class="warning">so 
dangerous</strong>

Example 3:
==== sidebar tip #shutdown
Always use the Shutdown command before turning off your computer
====
would render as
<div class="sidebar" class="tip" id="shutdown-tip">
and would allow the site's *designer* (not necessarily end-user) to 
create 'For Dummies' style sidebar content, using different icons for 
tips, warnings, etc and use an XSL transformer to extract all the 
tips into a pocket-size printable PDF. Currently, none of those 
things are possible with a wiki.

BTW The markup used is entirely up for discussion - I'm only talking 
about the validity of the approach.

Being able to create page(s) called, eg, css-fonts, css-positioning, 
css-colors and have those auto-included in the template would allow 
those power users to add/update styles to go with the enhanced 
content they just added.

John.

* I have my headings in reverse importance (!, !!, !!! = big, med, 
small) as people often create a ! tag first, then want to use the 
'bigger' headings & have to go back through the document making their 
previously 'big' headings smaller.
-- 
-------------------------------------------------------------------
T:01274 581519 / M:07944 755613   www.kershaw.org  jo...@ke...
skype:johnmkershaw  AIM:johnkershaw  MSN:joh...@ho...

Re: [Phpwiki-talk] css classes, ids in markup

[Matt B. <ma...@ma...>]

On Wed, 2005-10-12 at 13:51 +0200, Joel Uckelman wrote:

> 1. Do we want to extend the markup syntax to permit this?

My feeling is no. It breaks the fundamental concept of separating markup
from content. This concept is one of the huge strengths of a wiki.

> 2. If so, how should it be handled? As part of the basic syntax? As part
> of a plugin?

If it was decided it should be implemented, it should definitely be a
plugin so that only those users who are willing to break the
content/markup separation can enable it. 

I think this goes for much of PHPwiki at the moment. There are heaps and
heaps of features that are not used for many wikis and having them in
the default installation makes it much more complex to maintain a
PHPwiki installation. Breaking them out into plugins would make PHPwiki
vastly superior. 

I have grand intentions to help out in this area, I'm just slightly tied
up bringing the Debian packages into line at the moment, but as soon as
I get that under control modularisation of PHPwiki is something I would
quite like to look at. 

Cheers

-- 
Matt Brown
ma...@ma...
Mob +64 275 611 544 www.mattb.net.nz

Re: [Phpwiki-talk] css classes, ids in markup

[Reini U. <rei...@gm...>]

I would say, users should use RawHtml or write their own simple plugin
to allow that.

But generally I would like to add some kind of MarkupPlugin.
As in mediawiki, where you can register new simple or extended transformati=
ons.
As I did with the %color=3D%% and {{template}} syntax recently.
ENABLE_MARKUP_COLOR
ENABLE_MARKUP_TEMPLATE

See lib/InlineParser.php

The only administrative problem would be to define a container (ini-like fi=
le)
with a list of additional Syntax plugins.
And maybe another subdir.

Or maybe it's enough to define ENABLE_MARKUP_CLASS (uppercase)
and search for Markup_class.php (lowercase) in a special dir, which defines=
 the
markup extension
  class Markup_class extends BalancedMarkup /* or SimpleMarkup */
  (lowercase)
IniConfig could then preg_match ENABLE_MARKUP_* or DISABLE_MARKUP_*,
optionally look for the MarkupPlugin in the markup subdir, and fix the
$markup_types =3D array('escape', 'bracketlink', 'url',
                                  'interwiki', 'wikiword', 'linebreak',
                                  'old_emphasis', 'nestled_emphasis',
                                  'html_emphasis', 'html_abbr', 'plugin',
                                  'isonumchars', 'isohexchars',
/*'html_entities',*/
                                  );
in lib/InlineParser.php.

I'll try that in two weeks or someone else is faster :)

ENABLE_MARKUP_TEMPLATE should be renamed to
ENABLE_MARKUP_TEMPLATE _PLUGIN then for consistency though.
Or better rename Markup_template_plugin to Markup_template


PS:
Note that from this Friday on I'll be on a film festival for two weeks,
and I will probably not be able to fix things or add patches to CVS.
So it's up to you Joel.

PPS: But I'll try to find my start for the Mailer class and send it to you.
It's not on my main machine.

On 10/12/05, Joel Uckelman <uck...@no...> wrote:
> It was suggested to me (by John Kershaw) that it would be useful to allow
> users to apply class and id attributes to the markup when editing pages.
>
> Something like
>
>  {{foo #bar: Here is some text of class foo with id bar.}}
>
> would give you a span
>
>  <span class=3D"foo" id=3D"bar">Here is some text of class foo with id ba=
r.</span>
>
> where the classes and ids could be defined by the site maintainer in css =
as
> part of the theme, or for even more neato points, the css could be pulled
> from a page in the wiki so that the users could define it themselves.
>
> Mr. Kersahw has already hacked a very old version (1.3.0) to do something
> like this.
>
> Questions:
>
> 1. Do we want to extend the markup syntax to permit this?
> 2. If so, how should it be handled? As part of the basic syntax? As part
> of a plugin?
>
> Thoughts?
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] info about flatfile support in v1.3

[Reini U. <rei...@gm...>]

Oops,
flatfile is fully supported. In both branches: 1.2 and 1.3

DATABASE_TYPE=3Dfile

On 10/12/05, Massimiliano Pagani <ma...@gm...> wrote:
> Hello there,
>      I read in the 1.3.11p1 documentation that the flatfile support is st=
ill
> work in progress. When do you expect this feature will be available? Or
> maybe already exist an (unofficial) patch to enable it?
--
Reini Urban

Re: [Phpwiki-talk] DBAUTH_PREF_INSERT

[Reini U. <rei...@gm...>]

Thanks guys.
I also fixed the second INSERT.

And made the simple methods to the pref table default.
I want to deprecate the old users table.

On 10/13/05, John Stevens <jst...@gm...> wrote:
> Hi Thomas,
>  It was meant to allow for you to configure the INSERT clause for the
> backend DB you use.  This was the for Oracle.  Since Oracle does not have=
 a
> REPLACE clause (MySQL specific), I used this to to do an initial INSERT f=
or
> user prefs.  Without it, user prefs were never saved or updated.  See my
> Rant ;)
>  Regards
>
>
> On 10/13/05, Thomas Harding <tho...@la...> wrote:
> > Hello,
> > I've just updated my cvs repository.
> >
> > In config/config-dist.ini, I see :
> > ; DBAUTH_PREF_INSERT =3D "INSERT INTO pref SET prefs=3D'$pref_blob',
> userid=3D'$userid'"
> >
> > This is not compatible with Postgresql !
> >
> > The good statement for _all_ SQL SGBDRs is :
> > DBAUTH_PREF_INSERT =3D "INSERT INTO pref (prefs,userid) VALUES
> ('$pref_blob','$userid')"
> >
> > While config-dist.ini is used by the configurator, it will be wise to
> > correct this :)
--
Reini Urban

Re: [Phpwiki-talk] DBAUTH_PREF_INSERT

[John S. <jst...@gm...>]

Hi Thomas,
It was meant to allow for you to configure the INSERT clause for the backen=
d
DB you use. This was the for Oracle. Since Oracle does not have a REPLACE
clause (MySQL specific), I used this to to do an initial INSERT for user
prefs. Without it, user prefs were never saved or updated. See my Rant ;)
Regards

On 10/13/05, Thomas Harding <tho...@la...> wrote:
>
> Hello,
> I've just updated my cvs repository.
>
> In config/config-dist.ini, I see :
> ; DBAUTH_PREF_INSERT =3D "INSERT INTO pref SET prefs=3D'$pref_blob',
> userid=3D'$userid'"
>
> This is not compatible with Postgresql !
>
> The good statement for _all_ SQL SGBDRs is :
> DBAUTH_PREF_INSERT =3D "INSERT INTO pref (prefs,userid) VALUES
> ('$pref_blob','$userid')"
>
> While config-dist.ini is used by the configurator, it will be wise to
> correct this :)
>
> Greetings,
> --
> Thomas Harding
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] DBAUTH_PREF_INSERT

[<tho...@la...>]

On Wed, Oct 12, 2005 at 09:18:48PM +0200, Thomas Harding wrote:
> DBAUTH_PREF_INSERT = "INSERT INTO pref (prefs,userid) VALUES ('$pref_blob','$userid')"

It seems to be the reverse :
DBAUTH_PREF_INSERT = "INSERT INTO pref (userid,prefs) VALUES ('$userid','$pref_blob')"
 
The user's administration patch I've just sent correct this.

-- 
Thomas Harding

Re: [Phpwiki-talk] User administration stuff, pear-db done

[<tho...@la...>]

On Tue, Oct 11, 2005 at 07:52:00PM +0200, Thomas Harding wrote:
> 
> These patch and files associed permits to create and delete users, and
> update their password.
> 
> Currently, only PearDb backend is done.
> 
> I used separate files to avoid memory consomption while it's not needed.

Well, there were edit conflicts from my today's CVS update :/

Here is the diff from last cvs update (2005-09-12 20:00 UTC),
and the new files associated.


-- 
Thomas Harding

[Phpwiki-talk] DBAUTH_PREF_INSERT

[<tho...@la...>]

Hello,
I've just updated my cvs repository.

In config/config-dist.ini, I see :
; DBAUTH_PREF_INSERT = "INSERT INTO pref SET prefs='$pref_blob', userid='$userid'"

This is not compatible with Postgresql !

The good statement for _all_ SQL SGBDRs is :
DBAUTH_PREF_INSERT = "INSERT INTO pref (prefs,userid) VALUES ('$pref_blob','$userid')"

While config-dist.ini is used by the configurator, it will be wise to
correct this :)

Greetings,
-- 
Thomas Harding

[Phpwiki-talk] info about flatfile support in v1.3

[Massimiliano P. <ma...@gm...>]

Hello there,
I read in the 1.3.11p1 documentation that the flatfile support is still wor=
k
in progress. When do you expect this feature will be available? Or maybe
already exist an (unofficial) patch to enable it?

Thank you in advance


Best Regards
--
Massimiliano Pagani
http://www.maxpagani.org/

[Phpwiki-talk] css classes, ids in markup

[Joel U. <uck...@no...>]

It was suggested to me (by John Kershaw) that it would be useful to allow
users to apply class and id attributes to the markup when editing pages.

Something like

 {{foo #bar: Here is some text of class foo with id bar.}}

would give you a span

 <span class="foo" id="bar">Here is some text of class foo with id bar.</span>

where the classes and ids could be defined by the site maintainer in css as
part of the theme, or for even more neato points, the css could be pulled
from a page in the wiki so that the users could define it themselves.

Mr. Kersahw has already hacked a very old version (1.3.0) to do something
like this.

Questions:

1. Do we want to extend the markup syntax to permit this?
2. If so, how should it be handled? As part of the basic syntax? As part
of a plugin?

Thoughts?

-- 
J.

Re: [Phpwiki-talk] More spam filtering

[Reini U. <rei...@gm...>]

BTW: I just forgot

With the new revert button it's also very easy to get rid of thinks like th=
at.
You have to be admin or the ACL remove rights.

On 10/12/05, Reini Urban <rei...@gm...> wrote:
> This kind of five-casino-url spam (even with a nice announce) is
> imho not that annoying than hundreds of links making the text
> effectively unreadable.
>
> Only a global filterlist would help here. mediawiki is also
> looking into this. We will see.
>
> On 10/12/05, Dan Frankowski <dfr...@cs...> wrote:
> > This is just to let you know ..
> >
> > The "no more than 20 links" strategy worked fine for a long time. Just
> > in past couple of days, spammers have rediscovered WikiLens with a
> > vengeance, and they are submitting <<20 links (like 5). See, for exampl=
e,
> >
> > http://www.wikilens.org/wiki.php/RequestedFeatures?action=3DPageHistory=
&version=3D19
> >
> > I tried adding a verifying param to the URL ("site_token=3Dwikilens1234=
")
> > in case they were using a script to submit the edits directly, but it
> > was circumvented immediately. It looks like they are finding the "Save"
> > button somehow.
> >
> > I reverted for awhile, but finally got desparate and closed my wiki to
> > anonymous edits! (ALLOW_ANON_EDIT=3Dfalse. Note it was broken in 1.3.9,
> > which is where we .. well, forked I guess, and it was broken there, so =
I
> > had to make a quick fix).
> >
> > Any other spam filtering advice is welcome. I'd like to open up the wik=
i
> > to anonymous edits again. :(
> --
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>


--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] More spam filtering

[Reini U. <rei...@gm...>]

This kind of five-casino-url spam (even with a nice announce) is
imho not that annoying than hundreds of links making the text
effectively unreadable.

Only a global filterlist would help here. mediawiki is also
looking into this. We will see.

On 10/12/05, Dan Frankowski <dfr...@cs...> wrote:
> This is just to let you know ..
>
> The "no more than 20 links" strategy worked fine for a long time. Just
> in past couple of days, spammers have rediscovered WikiLens with a
> vengeance, and they are submitting <<20 links (like 5). See, for example,
>
> http://www.wikilens.org/wiki.php/RequestedFeatures?action=3DPageHistory&v=
ersion=3D19
>
> I tried adding a verifying param to the URL ("site_token=3Dwikilens1234")
> in case they were using a script to submit the edits directly, but it
> was circumvented immediately. It looks like they are finding the "Save"
> button somehow.
>
> I reverted for awhile, but finally got desparate and closed my wiki to
> anonymous edits! (ALLOW_ANON_EDIT=3Dfalse. Note it was broken in 1.3.9,
> which is where we .. well, forked I guess, and it was broken there, so I
> had to make a quick fix).
>
> Any other spam filtering advice is welcome. I'd like to open up the wiki
> to anonymous edits again. :(
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] WikiLens wants YOU!

[Dan F. <dfr...@cs...>]

This is an email to get you to try WikiLens:

  ** http://www.wikilens.org

We've had 4-5 releases since I last emailed the PhpWiki list. We also have

- entries for 1705 movies. 492 albums, 396 books, 58 video games, 52 
beers, ...
- 132 users (honestly around 10 active ones)
- 8400 ratings

This is a project essentially forked from PhpWiki 1.3.9. I'd love for 
someone to look at reintegrating it (the source tarball is at 
http://www.wikilens.org/wikilens-src.tgz). There are a bunch of changes 
deep into the code, mostly about WikiDB, I think. Probably we should be 
looking at merging, but our energy ran out waiting for 1.3.11.

Dan

WikiLens (http://www.wikilens.org) is a community-maintained repository 
of opinion. Right now, opinions are expressed as ratings, comments, or 
lists, which are digested to show people useful information. For 
example, ratings are turned into recommendations, lists are mentioned on 
each item page.

Think of Amazon, Epinions, MovieLens, or other web sites about things 
(books, video games, movies, beers, vacation spots, plants, etc.) and 
what people think of them, except WikiLens is non-commercial, editable 
by all, open content, open source. Users can create items and even whole 
categories! This is a wiki + recommender + social network (your buddies 
influence your recommendations).

We are where Wikipedia was in 2001: a glorious idea to take over the 
universe. That's where you come in! There are still tons of features to 
add and bugs to squash. However, it's no fun without users, so create an 
account and try us out! Rate a few things, create some items, make some 
comments, invite some buddies. Remember, the most important thing is 
your opinions; helping with the facts are good, but ratings or reviews 
are even better. Most of all, have fun!

[Phpwiki-talk] More spam filtering

[Dan F. <dfr...@cs...>]

Folks,

This is just to let you know ..

The "no more than 20 links" strategy worked fine for a long time. Just 
in past couple of days, spammers have rediscovered WikiLens with a 
vengeance, and they are submitting <<20 links (like 5). See, for example,

http://www.wikilens.org/wiki.php/RequestedFeatures?action=PageHistory&version=19

I tried adding a verifying param to the URL ("site_token=wikilens1234") 
in case they were using a script to submit the edits directly, but it 
was circumvented immediately. It looks like they are finding the "Save" 
button somehow.

I reverted for awhile, but finally got desparate and closed my wiki to 
anonymous edits! (ALLOW_ANON_EDIT=false. Note it was broken in 1.3.9, 
which is where we .. well, forked I guess, and it was broken there, so I 
had to make a quick fix).

Any other spam filtering advice is welcome. I'd like to open up the wiki 
to anonymous edits again. :(

Dan

[Phpwiki-talk] *Penthouse> Launch party

[M E T P A R T I E S <ma...@me...>]

if you cannot view please follow: http://www.metparties.com/newsletter/penthouse/flash.html

Re: [Phpwiki-talk] unsubscribe

[Odhiambo W. <wa...@wa...>]

* On 11/10/06 20:23 +0100, Saskia Marges wrote:
> hello everybody,
> 
> I tried a thousend times to unsubscribed myself from this mailinglist. But i cant get it done!
> 
> can someone help me please?
> It says: there is no subscription as unsubscribe.
> 
> Thank you!
> 
> S. Marges

If you can post to this list and be able to see your own posts, you can
easily unsubscribe yourself.
In every post you receive, there are unsub details if you view the full
headers.


        cheers
       - wash 
+----------------------------------+-----------------------------------------+
Odhiambo Washington            		. WANANCHI ONLINE LTD (Nairobi, KE)  |
wash () WANANCHI ! com			. 1ere Etage, Loita Hse, Loita St.,  |
GSM: (+254) 722 743 223			. # 10286, 00100 NAIROBI             |
GSM: (+254) 733 744 121			. (+254) 020 313 985 - 9             |
+---------------------------------+------------------------------------------+
"Oh My God! They killed init! You Bastards!"  
						 --from a /. post

[Phpwiki-talk] unsubscribe

[Saskia M. <s.m...@he...>]

hello everybody,

I tried a thousend times to unsubscribed myself from this mailinglist. =
But i cant get it done!

can someone help me please?
It says: there is no subscription as unsubscribe.

Thank you!

S. Marges

[Phpwiki-talk] User administration stuff, pear-db done

[<tho...@la...>]

These patch and files associed permits to create and delete users, and
update their password.

Currently, only PearDb backend is done.

I used separate files to avoid memory consomption while it's not needed.

Greetings,
-- 
Thomas Harding

Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[Reini U. <rei...@gm...>]

Am just trashing my system with the overall testsuite and noticed
some minor glitches with default locale detection.
It works ok, but breaks the testsuite.

I'll release 1.3.12 as soon as some important goals are met.

From the 1.3.12 TODO list:
* DB: ANSI SQL, foreign key support, simplify methods, full
transaction tests (to be tested)
* pcre textsearch with multiple words: order-independency
* SQL textsearch with multiple words: AND
  (the two new failing unit tests)
* fix textsearch optimize with "word -word -word"
* finish moacdropdown integration (for now xmlrpc, widgets later)
* the new Mailer class (50%) + better From (to be tested)
* finish ModeratedPages (mailer)
* finish the new Toolbar buttons (memory =3D> xmlrpc)
* re-enable pagedata_cache->next iterator (?, mem test)
* investigate setupwiki and dumphtml memory consumption
  (reset cache and rcs_id in templates?)

Maybe:
* HtmlParser and importer plugins (word, excel, html, interwiki)
* TrackBack, Blog,

On 10/11/05, John Stevens <jst...@gm...> wrote:
> > I've looked this up.
> >
> > WHERE NULL=3DNULL comes from Pear::DB/oci8.php modifyLimitQuery, not
> > from our search library, so please continue your rant at the pear list
> > :)
>
>  Ah, OK.  NULL=3DNULL is not something that will break code, but it shoul=
d
> still be fixed.  I probably won't bother ranting over there.  I have bett=
er
> things to be doing ;).  But if I am so inclined..........
>
>
> > I just added DBAUTH_PREF_INSERT as suggested and as default.
>
>  And the peice of code in ./lib/WikiUser/PearDb.php that uses it I hope ;=
)
> Pretty useless without it.
>  Thanks Reini.  Keep up the good work.  When will we see a new release or
> patch release with these changes?
>  Regards
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] CreateToc.php Plugin

[Stefan <son...@ba...>]

if someone else need this, here is a corrected version of CreateToc.php

Links, =E4=F6=FC=DF/- etc. work without Errors ....

Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[Reini U. <rei...@gm...>]

On 10/4/05, John Stevens <jst...@gm...> wrote:
> > If you dig into the sources, you will see that those TRUE statements (a=
lso
> 1=3D1)
> > come from the search library, which is a pretty good library IMHO.
>
>  I must disagree with this assessment.  There should be no reason to do a
> TRUE statement like 1 or 1=3D1 or NULL=3DNULL in any SQL.  It is simply a=
 way of
> preformatting a WHERE clause so you can just keep tacking AND condition
> statments to it, if there is a reason to.  It is lazy programming.  You
> should only create a WHERE clause if there are conditions that you need t=
o
> limit a query to.  If you dont, then SELECT column1,column2 FROM tablex; =
is
> all you need.  Not SELECT column1,column2 FROM tablex WHERE 1=3D1;  That =
is
> just lazy programming.

I've looked this up.

WHERE NULL=3DNULL comes from Pear::DB/oci8.php modifyLimitQuery, not
from our search library, so please continue your rant at the pear list
:)
It's quite tricky.

Thanks for your WantedPages fix. (p.id =3D linked.linkfrom)
We got this wrong for a long time now.

I moved ISNULL to PearDB_mysql and fixed the AS issue in FROM.

> > We can easily set another SQL TRUE statement for this branch, and we
> > haven't wrote a branch optimizer yet.
> > Recommendations welcome.
> > I'm just improving the postgresql interface, and oracle is not very far
> away.
> > (foreign keys and text search improvements)
>
>  While I cannot work out where I can contribute to this, I am looking
> forward to a much better Oracle implementation and will be keen to try it
> out.

Most of the other fixes were based on older releases and already fixed
a while ago.
I just added DBAUTH_PREF_INSERT as suggested and as default.
--
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[John S. <jst...@gm...>]

This has been addressed in the patches I made to get phpwiki working with
Oracle, although not down to the config.ini.dist. See the JohnStevens page.
Also part of my gripe ;-)
Regards

On 10/10/05, Reini Urban <rei...@gm...> wrote:
>
> On 10/8/05, Thomas Harding <tho...@la...> wrote:
> > Q: Why in config-default.ini there is a REPLACE statement, which is
> > Mysql specific?
>
> Currently we have this in config-dist.ini:
> ; Update the user's preferences
> ; DBAUTH_PREF_UPDATE =3D "UPDATE pref SET prefs=3D'$pref_blob' WHERE
> userid=3D'$userid'"
> ; MYSQL: Note that REPLACE works only with mysql and destroys all other
> columns!
> ; DBAUTH_PREF_UPDATE =3D "REPLACE INTO pref SET
> prefs=3D'$pref_blob',userid=3D'$userid'"
>
> The REPLACE line is just another example for customization.
> --
> Reini Urban
> http://phpwiki.org/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[Reini U. <rei...@gm...>]

On 10/8/05, Thomas Harding <tho...@la...> wrote:
> Q: Why in  config-default.ini there is a REPLACE statement, which is
> Mysql specific?

Currently we have this in config-dist.ini:
; Update the user's preferences
; DBAUTH_PREF_UPDATE =3D "UPDATE pref SET prefs=3D'$pref_blob' WHERE
userid=3D'$userid'"
; MYSQL: Note that REPLACE works only with mysql and destroys all other col=
umns!
; DBAUTH_PREF_UPDATE =3D "REPLACE INTO pref SET
prefs=3D'$pref_blob',userid=3D'$userid'"

The REPLACE line is just another example for customization.
--
Reini Urban
http://phpwiki.org/