Thread

Running EE 2.2.2, the following functionality on the edit content list screen is causing problems on the live environment (a dedicated LAMP server):

<input type=“checkbox” name=“toggle[]” value=“0” class=“toggle” id=“delete_box_0”/>
1. In the edit content list screen, the checkbox field IDs are numbered incorrectly, always starting from 0 and incrementing, instead of being set to the entry IDs e.g.

<input type="checkbox" name="toggle[]" value="0" class="toggle" id="delete_box_0"/>

This means that when you tick checkboxes to edit or delete certain entries and click submit, the *wrong* entries are selected (it’s always the earliest entry IDs selected).

This means that the delete entries functionality is extremely dangerous at the moment, because you select multiple entries, all the next screen says is are you sure you want to delete these entries, but if you click yes, the earliest entries are deleted instead! :( Plus there is no way to delete the entries you really want deleted.

In the pages module, you delete page URIs successfully though i.e. the correct field IDs are set there e.g.

<input id="delete_box_15" class="toggle" type="checkbox" value="15" name="toggle[]">

2. The paging controls at the bottom of the edit screen do not do anything.
In the file manager file list screen they do not work either and only the first 100 files are listed.
Also, on the content edit screen, there is no message above the paging controls (saying Showing 1 to 50 of 81 entries etc) i.e. the div with class dataTables_info is empty.

I replicated the site on my dev server and both these things work fine on it.
So I know this is not a general EE issue, or an add-on interference issue - it must be down to server config.
It is hard to fathom how functionality as basic as setting the checkbox field IDs could be screwed up by a server setting, so I would really appreciate it if the support team could offer any info at all on the method being used to do this and how it could be affected by the PHP/server config.
I am hoping that perhaps one of you may have encountered this kind of thing before on strange server set ups?

I am not the server admin, and the server admin is not familiar with EE, so I need to be able to point him in the right direction of what he should look into in the server set up.

Many thanks for your time,
Janine.

I think I have got to the bottom of this, but I would still appreciate input from tech support re a line of code that is puzzling us.

By examining system/expressionengine/controllers/cp/content_edit.php and disabling JavaScript, we realised that the field IDs for the checkboxes on the edit content screen are set via JavaScript rather than PHP.
With JS disabled, the checkbox field IDs are set to 0, 1, 2 etc, but some JS then corrects this setting each field ID to the entry ID.

In the case of the live server, Firebug’s console told us that there was a 414 network error for a URL being loaded for the edit screen because the URL was longer than the max allowed for the server. I’ll get the server admin to increase this which will *hopefully* fix all the issues I posted about.

However, we are not sure why all the checkbox field IDs should be wrong even with part of the JS missing.
We cannot work out why line 661 in content_edit.php uses $id_column instead of $row->entry_id:

$vars['entries'][$id_column][] = form_checkbox('toggle[]', $id_column, '', ' class="toggle" id="delete_box_'.$id_column.'"');

$id_column is the row index, starting at 0 and incrementing, so we can’t work out why that is used to set the checkbox field IDs via PHP. We know this should be corrected via JS later, but we found that using the $row->entry_id value in this line instead, set the correct values in PHP - so perhaps this might be a bug??

//#this code change sets the right checkbox field ids and values even without some of the JS loading
$vars['entries'][$id_column][] = form_checkbox('toggle[]', $row['entry_id'], '', ' class="toggle" id="delete_box_'.$row['entry_id'].'"');

Hi Janine,

Okay if we can work through the problems in order starting with the id numbers if that’s okay?

Do you only experience this problem when you have Javascript disabled?

The control panel relies upon Javascript for various items and so trying to work in there with Javascript turned off is indeed going to cause these problems.

I know that the ‘problem’ has been around for a while now with the IDs being set once the page has loaded using Javascript but it does work if you have Javascript enabled so I just wanted to check to see if you’re experiencing an issue with Javascript enabled?

Thanks.

Mark

Hi Mark,

We always had JavaScript enabled (except to debug which is how we worked out the root of the problem), but because the server only allowed URLs upto 512 characters, and some Ajax/script call in the edit screen had a URL longer than this, some of the JS was not included which broke all the delete, edit multi and paging functionality.

I heard back from the server admin today that he had increased the max server URI length to 2048 characters, which did indeed fix all the problems we were having.

I hadn’t ever come across URIs being too long for a server before, but it might be an idea to add the server URI length needed to the requirements list for EE http://expressionengine.com/overview/requirements
Because key CP functionality will not work if URIs of a certain length are not allowed and this was a pretty tricky issue to track down.

Also, the devs may still want to take a look at line 661 in content_edit.php when time allows as per the code in my post above, because just changing the variable name there *might* just get all the IDs set correctly even without JavaScript. I realise you need JS on for the CP anyway, but I can’t understand why you would have to set these IDs that way and why they could not be right from the off via PHP. I’m new to digging around the EE source code, so there’s probably a lot more to it of course! 😊

Hi Janine,

Many thanks for the follow up and thanks for the very detailed reply, much appreciated.

I will bring this up with the team and see what they have to say about everything. If indeed the 512 character limit is what is causing this (seems like from your testing that may well be) then it does indeed sound like that might be a good fit for the requirements in the documentation.

To be honest I’ve never had this problem on any servers I’ve hosted with however I totally understand that there are many many different types of servers and environments and so this could crop up from time to time.

As for the IDs being set by Javascript I’m not too sure on that one either so will ask that too. My guess would be because Ajax is being used on the Edit page to allow for quick updating of the entries list when making selections from the drop-downs there and to eliminate a complete page refresh. I may be wrong on that though so will ask the team for the reasons behind this.

I will let you know what they have to say as soon as I have heard anything.

Thanks.

Mark

Hi Janine,

I meant to ask, which browser was this happening in? Did you try a different browser before getting the server limit upped at all?

Thanks.

Mark

Hi Mark,

I appreciate you bringing this up with the team.

This was happening in all browsers. When we replicated the site locally and it worked fine, we disabled JS locally, and found that this made the IDs on the checkboxes all turn to 0 incorrectly. That’s when we realised it was a JS issue. Then looking at the problem server again with the Firebug console revealed the 414 error due to the URL being called in the ajax being too long for the server. Once the URI length was increased from 512 to 2048 it fixed everything. Not sure how long it needed to be, I just asked for 2048 because from Googling that seemed a standard value for it.

Had never encountered a host where this was an issue before either, using EE or any other CMS, so I assume a 512 setting is rare, but from our issues it is too low for EE2 as it stands.

By the way, hadn’t realised you were offically part of the support team now - congrats! 😊
I still remember you as one of the main people who helped me when I was getting to grips with EE1 thanks 😊

Hi Janine,

Hi Mark,

I appreciate you bringing this up with the team.

No problem at all. I did mention it again today and so will get an answer to you as to why it all works that way as soon as I hear back on that one.

This was happening in all browsers.

Ah okay. I just asked as I’d read that certain browsers only allow certain lengths of URIs so wanted to rule that out as a possibility.

Had never encountered a host where this was an issue before either, using EE or any other CMS, so I assume a 512 setting is rare, but from our issues it is too low for EE2 as it stands.

Yep I’d never even heard of that before you brought it up either 😉 Good catch on it though.

By the way, hadn’t realised you were offically part of the support team now - congrats! 😊

Many thanks.

I still remember you as one of the main people who helped me when I was getting to grips with EE1 thanks 😊

No problem at all. That’s what I’ve always been here for 😉

Mark

Hi Janine,

After passing this by another member of the Support Staff here it is as I originally thought.

Due to that page utilising Ajax methods in order to update itself when different criteria are selected via the drop-down menus this is why the IDs are being set like that and so can’t be set using PHP.

Yes you could initially set them by PHP but then you would need to do that for all selections.

As far as I know this isn’t going to be changed any time soon (if at all) and as the control panel relies very heavily upon Javascript then trying to use it without Javascript enabled would cause all sorts of problems anyway.

As to your problem with the 512 character limit neither myself or the other member of the support staff have ever come across a server with that limit before so I think it’s just a little unfortunate that you came across this problem.

Thankfully you found the problem and your host was able to fix it for you though so there shouldn’t be any more problems now going forward.

Hopefully that helps to answer your questions?

Is it okay for us to close out this thread now?

Thanks,

Mark

Hi Janine,

I’m going to close this thread now. Hopefully everything was dealt with here.

If not then please do feel free to post again as needed.

Thanks,

Mark