Thread

I realise it’s only a notice and it’ll go away when we’ve finished development but I’m seeing

A PHP Error was encountered

Severity: Notice

Message: Object of class CI_DB_mysql_result could not be converted to int

Filename: file/mod.file.php

Line Number: 90

on a template where I’m using

{exp:file:entries directory_id="3" disable="categories|pagination" dynamic="off"}
    {file_url}
{/exp:file:entries}

- that’s within a channel:entries tag.

The output seems to be fine, but the error is annoying.

There are six images in the directory. Some were uploaded via FTP & synchronised. We’re on v2.2.2.

Anyone got any thoughts on this?

Thanks,
Rich

Hi Rich,

Can you change the value of your dynamic= parameter to ‘no’ please and move the File Entries tag outside your Chanel Entries tag. Does the error persist?

What happens if you put that code into a blank template with nothing else?

Is this a fresh install or an upgrade from a previous version or build?

I’d already put the file:entries tag in a new (& otherwise blank) template from the one containing the channel:entries tag. No change from that or the dynamic=“no”.

Installation was a patch up from v2.1.

Should have mentioned - I am using a whole world of add-ons: Structure, Wygwam, Playa and Matrix.

Semlyen IT,

Now that you mention all the add-ons in play here, have you verified that you are using the most up-to-date versions of all those add-ons? I know that Matrix needs an update from the version that would have worked under 2.1 vs. 2.2.2

Cheers,

All the add-ons were installed after the upgrade to 2.2.2. All are the latest versions.

At the risk of spawning a tangent: can I disable them all without losing any settings in them? If I won’t have to set up all the listings and templates etc. in Structure again, or the editor configurations in Wygwam, I’ll just turn ‘em off and see if I still get this warning.

Hi Semlyen IT,

You can globally disable extensions, which will merely turn extensions off while preserving data. With modules, however, you cannot. In your situation, I would recommend making sure you have a solid backup of your files and database. Once you’re confident in that, go about uninstalling your modules in a process to narrow down the troublemaker. After you’ve found it, you can restore the backup of your database and then work specifically with the module that you know caused you issues. (This process preserves the data from your modules.)

Does that make sense?

Disabling extensions didn’t help. I’m afraid I couldn’t be bothered to backup and restore over a notice; much more fun to hack around in the EE code.

Line 90 of mod.file.php is:

if ($this->sql == '')

D’y know, if I replace it with

if (empty($this->sql))

I don’t get the notice.

I know it’s got its knockers but I’ve always like empty().

I var_dumped $this->sql, and it is indeed an empty CI_DB_mysql_result. Line 449 of mod.file.php creates it as such with

$this->sql = $this->EE->db->get();

... so it’s a bit of a mystery as to why it should be compared to an empty string.

Look forward to your comments on this!

Rich

LOL- glad you went poking.  This was indeed a bug- I reported as such and implemented your fix.  As to why the empty string comparison- search through for $this->sql and in some instances it is set to an empty string.  But the empty check takes care of it either way.  (Sometimes the method can bail out w/out ever running the main query- hence lack of object.)

Thanks both for the report and your excellent debug!