Wordpress and CMS Builder Issue

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

By ross - March 18, 2013

Hi pault

Thanks for the post! I did a quick search through our files and I don't see any calls to is_a() in the latest version of our software so it might have been something we used to use. I am not 100% certain though. using the error_checking(0) idea should supress the error but that can lead to problems with testing and things like that as it hides all error messages.  

Did you want to set up a test page that shows me the error and then send through a support request so I can do some further testing? 

https://www.interactivetools.com/support/email_support_form.php

Let me know :). Thanks!

-----------------------------------------------------------
Cheers,
Ross Fairbairn - Consulting
consulting@interactivetools.com

Hire me! Save time by getting our experts to help with your project.
Template changes, advanced features, full integration, whatever you
need. Whether you need one hour or fifty, get it done fast with
Priority Consulting: http://www.interactivetools.com/consulting/

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