On Thu, 22 Nov 2001 22:57:51 -0000
"Lawrence Akka" <Lawrence_Akka@...> wrote:
> Just wondering what the position was on XML dumps. I see some
> refs to in in the code, but it obvously isn't complete.
Yes, that's my fault.
I started to add XML dumps (mostly to replace the zip-dump functionality),
then
got bogged down while trying to decide on the syntax.
Should RDF be used for the page meta-data? (RDF having been designed
for that purpose.) (This would also fit in well with RSS generation.)
Consideration for ability to edit wiki pages via XML-ized methods:
Think about SOAP? How does this tie in with WebDAV?
Or just use a more ad hoc document-like syntax. Neither RDF nor SOAP
are
very document-like in structure.
At this point, I know nothing about WebDAV, not much about SOAP, and a
little
about RDF and RSS. That's where I stopped.
(See http://www.usemod.com/cgi-bin/mb.pl?RssExtensionModuleForWikis for
the latest
news on the wiki RSS front.)
So, if we're serious about XML dumps, I think we need to put some serious
thought
and discussion into the format of the dumps. If you want to pick up the
ball
on that, that would be great. (I don't mind doing the coding, once
there's
agreement on a suitable XML syntax.)
Jeff

On Tue, 18 Jul 2000 15:10:28 -0700
Jeff Dairiki <dairiki@...> wrote:
> However, I kind of like the line-by-line processing. It keeps
> goofs in one line from hosing the whole page.
It is significantly easier to do proper table support with
line-by-line processing. Further whole file processing allows
several easy optimisations.
--
J C Lawrence Home: claw@...
---------(*) Other: coder@...
http://www.kanga/nu/~claw/ Keys etc: finger claw@...
--=| A man is as sane as he is dangerous to his environment |=--

On Wed, 07 Feb 2001 11:19:29 -0800
Jeff Dairiki <dairiki@...> wrote:
> If there's a push for keeping the mark-up simple, why footnotes?
> Carrying the references around as page meta-data has been a
> pain-in-the-database-code. Why not just get rid of it all?
Wikis are cominginto increasing use as engineering and coroporate
documentation systems (usually with various sorts of access and
versioning control). Footnotes are almost a requirement for
engineering Wikis -- especially for technical review or analysis
documents.
> User ID's / Logins:
> I think they're a good idea. (Useful for some sites, at least.)
SourceForge has a fairly pleasant bit of PHP code to handle user
registrations with email confirmations etc. I've been extending it
here to support PHPLib-style templates (I'm actually using a
superset of PHPLib's template class) and its pretty clean code.
> On a related note, there's a bug:
> Currently 'index.php?zip=all' will get you to the wiki page
> named 'zip=all'. This is probably a bad idea ('zip=all' is an
> allowable page name, but it should have to be url-encoded.) I'll
> fix this unless you object.
Best would be to remove all ? and & URL variables to make it easier
for search engines to index public Wikis.
--
J C Lawrence claw@...
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--

On Wed, 7 Feb 2001, J C Lawrence wrote:
>
> Best would be to remove all ? and & URL variables to make it easier
> for search engines to index public Wikis.
That's now on the task list and will be in the next stable version.
~swain
...............................ooo0000ooo.................................
Hear FM quality freeform radio through the Internet: http://wcsb.org/
home page: http://www.wcsb.org/~swain

I've put a new jeffshacks snapshot up.
The new pgsql is working.
Deletion of old archived revisions is implemented.
I've been playing with the style sheets, so the look has changed
quite a bit. I haven't tested my stylesheet hacks at all with IE yet
(only
Netscape and Mozilla) so it could well be unreadable with IE at
this point.
A live demo is up at:
http://phpwiki.sf.net/jeffs-hacks/wiki/
A tar-ball of the source code can be found at:
http://phpwiki.sf.net/jeffs-hacks/files/
Jeff

> I've been playing with the style sheets, so the look has changed quite
> a bit. I haven't tested my stylesheet hacks at all with IE yet (only
> Netscape and Mozilla) so it could well be unreadable with IE at this
> point.
this is really nice! great work. two bug reports (that i'm sure you
already know about):
* it says log in with any username/password but it wouldn't let me. i
just kept getting the auth box pop up again until i selected "Cancel"
when it told me i had an invaled user/password.
* at the bottom of the page there is an error:
In template:82: Notice[8]: Undefined variable: RELATEDPAGES:
<small>${RELATEDPAGES}</small>
i'm getting exciting about migrating to phpwiki! keep up the good work
guys.
adam.

On Sep 10, 2001, Adam Shand said:
>
> this is really nice! great work.
Thanks!
> two bug reports (that i'm sure you already know about):
>
> * it says log in with any username/password but it wouldn't let me. i
> just kept getting the auth box pop up again until i selected "Cancel"
> when it told me i had an invaled user/password.
Yes. This is browser dependent, and has to do with whether your
browser accepts new cookies as part of a "401 Access Denied"
response. (Mozilla doesn't, NS4 does...) I have fixed this
in my latest version by using PHP sessions rather than cookies
to store the login state -- but that's a kludge, too.
Using HTTP authentication to query for usernames and passwords that
we, the PHP app, process is all a big hack in the first place.
I plan on doing away with that soon...
> * at the bottom of the page there is an error:
>
> In template:82: Notice[8]: Undefined variable: RELATEDPAGES:
> <small>${RELATEDPAGES}</small>
Yes that's just to remind me that I haven't implemented methods
for indexing RelatedPages (or some replacement for it) in the
new database API yet.
I suppose I should just put it on a TODO list instead :-)
Jeff

> I've put a new snapshot up. Demo and pointer to code at:
>
> http://phpwiki.sourceforge.net/jeffs-hacks/wiki/
this is great! any chance of making categories meta data which is
selected via drop box on the edit page? and maybe a similar thing for
sub-categories? i know it kinda breaks the wiki ideal but i think it's
going to become increasingly useful as wiki's increase in complexity.
also are comments (ie. they show up in the edit box but not on the actual
wiki page) a possibility?
this is looking really really good guys, great stuff.
adam.

On Mon, 17 Sep 2001 11:09:39 -0700
Jeff Dairiki <dairiki@...> wrote:
> What to do? Should you be allowed to take over the existing
> page as your homepage? (What if you were trying to register under
> the userid of FrontPage or CategoryNextWiki?)
This becomes easier if you make add support for a hierarchial
namespace (SubNodes) and then make people's pages bot a subnodes of
a common node (eg People), and then disallow other than automatic
creation of pages there. This has the pleasant side effect of
allowing the person's own page to (depending on your clocking
choices) to be under their control, which other pages out in the
publicly controlled namespace are more laissez faire.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@... He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

On Tue, 27 Nov 2001 09:44:19 -0800
Jeff Dairiki <dairiki@...> wrote:
> On Thu, 22 Nov 2001 22:57:51 -0000 "Lawrence Akka"
> <Lawrence_Akka@...> wrote:
> Consideration for ability to edit wiki pages via XML-ized
> methods: Think about SOAP? How does this tie in with WebDAV?
Support for an XML/RPC layer would be more interesting, especially
something that can integrate with Jabber ala Jogger:
http://jogger.jabber.org/
It would also be interesting/useful to extend the auth model to use
Jabber as a federated auth mechanism (a number of CMS tools such as
Drupal are already doing this).
http://www.drop.org/node.php?id=531&cid=1166http://www.drop.org/node.php?id=672
And on an Apache-specific level:
http://research.covalent.net/mod_auth_jabber/
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@... He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

J C Lawrence schrieb:
> Support for an XML/RPC layer would be more interesting, especially
> something that can integrate with Jabber ala Jogger:
>
> http://jogger.jabber.org/
Jabber look's good, but I personally don't like jabber that much.
Tried some days to install a jabber based chat client on my Suse 7.2
and 7.0 but failed. The simple ircd server worked out of the box.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

On Wed, 28 Nov 2001 02:07:59 +0000
Reini Urban <rurban@...> wrote:
> J C Lawrence schrieb:
> Jabber look's good, but I personally don't like jabber that much.
Any reasons other than your problems with client install?
> Tried some days to install a jabber based chat client on my Suse
> 7.2 and 7.0 but failed.
Gabber is the most actively developed OSS Jabber client, but is
(unfortunately) heavily Gnome oriented. Jarl is a CLI and Perl/TK
cleitn that is essentially trivially self-installing. Not fully
featured, but works reliably here.
Then there's things like EveryBuddy which have Jabber compatability.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@... He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

> Philip J. Hollenback schrieb:
>
> > 3. Crao nav bar is messed up in Forefox/Mac OS X. Specifically, the
> > 'prefs / admin / search' buttons and box on the right side are stacked
> > vertically instead of spread in a horizontal line like they should be.
> > I don't see this behavior with Safari.
This is due to themes/Crao/templates/navbar.tmpl, line 20:
<td align="right" width="150">
Remove the width attribute, and the right end of the nav bar has sufficient
space to display on a single line. That solves the problem for Firefox.
Unfortunately, I think the width attribute is there to coax IE into rendering
the navbar correctly---without the width, the navbar extends well past
the right edge of the box containing the page contents. ARGH!
> > 4. I could be imagining things, but the floating ttolbar on the bottom
> > of the Crao theme now slows down page scrolling significantly. I don't
> > think it used to.
>
> That's entirely a browser issue. Unfortunately the developer of this
> theme cannot check against MSIE.
Scrolling, in both IE and Firefox, seems the same for me with the Crao
theme.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joel Uckelman a écrit :
>>Philip J. Hollenback schrieb:
>>
>>
>>>3. Crao nav bar is messed up in Forefox/Mac OS X. Specifically, the
>>>'prefs / admin / search' buttons and box on the right side are stacked
>>>vertically instead of spread in a horizontal line like they should be.
>>>I don't see this behavior with Safari.
>
>
> This is due to themes/Crao/templates/navbar.tmpl, line 20:
>
> <td align="right" width="150">
>
> Remove the width attribute, and the right end of the nav bar has sufficient
> space to display on a single line. That solves the problem for Firefox.
> Unfortunately, I think the width attribute is there to coax IE into rendering
> the navbar correctly---without the width, the navbar extends well past
> the right edge of the box containing the page contents. ARGH!
>
>
>>>4. I could be imagining things, but the floating ttolbar on the bottom
>>>of the Crao theme now slows down page scrolling significantly. I don't
>>>think it used to.
>>
>>That's entirely a browser issue. Unfortunately the developer of this
>>theme cannot check against MSIE.
>
>
> Scrolling, in both IE and Firefox, seems the same for me with the Crao
> theme.
Crao Theme used to work well ... until Reini changed stuff in it :) (oh
... a troll comes accross the screen slowly walking ...)
It used to be a table free theme ... so any table related stuff ...
Well ... anyway, I changed some things in the theme, simplified the css,
added some permission checked, etc ...
Laurent (the co-author) will drop the tables again then we'll commit the
new crao version.
BTW, we can now check on MSIE thanks to vmware ...
We also have two brand new themes to commit ... just have to change the
way I deal with discussion pages (I coded discussions links long before
Reini add them into the default theme but not the same way. Reini's way
is better ... I gonna change my themes).
- --
Arnaud Fontaine
CRAO
Jabber: shinobi@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCWVlJyAf3wgFyy1ARAvluAKCqPbWw9CAn3O9ZQsEThPidn/XL3gCfayUh
maZDK7zGr3gR3otRPCqOJws=
=XXwg
-----END PGP SIGNATURE-----

I just checked http://www.hollenback.net on IE 6.0, Win2K and it looks pretty
bad. Specifics below, but bottom line is the Crao theme that ships with
1.3.11rc3 has serious rendering problems in IE that have to be
addressed.=20
On Sun, 10 Apr 2005 18:50:18 +0200, "Arnaud Fontaine" <arnaud@...>
said:
> Joel Uckelman a =E9crit :
> >>Philip J. Hollenback schrieb:
> >>>3. Crao nav bar is messed up in Forefox/Mac OS X. Specifically, the
> >>>'prefs / admin / search' buttons and box on the right side are stacked
> >>>vertically instead of spread in a horizontal line like they should be.
> >>>I don't see this behavior with Safari.
> >=20
> > This is due to themes/Crao/templates/navbar.tmpl, line 20:
> >=20
> > <td align=3D"right" width=3D"150">
> >=20
> > Remove the width attribute, and the right end of the nav bar has suffic=
ient
> > space to display on a single line. That solves the problem for Firefox.
> > Unfortunately, I think the width attribute is there to coax IE into ren=
dering
> > the navbar correctly---without the width, the navbar extends well past
> > the right edge of the box containing the page contents. ARGH!
I left that setting alone in navbar.tmpl and I observe that the navbar
goes way too far off to the right. So if that 150px setting is there to
fix that, it's not working on my setup.
I just checked http://crao.net/wiki and it exhibits this problem as
well.
Other problems:
1. The larger fonts look bad (i.e. h1, h2, etc). They're jagged and not
scaled well. I would say the base font is a little too large, then the
steps for each successive font are too big. Thus the largest heading
fonts are enormous.
crao.net does not exhibit this problem.
2. The bottom toolbar does not float on the bottom of the screen,
instead it's stuck on the bottom of the actual page. I assume that's
just because getting IE to support that is just too hard, so I'm not
particularly worried about it.
crao.net has this problem as well, but like I said this isn't a
showstopper.
3. A bigger bottom toolbar problem is that it doesn't scale in width
properly. Even when the user is not logged in, it's still the same
width as if you were logged in (i.e. there is blank space on the left of
the toolbar for the icons only a logged-in user sees.
crao.net has this problem too.
4. The topbar is too tall - there is a gap above and below the wiki logo
text, when it should be flush.
I saw this same problem in my old 1.3.10 setup, and I seem to remember
it was due to some weirdness in the css for the topbar. I fixed it then
and I suspect a diff of the css file will reveal where that is.
crao.net does not have this problem.
> Crao Theme used to work well ... until Reini changed stuff in it :) (oh
> ... a troll comes across the screen slowly walking ...)
> It used to be a table free theme ... so any table related stuff ...
>=20
> Well ... anyway, I changed some things in the theme, simplified the css,
> added some permission checked, etc ...
>=20
> Laurent (the co-author) will drop the tables again then we'll commit the
> new crao version.
I really like the clean, modern look of the Crao theme. I really,
really hope we can get all the interface glitches worked out in that
theme before 1.3.11 final. Arnaud, any help would be much appreciated,
and if you guys can get me that new crao theme I will be happy to test
it asap.
Administrative question: should I be filing all these problems in the
sf.net bug tracker? I say yes because they are against files included
in phpwiki, but I just wanted to make sure that's the most effective way
to go. Arnaud, do you check the Crao bugs that are posted there?
Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
have to stick that javascript hack for IE to make transparent PNGs work
back into my phpwiki.
Thanks,
P.
--=20=20
Philip J. Hollenback
philiph@...
http://www.hollenback.net

Philip J. Hollenback schrieb:
> Administrative question: should I be filing all these problems in the
> sf.net bug tracker? I say yes because they are against files included
> in phpwiki, but I just wanted to make sure that's the most effective way
> to go. Arnaud, do you check the Crao bugs that are posted there?
I would prefer this. It raises our sf-wide statistics activity level :)
Maybe we can make under the top ten again during 1.3.11 final.
> Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
> have to stick that javascript hack for IE to make transparent PNGs work
> back into my phpwiki.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/http://phpwiki.org/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Philip J. Hollenback a écrit :
> I just checked http://www.hollenback.net on IE 6.0, Win2K and it looks pretty
> bad. Specifics below, but bottom line is the Crao theme that ships with
> 1.3.11rc3 has serious rendering problems in IE that have to be
> addressed.
Good news for all : Laurent has set up a new 300 euros winxp box just to
be able to test themes with those crappy browsers :)
> I just checked http://crao.net/wiki and it exhibits this problem as
> well.
Right ... (btw, it's wiki.crao.net ...)
> 1. The larger fonts look bad (i.e. h1, h2, etc). They're jagged and not
> scaled well. I would say the base font is a little too large, then the
> steps for each successive font are too big. Thus the largest heading
> fonts are enormous.
????????????????????????????
isn't it a problem local to your config ?
> 2. The bottom toolbar does not float on the bottom of the screen,
> instead it's stuck on the bottom of the actual page. I assume that's
> just because getting IE to support that is just too hard, so I'm not
> particularly worried about it.
Right ... the floating stuff doesn't work with IE ... I'll ask Laurent
if he has found a nice hack.
> 3. A bigger bottom toolbar problem is that it doesn't scale in width
> properly. Even when the user is not logged in, it's still the same
> width as if you were logged in (i.e. there is blank space on the left of
> the toolbar for the icons only a logged-in user sees.
Yet another table related problem ... As I said, we're working on
another table free crao version (Reini, you'll not be allowed to add
tables to it ;))
> 4. The topbar is too tall - there is a gap above and below the wiki logo
> text, when it should be flush.
Might be a side effect of another problem.
> Administrative question: should I be filing all these problems in the
> sf.net bug tracker? I say yes because they are against files included
> in phpwiki, but I just wanted to make sure that's the most effective way
> to go. Arnaud, do you check the Crao bugs that are posted there?
Ok ... I'll check the sf bug tracker to raise the stats ;)
> Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
> have to stick that javascript hack for IE to make transparent PNGs work
> back into my phpwiki.
Why don't you all switch to firefox ? :)
- --
Arnaud Fontaine
CRAO
Jabber: shinobi@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCWspOyAf3wgFyy1ARAirAAJwNo38OCP1FKQpF7AWbSX4wI0u03gCg0nMh
JNzcSfykJLwoRBHWKnvae28=
=4y1i
-----END PGP SIGNATURE-----

Arnaud Fontaine schrieb:
>>3. A bigger bottom toolbar problem is that it doesn't scale in width
>>properly. Even when the user is not logged in, it's still the same
>>width as if you were logged in (i.e. there is blank space on the left of
>>the toolbar for the icons only a logged-in user sees.
>
> Yet another table related problem ... As I said, we're working on
> another table free crao version (Reini, you'll not be allowed to add
> tables to it ;))
I hope that I will not forget it :)
> Ok ... I'll check the sf bug tracker to raise the stats ;)
>
>
>>Oh, and ignore the fact that the topbar textlogo is all ugly in IE - I
>>have to stick that javascript hack for IE to make transparent PNGs work
>>back into my phpwiki.
>
>
> Why don't you all switch to firefox ? :)
It's not us. It's the userbase out there which we have to support.
I just had to add some stupid iehacks to the "smaller" theme, just for
the size of lower actionbar buttons.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/http://phpwiki.org/

On 04/10/05, Joel Uckelman wrote:
> > Philip J. Hollenback schrieb:
> >
> > > 3. Crao nav bar is messed up in Forefox/Mac OS X. Specifically, the
> > > 'prefs / admin / search' buttons and box on the right side are stacked
> > > vertically instead of spread in a horizontal line like they should be.
> > > I don't see this behavior with Safari.
>
> This is due to themes/Crao/templates/navbar.tmpl, line 20:
>
> <td align="right" width="150">
>
> Remove the width attribute, and the right end of the nav bar has sufficient
> space to display on a single line. That solves the problem for Firefox.
> Unfortunately, I think the width attribute is there to coax IE into rendering
> the navbar correctly---without the width, the navbar extends well past
> the right edge of the box containing the page contents. ARGH!
I share your sentiment. Another IE issue: I use a transparent png for
my image/title at the top left. That doesn't render properly in IE 5.x
cause it doesn't understand transparent PNGs.
I found a javascript snippet that does some sort of magic to fix that
for IE. Is there any interest in incorporating that into phpwiki? It's
useful anywhere you want to use transparent pngs in themes. It does
bloat every page somewhat, but the javascript is only executed when the
correct version of IE is detected, so the effect on other browsers in
minimal.
It's the usual problem of how far do you go to support different
browsers.
Thanks for the tip on how to fix this, I will tweak the layout to see if
I can come up with something that works on IE and other browsers.
> > > 4. I could be imagining things, but the floating ttolbar on the bottom
> > > of the Crao theme now slows down page scrolling significantly. I don't
> > > think it used to.
> >
> > That's entirely a browser issue. Unfortunately the developer of this
> > theme cannot check against MSIE.
>
> Scrolling, in both IE and Firefox, seems the same for me with the Crao
> theme.
Huh. Wonder if it's a problem with Firefox on the mac only? I will
test Firefox and Konqueror on Linux tomorrow and report.
--
Philip J. Hollenback
http://www.hollenback.net

Philip J. Hollenback schrieb:
> On 04/10/05, Joel Uckelman wrote:
> I share your sentiment. Another IE issue: I use a transparent png for
> my image/title at the top left. That doesn't render properly in IE 5.x
> cause it doesn't understand transparent PNGs.
I know of this transparent PNG js hack for older IE's, but I thought we
could go without it so far.
Well, if you can send it along, I will put it in.
> I found a javascript snippet that does some sort of magic to fix that
> for IE. Is there any interest in incorporating that into phpwiki? It's
> useful anywhere you want to use transparent pngs in themes. It does
> bloat every page somewhat, but the javascript is only executed when the
> correct version of IE is detected, so the effect on other browsers in
> minimal.
>
> It's the usual problem of how far do you go to support different
> browsers.
>
> Thanks for the tip on how to fix this, I will tweak the layout to see if
> I can come up with something that works on IE and other browsers.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/http://phpwiki.org/