Symphony.

Just updated a 2.0.6 install to 2.1.0 and found out 2.1.0 has a build in localisation manager, great. However my install has no language packs, and yet I am able to select all the different languages… when I do so i get this fatal error:

Fatal error: Call to a member function listAll() on a non-object in /opt/local/apache2/htdocs/cav5/symphony/lib/toolkit/class.lang.php on line 149

and am completely locked out

The error doesn’t occur on a new install, but it do has all the languages in the combobox, see attachment. Where does it get this list of languages from?…

Attachments:

Picture 1.png

I’m not sure about the error you are getting but there is no hardcoded list of languages. You’re seeing all languages that are available in the system (e. g. via core extensions). See here. So your screenshot shows the correct list of available languages.

yeah thanks, on line 149 it does;

foreach($ExtensionManager->listAll() as $extension => $about) {

so maybe its an extension with some missing about info? In previous version this wouldnt have been an error?

I’m guessing around here Symphony should first make sure $this->ExtensionManager exists.

It seems like the Extension Manager object is not initialised correctly. Does the rest of your site work correctly?

Brendan, but the question is: why shouldn’t the Extension Manager be available in this context?

Indeed Nils. Yes the site worked before, I cant double check now ofcourse… But I did make some changes after it worked and before it stopped working; I updated the core extensions to their latest version form the versions that were included in 2.0.6

Isnt there something I can do to bypass the fatal error reporting, so I can get into my broken site to investigate?

@newnomad Try copying these 3 lines to just above that line you quoted (L149) and see if that resolves the issue.

@Nils, I’m not sure to be honest, I was under the impression that everything operates in the Frontend or Administration instance, both of which call their parent::_construct which would appear to call that initialiseExtensionManager. If that fails an Exception is meant to be thrown, so again, no idea how it can’t be initialised.

@brendo
Thansk for the constructive advice, the result is however;

  Fatal error: Using $this when not in object context in /opt/local/apache2/htdocs/cav5/symphony/lib/toolkit/class.lang.php on line 149

I also got this error and have been locked out.

As a test, I installed a new version of Symphony 2.1.0 and immediately changed my language preference to German and again got the error:

Fatal error: Call to a member function listAll() on a non-object in C:xamppxampphtdocsnwfscsymphonylibtoolkitclass.lang.php on line 149

Switching to French also produced the error, but switching to English produced no error.

What exactly to you mean by saying “locked out”?

• Have you made sure that all files are uploaded properly?
• Are you using the Git repository or the download available on this site?

both front and backend give this error, so we cant log in to change anything.

aha… I individually updated the core extensions from their github pages on the faulty install, wether on the workign new install i cannot recreate the error, as jefepeters did. Perhaps he got his full install from git, and as sometimes git played up on safari and there are missing files?…. (the hardcore zip action always keeps turning after the download is ready)

I just checked my own test install and I cannot reproduce your issue there.

Could you please try and replace the /symphony/ folder and the core extensions with the files available for download on this site: http://getsymphony.com/download/releases/current

Maybe that fixes the issue.

Ah and by the way, do you have any special extensions installed?

I have been using the download available on the site. I just tried the Git repository version and only English is available as a language option, therefore I can’t recreate the error.

And yes, “locked out” means the front and backend are no longer accessible.

No special extensions, nothing beyond what is included in the zip package on the website.

No special extensions, nothing beyond what is included in the zip package on the website.

In symphony/lib/core/class.symphony.php, replace the reloadLangFromAuthorPreference() method (line 279) with this:

    public function reloadLangFromAuthorPreference(){   

        $lang = $this->Author->get('language');
        if($lang && $lang != self::lang()){
            self::$_lang = $lang;
            if($lang != 'en') {
                if(!$this->initialiseExtensionManager()){
                    throw new SymphonyErrorPage('Error creating Symphony extension manager.');
                }
                Lang::loadAll($this->ExtensionManager);
            }
            else {
                // As there is no English dictionary the default dictionary needs to be cleared
                Lang::clear();
            }
        }

    }

If that solves it, I’ll commit the fix.

That solves it. Thanks, czheng.

Oops, I spoke too soon. This fixes the function listAll() error, but now Symphony prompts me to login each time I navigate to a new admin page. I also cannot change the lang preference back from German to the system default.

Strange. I can’t reproduce either of those behaviors. Anything in the logs?

Nothing in the logs. I tried another install and the behavior is the same.

@newnomad Apologies, I should of been clearer in my instructions, I meant as czheng as shown. Does that solve your issue if you copy czheng’s code?

@jefepeters You could try opening up the sym_authors table in MySQL and clearing the language field to be NULL again.

I had this same problem. I’m new to symphony and started out by downloading the 2.1.0 release (the zip) and following the installation guide. I did:

• unzip and set correct permissions
• run the install script
• log in to the new install
• go to user preferences and change the language to “Nederlands”

After submitting the form, I got the same error mentioned earlier here. I thought the dutch translation was just missing, so I downloaded it and copied it to lib/lang/ but I was still “locked out”. Finally, I changed the database record to reference “en” instead of “nl” and everything was fine again.

It seems from the replies in this issue that not everybody can reproduce it. However, doing a clean install like I did is a solid way to reproduce it for me (worked for 3 clean installs)

Does the mentioned fix work for you?

Yes it does! Great! :)

I think I’ve figured out what is causing this issue and how the Extension Manager might not be initialized.

The Symphony __construct function executes the isLoggedIn (line 74) function before the Extension Manager is initialized on line 82. If $this->Author is not around, it’ll attempt to log one in from the cookie, which on success will call the reloadLangFromAuthorPreference function.

If this occurs, the EM is never started, hence the error.

Do you have a fix in mind, Brendan?

Other then our quick hack, not really.

At first glance, it’d appear that’d you just swap [78-80][1] with [74-76][2] but I don’t think it’s as easy as that.

The problem then would be if the EM fails to start for whatever reason, the SymphonyErrorPage exception would be thrown and it would display the verbose errors (something that was fixed as part of #360) instead of hiding them for non logged in users.

Having said that I can’t see any reason why initialiseExtensionManager would ever return false anyway. Perhaps Alistair could explain the caution used here?

So it looks as though this commit is to blame.

Having said that I can’t see any reason why initialiseExtensionManager would ever return false anyway. Perhaps Alistair could explain the caution used here?

As far as I can tell, no, it wont. However, I think the idea was for future proofing, it should return something. That way, if at some point we decide the initialiseExtensionManager should be doing more than just returning an instance of ExtensionManager, the return value will be meaningful.

I think the ExtensionManager failing to load is a very critical problem and would be more likely to appear at first install rather than randomly down the line for users. It’s almost like ensuring we hide an error thrown by not being able to instantiate the Symphony/Administration/Frontend class.

Really swapping those bits of code around, i.e. having the call to initialiseExtensionManager() before isLoggedIn(), seems like a reasonable solution.