[SOLVED] Upgrading Group Jive 2.3 to 2.4rc - Fatal Errors

XAMPP is a prepackaged server implementation, which I find best emulates a live server (excluding error reporting, as it starts with STRICT mode enabled). XAMPP is also cross-platform, please see the below.

www.apachefriends.org/en/xampp.html

Linux is clearly supported.

At any rate hopefully you work out your localserver issues. Appreciate the confirmation that it is localserver related.

Thank you for your reply but - supported is not the same as the same. So we have done the following...

1) ensured that our dev and test servers are running the latest version of xampp-linux they are v1.7.4 which includes php 5.3.5

2) we then checked that our servers were fully in accordance with joomla's techical requirements which are here...

www.joomla.org/technical-requirements.html

and they are.

3) we then checked joomla php.ini requirements here...

docs.joomla.org/Security_Checklist_4_-_Joomla_Setup

our internal servers fully comply with this in particular register_globals is set to off (interestingly register_globals is set to On in the production servers - more of that in a minute)

4) turned register_globals on on the dev server and ran phpdebug this returns the following message...

"Deprecated: Directive "register_globals" is deprecated in php 5.3 and greater"

5) Ran the vanilla j1.7 on our servers on lo no fatal errors

6) So the fatal errors occur when we follow joomla's own technical guidance

7) With strict standards mode it is clear that SOME variables are not being loaded from the relevant components base classes (we will do further analysis tomorrow and advise)

The issue is NOT with our internal servers as we can now turn the fatal errors on and off at will by using the register_globals setting.

9) We have NEVER had any issues with our internal servers until testing joomla components that are 1.5/1.6/1.7 native

Questions...

1) Is your xampp the latest version - 1.7.4 with php 5.3+?
2) Do you have register_globals set to ON in your php.ini if so try turning it OFF as per Joomla's technical guidance we suspect you will enter into a whole new world of fun!

Please understand we are not having a go at CB or you, we have already identified the same issue with another J1.7 compatible component provider. We are just using our resources as an contribution to open source as we suspect this issue is going to bite a lot of people in the future. We would wholly support the general recommendation that do not go near j1.7 yet unless you have no choice

1) Is your xampp the latest version - 1.7.4 with php 5.3+?

Yes.

2) Do you have register_globals set to ON in your php.ini if so try turning it OFF as per Joomla's technical guidance we suspect you will enter into a whole new world of fun!

Its always been off.

Firstly thank you for the time you have spent on this issue and your last response which we really appreciate..

We have rebuilt the test server to run windows and installed xampp-windows, installed the vanilla j1.7 environment and lo it works.

This result does not really surprise us as we have experienced a very similar issue 2 years ago with joomla on the different flavours of xampp.

The key outcomes are that there absolutely no issues with group jive on a pure Apache production environment, the only variables left are the different flavours of xampp which given the fundamentally different nature of the operating environments is unsurprising.

As far as we are concerned this topic is closed as we can create and control the issue at will. We hope that this will help others as they either migrate or update their versions of xampp and Joomla.

Once again we should like thank krileon for helping to track this down and CB for their excellent product.

I pulled up this post doing a search of the forums on 'cbgjDBTable'. I was having a similar issue with fatal errors from cbGJ when activating photos, videos, wall and other cbGJ plugins.

My error report was saying the class cbgjPhoto did not exist, then I noticed line 785 in cbgroupjivephoto.php.

Sure enough this class did not exist for me either. After reading through this thread I tested on my live environment and did not have the issue there. I am using MAMP and suspected it was the culprit at this point. After fiddling around with MAMP I realized after I restarted the server the issue was gone for the first page load, then would occur on the second page load so I knew some type of caching was happening on my local MAMP.

In MAMP under Preferences->PHP in the PHP Extensions box, cache was set to XCache. I changed the selection to '--', restarted the server, and the issue is now gone.