FuelPHP Forums

floorish

Ok this is ridiculous, I don't know what the hell is going on, this is by far the weirdest bug I've seen in my life. I'm not sure it is the Framework or PHP being funny. Here's a little story:

I started with this question on StackOverflow, because something happened that should not happen: http://stackoverflow.com/questions/18580668/php-says-object-is-non-object

Basically, in the logs there are "Trying to get a property of a non-object" errors, while the variable is definitely an object. (Xdebugged and all, they are objects)

Now I commented out some more stuff in the app to determine what this could be. I noticed the errors were gone if I manually set the $id to something like "19" in the Orm query. Ok weird.

The other odd thing that happened, was that the errors disappeared if I changed the view loaded in the method. So I thought: maybe it's something in the view?

Did some debugging and after removing a \Form::textarea('title', 'content', array('class' => 'someclass')); the errors were gone.

So , maybe there was something funky in the textarea code that triggered errors in some objects in the controller? It gets better: removing just the attributes from the textarea method was enough; no errors.

Then I managed to pin it down to the html_tag() method in base.php and if I change the output there: no errors. Weird.

Now I checked when these errors first occured; February 22nd this year (yeah I know, should have fixed it earlier, but you know, time...). That's when I updated the Log package in Fuel. Coincidence?I don't know anymore. I'm not sure how much time I should spend finding out where the errors come from. It works, only the logs get polluted with a stupid error but that's it.

If anyone got the slightest clue what is going on I appreciate any feedback.

Some code for reference:

/* CONTROLLER */
public function action_edit($id = null) { 
 $fake_id = "18"; 
 var_dump($fake_id === $id); // true 

 $foo = Model_Artist::find($id); 
 $foo->id; // error 

 $bar = Model_Artist::find($fake_id); 
 $bar->id; // no error

 /* snip */

 $view = View::forge('admin/artist/edit');
 $this->template->content = $view;
}


/* VIEW */

// remove the array here: no errors above

<?php echo Form::textarea('description', Input::post('description', isset($artist) ? $artist->description : ''), array('class' => 'span10 editor', 'rows' => 8)); ?>

Harro

This is very weird, because the ORM caches all objects.

So if you do a var_dump($foo, $bar), you'll see two identical objects (note the object reference number).

Your stackoverflow post suggests that altough you get the error when you echo $b->id, you get the result to. Is that the case? If so, is the error actually triggered by $b->id, or by something else.

ORM models don't have accessable properties, so $b->id will trigger an __get() magic method call, and in there all sorts of things may happen. It might be an issue in your Model that has caused a required internal property to be missing for example...

Harro

BTW, Fuel 1.6 doesn't have a Log package, so if you're on 1.6, and you have an active Log package, you're in for problems anyway.

Delete the package, and remove any reference from it always_load. 1.6 uses Composer to install the Monolog library, which is used by \Fuel\Core\Log directly.

floorish

Thanks for the quick suggestions!

Yes, both are the same objects: object(Model_Artist)[38] ... object(Model_Artist)[38]

--

Yes, I get the result too, everything just works. I guess it is triggered by something else, since they are objects. But the log says otherwise:

ERROR - 2013-09-03 10:44:22 --> 8 - Trying to get property of non-object in /var/www/fuel/app/classes/controller/admin/artist.php on line 110

This shows only once. (Of course if I duplicate that line, it shows twice ;) but the other line with $fake_id has no errors)

--

Yeah, I know kind of how the models work, have been playing around with them a lot. I replaced it with another, same results! Just a basic class Model_Artist extends \Orm\Model

--

Yep, 1.6 is all set without the Log package. No traces left behind as far as I can tell. I just noticed it as an odd coincidence that I got the first errors in the logs at that time. (My previous forum question was even on that day hah!)

--

It seems to me like the kind of errors you get in C++ without proper memory management: change something in one class; three classes down a random variable is broken. No relation.

Harro

I'm clueless...

floorish

No worries, me too ;)

Thanks anyway for giving it a thought!

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion