phpwiki-talk

[Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Todd M. <nil...@ne...>]

With current cvs, if you have a plugin as part of a list, TightSubBlock
errors out with: "PHP Fatal error:  Call to undefined function: 
gettag() in lib/BlockParser.php on line 421"

The problem is that $elem in that line of code is an instance of
Cached_PluginInvocation, which does not inherit from XmlElement.  I'm
not sure if plugins shouldn't be allowed in lists and this error caught,
or other changes are needed to allow this.

--start example--
test:
  <?plugin HelloWorld ?>

or

* <?plugin HelloWorld ?>
--end example--


-- 
Todd Mokros <nil...@ne...>

Re: [Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Todd M. <tm...@ne...>]

As a quick fix, the following patch seems to work for me.
The only problem would be that the is_a() function requires php >=
4.2.0.  The method_exists function should work with all PHP4 versions,
but is an uglier way to check.  The patch might get wrapped by my
mailer, but should be easy patch by hand.


Index: BlockParser.php
===================================================================
--- BlockParser.php     (revision 52)
+++ BlockParser.php     (working copy)
@@ -418,7 +418,7 @@
         // If content is a single paragraph, eliminate the paragraph...
         if (count($this->_content) == 1) {
             $elem = $this->_content[0];
-            if ($elem->getTag() == 'p') {
+            if (is_a($elem, 'XmlElement') && $elem->getTag() == 'p') {
                 assert($elem->getAttr('class') == 'tightenable top bottom');
                 $this->setContent($elem->getContent());
             }



On Wed, 2003-02-26 at 03:25, Todd Mokros wrote:
> With current cvs, if you have a plugin as part of a list, TightSubBlock
> errors out with: "PHP Fatal error:  Call to undefined function: 
> gettag() in lib/BlockParser.php on line 421"
> 
> The problem is that $elem in that line of code is an instance of
> Cached_PluginInvocation, which does not inherit from XmlElement.  I'm
> not sure if plugins shouldn't be allowed in lists and this error caught,
> or other changes are needed to allow this.

-- 
Todd Mokros <tm...@ne...>

Re: [Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Jeff D. <da...@da...>]

On 26 Feb 2003 03:59:54 -0500
Todd Mokros <tm...@ne...> wrote:

> As a quick fix, the following patch seems to work for me.

Thanks for the report and the patch, Todd.  I've just checked
it into CVS.

Jeff

PS:
> The only problem would be that the is_a() function requires php >=
> 4.2.0.

(Note that we have our own, more portable, isa() function in
lib/stdlib.php.)

Re: [Phpwiki-talk] Bug with TightSubBlock and plugins in lists

[Aredridel <are...@nb...>]

On Wed, Feb 26, 2003 at 03:59:54AM -0500, Todd Mokros wrote:
> As a quick fix, the following patch seems to work for me.
> The only problem would be that the is_a() function requires php >=
> 4.2.0.  The method_exists function should work with all PHP4 versions,
> but is an uglier way to check.  The patch might get wrapped by my
> mailer, but should be easy patch by hand.

May I suggest a "versioncompat.php" that, for example, moves
HTTP_POST_VARS to _POST, HTTP_GET_VARS to _GET, if is_a is not defined,
defines one (it's trivial to make a function that does the same), and
various other things like that.  

If functions need _GET, one should global it, as it's not autoglobal in
< 4.3, but there's no reason not to use the new names. 

Makes life much easier, and you can write with the current idiom,
instead of making new versions backward compatible, you can just write
to a nice common denominator.

Ari

[Phpwiki-talk] compat.php (was Bug with TightSubBlock and plugins in lists)

[Jeff D. <da...@da...>]

On Wed, 26 Feb 2003 12:35:59 -0700
Aredridel <are...@nb...> wrote:

> May I suggest a "versioncompat.php" that, for example, moves
> HTTP_POST_VARS to _POST, HTTP_GET_VARS to _GET, if is_a is not defined,
> defines one (it's trivial to make a function that does the same), and
> various other things like that.  

 
> If functions need _GET, one should global it, as it's not autoglobal in
> < 4.3, but there's no reason not to use the new names. 


The reason we haven't moved to _GET in PhpWiki is just exactly
the autoglobal semantics.  Since you'd have to 

  global $_GET;

anyway, might was well do

  $_GET = &$GLOBALS['HTTP_GET_VARS'];

(or just use HTTP_GET_VARS.)  It makes it explicit that we're not
using a real (autoglobal) $_GET.

As far as implementing replacement functions, a compat.php
is a fine idea.  (We already do define functions like this,
when they're needed, but their definitions are scattered
all over the place.  Grep for 'function_exists'.)

It's probably a good idea to normalize some of the names,
too.  E.g. we have isa() instead of is_a() for historical
reasons (we invented it before PHP did, I think).