Recent Topics
  1. b2evolution CMS Support Forums
  2. Archives
  3. Older bugs
  4. Bugs in 2.4.x
  5. [2.4.2] Anonymous users + protected posts = PHP notices

[2.4.2] Anonymous users + protected posts = PHP notices

1 Jun 28, 2008 22:58    

When trying to access a protected post as a guest PHP shows notices like
this one:
[url=http://image.gd/image,show,1,e700e8fea8e37a20fdf1cd297c9a31c3aa4ffc63,2]http://s1.image.gd/t/e7/e700e8fea8e37a20fdf1cd297c9a31c3aa4ffc63.jpg[/url]

Background:
The error occurs when the template function item_prevnext_links() is called
on a post with protected status. The function then calls ItemList2::prevnext_item_links(),
which calls ItemList2::prev_item_link() and ItemList2::next_item_link().
Both these methods call ItemList2::get_prevnext_Item().
In this method a check is performed if the return value of DataObjectList2::get_by_idx()
is NULL. Thus everything works as expected, except of the PHP notices. So
where they come from? DataObjectList2::get_by_idx() invokes DataObjectCache::instantiate()
with a object from DataObjectList2::$rows (in this case it's the object
stored at index 0). But if the post is protected, there isn't an object,
there's only NULL. ;) DataObjectCache::instantiate() tries to access NULL
as an object and that's the source of the notices. My fix in DataObjectList2::get_by_idx()
is to check if the requested row doesn't exist or is NULL and return NULL
if that's true. A similiar change could be also done in DataObjectCache::instantiate(),
but I think the better place is the former function.

Yeah. Tricky. OK, here's the patch:


--- a/inc/_core/model/dataobjects/_dataobjectlist2.class.php    2008-04-27 22:09:26.000000000 +0200
+++ blogs/inc/_core/model/dataobjects/_dataobjectlist2.class.php        2008-06-28 22:53:07.000000000 +0200
@@ -177,6 +177,12 @@
         */
        function & get_by_idx( $idx )
        {
+               if( !isset( $this->rows[$idx] ) || is_null( $this->rows[$idx] ) )
+               {
+                       $obj = NULL;
+                       return $obj;
+               }
+
                return $this->Cache->instantiate( $this->rows[$idx] );
        }

@@ -337,4 +343,4 @@
 }


-?>
\ Kein Zeilenumbruch am Dateiende.
+?>

Tblue

Back to top

2 Jul 04, 2008 09:00

Is this true in 2.4.2 or <= 2.4.1? I know it used to be true because I reported it, but I don't know off the top of my head if I reported it against 2.4.2 or not?

Also if this is 2.4.2 could you PLEASE post a "before" and "after" code version instead of a diff file type of thing? Diff files suck cuz (as far as I know) there is nothing out there that will effectively and actually turn it into a useful patch. Before and After works because all we have to do is copy/paste :)

Back to top

3 Jul 04, 2008 14:59

I don't know if it's true in <= 2.4.1, but I'll look at it.
Edit: True at least in 2.4.1 and 2.4.0-rc2.

OK, I'll try to make a "before"/"after" version, but first let me look at 2.4.1 and earlier. ;)

Edit #2:
File: inc/_core/model/dataobjects/_dataobjectlist2.class.php
Search for:


	function & get_by_idx( $idx )
	{
		return $this->Cache->instantiate( $this->rows[$idx] );
	}


Replace with:


	function & get_by_idx( $idx )
	{
		if( !isset( $this->rows[$idx] ) || is_null( $this->rows[$idx] ) )
		{
			$obj = NULL;
			return $obj;
		}

		return $this->Cache->instantiate( $this->rows[$idx] );
	}

OK, not really "before"/"after" but "search and replace"...

BTW, there's another possibility to fix this bug.
File: inc/_core/model/dataobjects/_dataobjectcache.class.php
Search:


	function & instantiate( & $db_row )
	{
		// Get ID of the object we'ere preparing to instantiate...
		$obj_ID = $db_row->{$this->dbIDname};


Replace with:


	function & instantiate( & $db_row )
	{
		if ($db_row === NULL)
		{
			$Obj = NULL;
			return $Obj;
		}
	// Get ID of the object we'ere preparing to instantiate...
	$obj_ID = $db_row->{$this->dbIDname};

The first patch fixes this specific bug, the second one prohibits the instantiation of a NULL "object" in the cache in general. Which solution is the better one? Both work without problems.

Back to top

4 Jul 05, 2008 00:02

Cool - thanks!

I dunno which is "better" because I pretty much don't know much about nothin' at all. It'll be up to the dev team to decide which is better I guess, but for my money I'll go with the second version because it seems more 'global'.

My question on the versions is because, to my way of thinking, anything good should be done for 242 due to it is the "officially stable" release. All others in the 2.* generation are some sort of non-stable alpha beta type of thing ... and some might even be obsoleted already.

I'll mark this as a favorite because it comes back from time to time and now solutions are available. Hooray for solutions!

Back to top


Form is loading...