Thread

We upgraded from EE 1x to EE v2.1.3 build 20101220 for one of our client sites last week.

Everything seemed fine when I was working with the new site as a Super Admin. However, non Super Admins are seeing some errors when editing an entry.

The errors the non Super Admins see are:

A PHP Error was encountered
Severity: Notice
Message: Undefined variable: assigned_channels
Filename: cp/content_publish.php
Line Number: 2122

A PHP Error was encountered
Severity: Warning
Message: in_array() [function.in-array]: Wrong datatype for second argument
Filename: cp/content_publish.php
Line Number: 2122

A PHP Error was encountered
Severity: Warning
Message: Cannot modify header information - headers already sent by (output started at /mnt/Target01/330832/n2n.qdsprojects.com/web/content/adm/codeigniter/system/core/Exceptions.php:170)
Filename: core/Common.php
Line Number: 409

I’m not sure where to begin trying to figure out what these issues are from. Any guidance? Let me know if I can provide more info that would be helpful. Thank you in advance.

Actually, I have some additional info:

When a non Super Admin attempts to edit an entry, they are able to, but the returned page they see has these errors —and only these errors, nothing else shows on the page.

A PHP Error was encountered
Severity: Notice
Message: Undefined variable: assigned_channels
Filename: cp/content_publish.php
Line Number: 2122

A PHP Error was encountered
Severity: Warning
Message: in_array() [function.in-array]: Wrong datatype for second argument
Filename: cp/content_publish.php
Line Number: 2122

A PHP Error was encountered
Severity: Warning
Message: Cannot modify header information - headers already sent by (output started at /mnt/Target01/330832/n2n.qdsprojects.com/web/content/adm/codeigniter/system/core/Exceptions.php:170)
Filename: libraries/Functions.php
Line Number: 749

A PHP Error was encountered
Severity: Warning
Message: Cannot modify header information - headers already sent by (output started at /mnt/Target01/330832/n2n.qdsprojects.com/web/content/adm/codeigniter/system/core/Exceptions.php:170)
Filename: libraries/Functions.php
Line Number: 387

Note: the content updates they enter ARE saved.

Okay, one more update, please excuse the multi-posts:

I updated the error display settings so only Super Admins see them (output/debugging preference = 1). So, non Super Admins that were seeing the errors previously now are NOT seeing any anywhere. (They were seeing them on both editing an entry, and after saving an entry.)

HOWEVER, no PHP errors are showing for Super Admins now. Should I be worried since previously PHP errors were shown to non Super Admins? No code has changed, so it seems as if the errors could still exist?

Thanks for your time.

Susan, I want to be brief, because really Support needs to work with you on this.

You’re correct: the output debugging preference you set only hides the errors from non-admins - pretty assuredly the errors are still there. I’m surprised in fact that the user edits appear to be successful.

From the details, there’s only one real error, and that looks like it may be caused by a bad file upload during your FTP of the new system. It’s not uncommon to have that happen.

I’d first make sure you have a fresh full backup of all your system files, and of your database as they are at present. Be sure you keep those separate from backups of your earlier 1.x site and its earlier database.

This will prepare you for what Support will likely prescribe, which is pretty easy:  fresh folder and files to be switched in to replace the present system, along with copying in two of your present files for configuration.

Regards,
Clive

Thanks Clive. I appreciate your reply and the info.

We do have backups from both 1x and the initial 2x install. I’ll make another of our current files + DB.

Susan, here’s a safe procedure, so that you can possibly get things clear for your client today.

- on your preparation machine, take a fresh copy of the system folder, from the EE release version zip you’re working from.

- rename this system folder with your own systemname.new

- go to your backup of the present site, in systemname/expressionengine/config, and copy config.php and database.php, pasting them over the empty files in your new systemname.new/expressionengine/config. This configures this fresh system.

- if you are using any EE add-ons, similarly copy and paste any folders in the current systemname/expressionengine/thirdparty to systemname.new/expressionengine/thirdparty.

- unlikely with EE 2.x, but you can check to see if you need similarly to copy over any items from current systemname/expressionengine/language/en or systemname/expressionengine/templates.

- Check your FTP program to make sure it will transfer files automatically for type—not as ASCII or BINARY only.

- using FTP, upload systemname.new to the root of your site where your present systemname already is.

- now, on the site, and probably using the ftp program to do it, rename first systemname to systemname.old. Then also on the site, rename systemname.new to system.

- at this point, you’ve got a refreshed set of all system files, along with your config and add-ons. You can try the front-end site, and log in to the CP to see that everything looks normal.

- Now set your debug level back to 2 so that errors would show for ordinary members. Log out as administrator, and log in as one of the users, to test what was failing with PHP errors before.

Hopefully, this will get the job done. I don’t think themes are involved, though they often are on bad FTP transfers when the problem is in the Control Panel. If they were, a similar procedure to build and safe-upload-swap a fresh root/templates directory, carefully including any third_party, or third-party-owned template folders, would be the way.

Susan, if you run into any unexpected trouble, all you have to do to recover is rename the fresh uploaded systemname folder back to systemname.new; and then rename the systemname.old back to systemname. That will return you to the installation as you presently have it, untouched.

Let us know how this goes, if you want to do it, and by that time maybe Ellis will have someone here from Support.

Regards,
Clive

Thanks again Clive. I’ll try this out and post back with news—hopefully good news.

Sounds good. Please let us know how it goes.

Well, I replaced the system folder and theme folder.

All was smooth, but the errors are exactly the same (as reported in earlier posts).

I spent a little time this evening checking and saving various channels, fields etc.
+ All channels have status groups assigned to them.
+ The non Super Admin group has access to all Channels
+ I re-saved all Channels
+ We have no custom add-ons being used, so there is no conflict there—HOWEVER, I wonder if remnants from previous older add-ons could be saved in DB and causing trouble?

I’m not sure if there is anything else I can come up with to check/review.
In the meantime, please let me know if there is anything you can think of for me to check.

Thanks ~

I have found something sort of interesting.

See attached screenshot:
* I am logged in as a non Super Admin
* The PHP errors for adding/editing entries are seen at top
* Note the channel drop down is blank—which shouldn’t be

Any ideas why the channel drop down would be blank? Seems like that might be a problem. And ideas on how to fix?

It looks like this thread addresses the issue I’m seeing: http://ellislab.com/forums/viewthread/177335/

Can you confirm? If so, you can mark this as resolved.

Hi Susan—very good work to track that down. Last Friday I had just looked at the nature of your error, and presumed EE itself wasn’t at fault since apparently others hadn’t reported it. But they had.

Looking over the comments in the bug report, I think you can take it as pretty high confidence that this is the fault you’ve had also.

It’s marked as fixed in the present 2.1.4 beta, and I looked at the source to see how they’ve done it. A little more robustly but with the same technique as the fix reported, is the answer.

Then I think you’ve got three alternatives, given the way you sound careful on customers’ behalf:

- add the line make the fix in the bug report here: Actual Fix Line. Notice I’ve pointed to where Dom S./Vaya has corrected the original suggestion, agreed by EE and said to work, as it should.

- upgrade to the 2.1.4 beta. This would get you the fix along with others. The beta seems good and seems stable, but it is a beta in terms of responsibility, and I imagine it will be another month before 2.1.4 becomes a release. It introduces change for the better in the File Manager for uploading content as well as its bug fixes.

- live with what you have by turning off the error, if this indeed gives your users error-free and trouble-free content editing for the present. Now you know that they don’t have a channel selection in some instances either.

Thus it’s a call according to your judgement. I myself might be tempted to add the fix line, given what may sound like a conservative environment.

Susan, I looked at the 2.1.4beta source to see what they did. They used the same fix line, but put it in a more sensible place:  in what’s called the constructor, at the top of the file. This means the fix is available to any abilities that might need it in content publishing, and so it might be necessary to have it there to repair the additional problem you discovered with the drop-down menu.

If you want to do it this way, then the code change would be as here: you can see the fix line, setting value to this->_assigned_channels, added to the bottom of whatever is in the __construct () function, which will be near the top of the system/expressionengine/controllers/cp/content_publish.php file:

public function __construct()
    {
        parent::__construct();

        if ( ! $this->cp->allowed_group('can_access_content'))
        {
            show_error(lang('unauthorized_access'));
        }
        
        $this->load->library('api');
        $this->load->library('spellcheck');
        $this->load->model('channel_model');
        $this->load->helper(array('typography', 'spellcheck'));
        $this->cp->get_installed_modules();
        
        $this->_assigned_channels = $this->functions->fetch_assigned_channels();
    }

Hope this gives you what you need, and again, compliments on the job from your end.

Regards,
Clive

Thanks Clive.

Yes indeed, this is a known issue with 2.1.3 that is resolved in 2.1.4. I’ll go ahead and close this one out but don’t hesitate to post again!