phpwiki-talk Mailing List for PhpWiki (Page 211)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi folks,

Where do you prefer to get bug reports? In Sourceforge BTS, in PhpWiki 
WikiWeb or on this mailing list? Or some combination of them all?

m.




On Thursday 07 November 2002 12:42, Reini Urban wrote:

> I like DynamicTextFormattingHelp a lot!
> Just a note on the text:
> Tables in new markup can be formatted with the new
> OldStyleTablePlugin.

Thanks for the compliments! NewTextFormattingRules page was locked for 
no good reason, so now you can make changes yourself as well. Of 
course, I'll refine the page according to your suggestions, just not 
right now. Must... write... thesis...

m.




Carsten Klapp schrieb:
> The NewTextFormattingRules you made looks super, I'd like to see it just 
> replace the current TextFormattingRules page.
> 
> The dynamic switching of the help at the bottom of the edit page is very 
> neat! :) I believe many old rules are probably being phased out 
> completely so a dynamic help blurb won't be necessary in the end.
> 
> Comments from anyone else on the list?

I like DynamicTextFormattingHelp a lot!
Just a note on the text:
Tables in new markup can be formatted with the new OldStyleTablePlugin.

> On Wednesday, November 6, 2002, at 08:27  pm, Matti Airas wrote:
>> After getting frustrated with the lack of integrated help page on new
>> markup rules, I created a tentative help page for it. Please get it
>> from http://mairas.net/wiki/NewTextFormattingRules.
>>
>> I don't know if it's considered kosher for PhpWiki, but to go with the
>> new help page, I also created a DHTML thingy, which automatically
>> changes the shown instructions according to the selected markup
>> version. The patch and compatibility notes are available at
>> http://mairas.net/wiki/DynamicTextFormattingHelp.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/




Hi Matti,

The NewTextFormattingRules you made looks super, I'd like to see it 
just replace the current TextFormattingRules page.

The dynamic switching of the help at the bottom of the edit page is 
very neat! :) I believe many old rules are probably being phased out 
completely so a dynamic help blurb won't be necessary in the end.

Comments from anyone else on the list?

Cheers,
Carsten

On Wednesday, November 6, 2002, at 08:27  pm, Matti Airas wrote:

> Hi all,
>
> After getting frustrated with the lack of integrated help page on new
> markup rules, I created a tentative help page for it. Please get it
> from http://mairas.net/wiki/NewTextFormattingRules.
>
> I don't know if it's considered kosher for PhpWiki, but to go with the
> new help page, I also created a DHTML thingy, which automatically
> changes the shown instructions according to the selected markup
> version. The patch and compatibility notes are available at
> http://mairas.net/wiki/DynamicTextFormattingHelp.
>
> Best regards,
>
> m.




Hi all,

After getting frustrated with the lack of integrated help page on new 
markup rules, I created a tentative help page for it. Please get it 
from http://mairas.net/wiki/NewTextFormattingRules.

I don't know if it's considered kosher for PhpWiki, but to go with the 
new help page, I also created a DHTML thingy, which automatically 
changes the shown instructions according to the selected markup 
version. The patch and compatibility notes are available at 
http://mairas.net/wiki/DynamicTextFormattingHelp.

Best regards,

m.




Carsten Klapp <car...@us...> writes:

Hi Carsten

> This is a very cool plugin, and it works nicely with C code too.

Ahh yes, I haven't thought about that...
 
> I checked it into CVS with a modification to make it compatible with
> PHP < 4.2.0 and the ability to specify colors.

Very nice indeed.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.



Jeff Dairiki schrieb:
> On 01 Nov 2002 23:48:01 +0200
> Matti Airas <ma...@ik...> wrote:
> 
> 
>>The PhpWeather plugin was a bit outdated. I made it work with the
>>current CVS version and added some new features.
> 
> Reini,
> 
> You seem to be the one who wrote the plugin.  Do you have time to
> look at Matti's patches anytime soon?  (If not, I can merge them
> into the CVS code.)

I'll do, but give me some time. A week or so.

> Do we really want to drop support for older versions of PhpWeather?
> (My vote is "yes", but my vote shouldn't count for much since I don't
> use PhpWeather...)

Ok. I'll test. When I added support for the old version, the new one 
didn't work good enough for me.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/




Hi Martin,

This is a very cool plugin, and it works nicely with C code too.

I checked it into CVS with a modification to make it compatible with 
PHP < 4.2.0 and the ability to specify colors. (Time for me to think 
about upgrading my PHP).

Thanks,
Carsten

On Sunday, November 3, 2002, at 06:32  pm, Martin Geisler wrote:

> I have a tutorial on PHP at my WikiWikiWeb, so I wrote a WikiPlugin,
> that will highlight some PHP code using highlight_string(). It can be
> seen in action here:




Hi everybody!

I have a tutorial on PHP at my WikiWikiWeb, so I wrote a WikiPlugin,
that will highlight some PHP code using highlight_string(). It can be
seen in action here:

  http://www.gimpster.com/phpwiki/index.php/PhpTutorial/PrinterFriendly

(This page demonstrates a problem with the IncludePage plugin and
subpages: a relative link like /Intro on PhpTutorial is interpreted as
a relative link from PhpTutorial/PrinterFriendly when PhpTutorial is
seen through IncludePage on PhpTutorial/PrinterFriendly.)

The code for the plugin is very simple:

/**
 * A plugin that runs the highlight_string() function in PHP on it's
 * arguments to pretty-print PHP code.
 *
 * Usage:
 * <?plugin PhpHighlight
 * code that should be highlighted
 * ?>
 *
 * You should not add '<?php' and '?>' to the code - the plugin does
 * this automatically.
 *
 * Author: Martin Geisler <gim...@gi...>.
 */

class WikiPlugin_PhpHighlight
extends WikiPlugin
{
    // Four required functions in a WikiPlugin.

    function getName () {
        return _("PhpHighlight");
    }

    function getDescription () {
        return _("PHP syntax highlighting");

    }
    // Establish default values for each of this plugin's arguments.
    function getDefaultArguments() {
        return array();
    }

    function run($dbi, $argstr, $request) {

        $str = highlight_string("<?php\n" . $argstr . "\n?>", true);
        /* Remove "<?php\n" and "\n?>": */
        $str = str_replace(array('&lt;?php<br />', '?&gt;'), '', $str);
        /* We might have made some empty font tags: */
        $search = '<font color="' . ini_get('highlight.default') . '"></font>';
        $str = str_replace($search, '', $str);

        return new RawXml($str);
    }
};

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.



I have been trying to get VisualWiki to work, with no success. After
minor tweaking I got so far that GraphViz actually generates the image
and the imagemap. However, the calls to getimg.php always fail,
resulting in no image. If I cut'n'paste the call from the HTML source
and try to call getimg.php by itself, I always get the following error:

Fatal error: Call to undefined function: getdbh() in
/var/www/mairas.net/html/phpwiki/lib/WikiUser.php on line 50

I really can't understand the reason for the error, since the request
object would seem to be there, and in any case the same method gets
called also during regular page requests...

BTW, I tried to debug the object by serializing it to error_log, but the
result wasn't very informative. What would be a better way?

Best regards,

m.





la, 02-11-2002 kello 01:02, Jeff Dairiki kirjoitti:

> If updated http://phpwiki.sourceforge.net/phpwiki/PrettyWiki,
> take a look and make any appropriate changes...

OK, did that.

m.





On 01 Nov 2002 23:48:01 +0200
Matti Airas <ma...@ik...> wrote:

> The PhpWeather plugin was a bit outdated. I made it work with the
> current CVS version and added some new features.

Reini,

You seem to be the one who wrote the plugin.  Do you have time to
look at Matti's patches anytime soon?  (If not, I can merge them
into the CVS code.)

Do we really want to drop support for older versions of PhpWeather?
(My vote is "yes", but my vote shouldn't count for much since I don't
use PhpWeather...)



> Just wondering whether there is any call for having the wiki css
> editable as a wiki page.  Any views?

My first reaction (at least today) is that it's a bad idea.

In order to produce optimal^H^H^H^H^H^Hacceptable results with as many
browsers as possible, the CSS is pretty finely tuned.  Changes (at least
in
the default CSS's) really should be tested using as many browsers as
possible
before being accepted.

Having (anonymous) user editable CSS seems like a really bad idea to me.
(A nasty guy could hide text, etc...  --- who knows what really.)

Having admin-editable CSS would be okay, I guess --- but really: why
not just edit the file?

Now, if a user were allowed to edit only the CSS he sees (this would
be like a user preference), I guess that would be okay.  But it could
be dreadfully confusing...  Allowing the user to specify alternate
style sheets (of his own choosing) is probably a more reasonable solution.

Jeff



Thanks for the info, Matti.

It turns out that ForceType (instead of SetHandler) works with
(at least my) Apache 1.3.x.

If updated http://phpwiki.sourceforge.net/phpwiki/PrettyWiki,
take a look and make any appropriate changes...

I see no point of fixing config.php so that it turns on
USE_PATH_INFO by default under apache 2.0, since it seems that
default installations of 2.0 don't support PATH_INFO...
If someone can figure out a way to determine whether AcceptPathInfo
is enabled or not, that would be different.

At this point, I think I'll just put a pointer to PrettyWiki in the
index.php comments...





pe, 01-11-2002 kello 21:48, Jeff Dairiki kirjoitti:

> In order that we can try to fix the auto-detection:
> 
> Can you tell me what php_sapi_name() returns on your system.
> Apparently, it's something other than 'apache'.

apache2filter

> Also, is there way one can tell (from PHP) whether AcceptPathInfo
> is on or not?  I assume if (defined($_SERVER['PATH_INFO'])) then
> AcceptPathInfo is enabled, but I don't think the converse is true.
> (If the URL does not contain any trailing path info, then (at least
> in Apache 1.3.x, PATH_INFO is undefined (not just empty).)

If AcceptPathInfo is on, PATH_INFO behaves exactly as in Apache 1.x,
i.e. it may either be undefined or defined, depending on the actual
path.

Unfortunately I have no idea whether the value of AcceptPathInfo can be
deduced from within PHP. Maybe someone with more experience on PHP can
answer that?

However, since the preferred installation method (as described in
http://phpwiki.sourceforge.net/phpwiki/PrettyWiki) requires modifying
the top-level .htaccess or the server configuration, IMHO it would be
simpler to just provide a sample top-level .htaccess like follows:

<IfDefine APACHE2>
   AcceptPathInfo on
   ForceType application/x-httpd-php
</IfDefine>
<IfDefine !APACHE2>
   SetHandler application/x-httpd-php
</IfDefine>

Hmm... Of course, AcceptPathInfo setting should still be detected
somehow, or else it might be difficult to get PhpWiki to work reliably
out-of-the-box... Suggestions for workarounds?

Cheers,

m.





The PhpWeather plugin was a bit outdated. I made it work with the
current CVS version and added some new features.

The patches are attached. The first makes it work with the current CVS
version (and removes support for old versions). The second adds some new
options and features.

The documentation can be pulled out from 

http://mairas.net/wiki/PhpWeatherPlugin

As usual, I only have tested it with my setup and current PHP Weather
nightly.

Cheers,

m.


Just wondering whether there is any call for having the wiki css editable as a 
wiki page.  Any views?

Lawrence





Just in case anyone is wondering ....

I said a week ago that I would finish a file upload patch within a few days.  I 
haven't, because I have been away from home for a week.  Sorry.

Watch this space ....

Lawrence





> It's notable that the comment in index.php suggests that
> USE_PATH_INFO is by default true. Well, this is not quite true. :-)

If you don't explicitly set USE_PATH_INFO, then it's value is
auto-determined by the following code (in lib/config.php):

    if (php_sapi_name() == 'apache')
        define('USE_PATH_INFO', true);
    else
        define('USE_PATH_INFO', ereg('\.(php3?|cgi)$', $SCRIPT_NAME));

I don't currently have access to a machine running Apache 2.0.  (And
I don't want to install it right now...)

In order that we can try to fix the auto-detection:

Can you tell me what php_sapi_name() returns on your system.
Apparently, it's something other than 'apache'.

Also, is there way one can tell (from PHP) whether AcceptPathInfo
is on or not?  I assume if (defined($_SERVER['PATH_INFO'])) then
AcceptPathInfo is enabled, but I don't think the converse is true.
(If the URL does not contain any trailing path info, then (at least
in Apache 1.3.x, PATH_INFO is undefined (not just empty).)

Jeff




> Definition lists that had a colon somewhere in the intended <dd>
> element, were broken because of a too greedy regular expression. I
> finally found the offending operation. Alas, here:

Thanks Matti!  I've just checked your patch into the CVS.



> Maybe a silly question, but I am using php1.3.3 and I cannot format
> tables. Is there something I need to setup from default? The
> 'textformattingrules' page works with table formatting but not my normal
> pages.

(This should go in the FAQ if it's not there already...)

We're in the midst of a (very slow) transition to a new set of
markup rules.   Starting in 1.3.3 there's a checkbox on the edit
form which determines whether the page is displayed using the old
or new rules.  The default for new pages is to use the new rules.
(TextFormattingRules describes the old markup rules.)

The new rules are described, more or less, at
  http://phpwiki.sf.net/phpwiki/NewBlockMarkup
and
  http://phpwiki.sf.net/phpwiki/NewInlineMarkup

The new rules are not backwards-compatible with the old rules.
(Though backward-compatibility is kept, as much as is possible.)

One of the big differences, which you've discovered, is that the
old-style tables don't work with the new formatting rules.

You have several choices on how to get tables:

  1. Use the old formatting rules (uncheck the checkbox on the
     edit-page form) and use old-style tables.

  2. Use the new formatting rules, and use the new
     "definition list" style tables.  Not all table structures
     can be represented, but if they can, the new syntax is,
     IMHO, much more natural and cleaner...

        Type 1 |
           Variation A |
               Description of type A-1.
           Variation B |
               Or you can use type B-1.
        Type 2 |
           And so forth.

     gets you

        +---------+---------------+---------------------------+
        |         |  Variation A  |  Description of type A-1. |
        | Type 1  +---------------+---------------------------+
        |         |  Variation B  |  Or you can use type B-1. |
        +---------+---------------+---------------------------+
        | Type 2  |  And so forth.                            |
        +---------+-------------------------------------------+

  3. The current CVS code (but not 1.3.3) has an OldStyleTable
     plugin which can be used to include old-style tables
     within new-style pages.

        <?plugin OldStyleTable
        | Col 1 | Col 2
        | a     | b
        ?>




Hello All,

testing PhpWiki I found that people don't see that the PhPWiki icon 
is the link to HomePage.

Therefore I added an explicit link in the navbar (.tmpl).

Maybe I had the wrong test persons <g>, but likely a better 
recognizable HomePage link is useful.

Oliver



Hello Carsten,

[...]

> Removing img { vertical-align: baseline; } might affect the position of 
> LinkIcons in body text for some browsers, probably nothing else. 

Thanks for the explanation.

LinkIcons (always "default" theme) are at the right position with 
Opera 6.05, Mozilla 1.1, IE5, IE6, so I let the css line commented 
out.

BTW: I read "/* for NS4 */" above the "img { vertical-align: 
baseline; }" line, but the "-heavy.css" shouldn't be imported by NS4 
as far as I understand phpwiki.css.

Oliver



Maybe a silly question, but I am using php1.3.3 and I cannot format
tables. Is there something I need to setup from default? The
'textformattingrules' page works with table formatting but not my normal
pages.

Thanks.
Rex.




Hi,

Definition lists that had a colon somewhere in the intended <dd>
element, were broken because of a too greedy regular expression. I
finally found the offending operation. Alas, here:

--clip----clip----clip----clip----clip----clip----clip----clip----clip--

--- /tmp/phpwiki/lib/BlockParser.php    2002-09-17 22:23:32.000000000
+0300
+++ lib/BlockParser.php 2002-11-01 04:17:35.000000000 +0200
@@ -717,7 +717,7 @@
     //var $_tag = 'ol', 'ul', or 'dl';
     var $_re = '(?: [*] (?! \S[^*]* (?<=\S) [*](?!\S) )
                   | [#] (?! \[ .*? \] )
-                  | ; .* :
+                  | ; .*? :
                 ) .*? (?=\S)';

     function _match (&$input, $m) {
--clip----clip----clip----clip----clip----clip----clip----clip----clip--

After applying the patch pages like CalendarPlugin are showed correctly
again.

BR,

Matti Airas






2000	Jan	Feb	Mar	Apr	May (1)	Jun (103)	Jul (105)	Aug (16)	Sep (16)	Oct (78)	Nov (36)	Dec (58)
2001	Jan (100)	Feb (155)	Mar (84)	Apr (33)	May (22)	Jun (77)	Jul (36)	Aug (37)	Sep (183)	Oct (74)	Nov (235)	Dec (165)
2002	Jan (187)	Feb (183)	Mar (52)	Apr (10)	May (15)	Jun (19)	Jul (43)	Aug (90)	Sep (144)	Oct (144)	Nov (171)	Dec (78)
2003	Jan (113)	Feb (99)	Mar (80)	Apr (44)	May (35)	Jun (32)	Jul (34)	Aug (34)	Sep (30)	Oct (57)	Nov (97)	Dec (139)
2004	Jan (132)	Feb (223)	Mar (300)	Apr (221)	May (171)	Jun (286)	Jul (188)	Aug (107)	Sep (97)	Oct (106)	Nov (139)	Dec (125)
2005	Jan (200)	Feb (116)	Mar (68)	Apr (158)	May (70)	Jun (80)	Jul (55)	Aug (52)	Sep (92)	Oct (141)	Nov (86)	Dec (41)
2006	Jan (35)	Feb (62)	Mar (59)	Apr (52)	May (51)	Jun (61)	Jul (30)	Aug (36)	Sep (12)	Oct (4)	Nov (22)	Dec (34)
2007	Jan (49)	Feb (19)	Mar (37)	Apr (16)	May (9)	Jun (38)	Jul (17)	Aug (31)	Sep (16)	Oct (34)	Nov (4)	Dec (8)
2008	Jan (8)	Feb (16)	Mar (14)	Apr (6)	May (4)	Jun (5)	Jul (9)	Aug (36)	Sep (6)	Oct (3)	Nov (3)	Dec (3)
2009	Jan (14)	Feb (2)	Mar (7)	Apr (16)	May (2)	Jun (10)	Jul (1)	Aug (10)	Sep (11)	Oct (4)	Nov (2)	Dec
2010	Jan (1)	Feb	Mar (13)	Apr (11)	May (18)	Jun (44)	Jul (7)	Aug (2)	Sep (14)	Oct	Nov (6)	Dec
2011	Jan (2)	Feb (6)	Mar (3)	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2012	Jan (11)	Feb (3)	Mar (11)	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov (4)	Dec
2013	Jan	Feb	Mar	Apr (3)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar	Apr	May (4)	Jun	Jul	Aug	Sep	Oct	Nov (8)	Dec (1)
2015	Jan (3)	Feb (2)	Mar	Apr (3)	May (1)	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec (2)
2016	Jan	Feb (4)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul (3)	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar	Apr	May (3)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar	Apr	May (3)	Jun	Jul (5)	Aug	Sep	Oct	Nov	Dec
2021	Jan	Feb (4)	Mar	Apr	May	Jun	Jul (1)	Aug (6)	Sep (3)	Oct	Nov	Dec
2022	Jan (11)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov (3)	Dec (3)
2024	Jan (7)	Feb (2)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2025	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul (3)	Aug	Sep	Oct	Nov	Dec