Wordpress and CMS Builder Issue

7 posts by 4 authors in: Forums > CMS Builder
Last Post: March 19, 2013   (RSS)

By pault - March 15, 2013

I've often had problems with running Wordpress and CMS Builder together, with error messages being displayed regarding a function is_a()

The error is along the lines of is_a(): Deprecated. Please use the instanceof operator

I looked at the following post which suggests a solution to the problem but for me this didn't work, adding the error_reporting directive as suggested had no effect.

http://www.interactivetools.com/forum/forum-posts.php?postNum=2213858#post2213858

I've now found a solution which I thought I would share which is by adding the following line to each page that the CMS Builder functions are called, but after the loading of the CMS Builder libraries, so immediately below the foreach ($dirsToCheck as $dir) { if (@include_once("$dir$libraryPath")) { break; }} line:

error_reporting(0);

The problem seems restricted to PHP versions between 5.0 and 5.3 when the is_a() function was removed (but has since been put back in)

By pault - March 18, 2013

Hi Ross,

It's not actually CMS Builder that uses is_a(), it's Wordpress but the problem is that when CMS Builder is installed along side Wordpress then the explicit turning on of error_reporting on line 4 of cmsAdmin/lib/init.php makes a load of errors appear.

I initally fixed it by editting init.php but obviously this would then get overwritten if upgraded and would affect all pages which is why I put the error_reporting(0) only on the pages that had both Wordpress and CMS Builder.

Don't worry spending any time over it, it's just I've had this issue before and never worked out how to get around it so just wanted to post an idea in case it helped anyone, even though I know it's not perfect.

Thanks, Paul.

By Codee - March 18, 2013

Hi Paul,

Is your WP updated, especially the backup function? I thought that particular deprecation warning stopped after WP backup 2.2.2, but I'm not positive. If you updated that function, the warning message might not occur.  Keeping up with WP updating (there are so many) can be time-consuming, especially for security issues because there are a LOT of security holes in WP making them targets of hackers.

I have a tangent question....because I am very curious. Are you using WP in conjunction with CMSB because of the availability of nice looking templates? Obviously WP has a lot of templates out there, and essentially their own CMS...but I recognize it's not as powerful and not as flexible as working with CMSB. Other than wanting some immediate nice-looking templates I do not see why there would be a strong enough reason to combine the 2 (and possibly increase the work load). I hope you don't mind me asking.

By pault - March 18, 2013

Thanks for the reply.

Yes, it's a new installation of Wordpress 3.5.1.    I've just searched for uses of is_a() in the Wordpress files and it's in a lot of places so maybe the re-introduced it?

Paul.

By Codee - March 18, 2013

Okay, in a wordpress forum this error has come up quite a bit, and it was deprecated in ver 5.0, and we're supposed to use 'instanceof', however there are valid use cases for it that instanceof didn't cover (such as the input being a string), so it was reintroduced with 5.3.  An exampleis_a($foo, 'Item')this is a dynamically bound symbol, and is different from is_a($foo, Item)which is static bound.

By Dave - March 19, 2013

Hi Paul,

We turn the error reporting up high for CMSB so we catch error early and not just when we upload to a server that has them turned on (that's happen before... no fun when you want to launch a site).  But those deprecated warnings from Wordpress can probably be safely ignored.  

Try turning off error reporting in these places:

/cmsAdmin/.htaccess - Add a # in front of these lines:

# Debug: Enable error checking
php_flag display_errors On
php_flag display_startup_errors On
php_flag log_errors On
php_value error_log "_php_error.log"

Then if that does work, try: /cmsAdmin/lib/init.php - Add a # in front of these lines:

  error_reporting(E_ALL | E_STRICT);
  ini_set('display_errors', '1');         //
  ini_set('display_startup_errors', '1'); //
  ini_set('track_errors', '1');           // store last error in $php_errormsg
  ini_set('html_errors', '0');            // don't output html links in error messages
  ini_set('mysql.trace_mode', '0');       // when this is enabled SQL_CALC_FOUND_ROWS and FOUND_ROWS doesn't work: http://bugs.php.net/bug.php?id=33021

Let me know if either of those turns off error reporting for you.

We can probably add a flag to the next release to turn it off.  There's a number of reasons why that would be helpful sometimes.

Hope that helps!

Dave Edis - Senior Developer
interactivetools.com