Bug #23604 See Comments

Adding extra row to grid field triggers error and the crash - EE4.2.1

Version: 4.2.1 Reporter: glawrie

Site has a fluid field attached to a channel, and within the fluid field are linked several grid fields.

Choose a grid field and site works just fine until grid field gets above a certain size.

Have developed a repeatable error where adding an extra row to a large table initially triggers ‘Error’ markers on the submit buttons for the page.

Deleting the row during the add (i.e. after errors have appeared) clears the error and the entry can continue to be edited.

Reloading the page when the error occurs results in the added row elements continuing to be displayed, but errors in submit buttons are cleared.

Saving the page at this point triggers a serious / fatal EE error

Fatal error: Uncaught Error: Call to a member function updateAuthorStats() on null in /var/sites/g/greentree-ee4.jcogs.net/system/ee/EllisLab/ExpressionEngine/Model/Channel/ChannelEntry.php:446 Stack trace: #0 [internal function]: EllisLab\ExpressionEngine\Model\Channel\ChannelEntry->onAfterUpdate(Array) #1 /var/sites/g/greentree-ee4.jcogs.net/system/ee/EllisLab/ExpressionEngine/Service/Model/Model.php(824): call_user_func_array(Array, Array) #2 /var/sites/g/greentree-ee4.jcogs.net/system/ee/EllisLab/ExpressionEngine/Service/Model/Query/Update.php(51): EllisLab\ExpressionEngine\Service\Model\Model->emit('afterUpdate', Array) #3 /var/sites/g/greentree-ee4.jcogs.net/system/ee/EllisLab/ExpressionEngine/Service/Model/DataStore.php(281): EllisLab\ExpressionEngine\Service\Model\Query\Update->run() #4 /var/sites/g/greentree-ee4.jcogs.net/system/ee/EllisLab/ExpressionEngine/Service/Model/DataStore.php(247): EllisLab\ExpressionEngine\Service\Model\DataStore->runQuery('Update', Object(EllisLab\ExpressionEngine\Service\Model\Query\B in /var/sites/g/greentree-ee4.jcogs.net/system/ee/EllisLab/ExpressionEngine/Model/Channel/ChannelEntry.php on line 446

This behaviour does not affect the rendering of the grid - if you add additional rows via SQL rather than EE CP interface the additional rows (i.e. above 162 in the test case) display fine in both CP and on the public site, but any attempt to save the entry triggers a different error - with multiple warnings and the edit not being saved. Vis:

Notice
Trying to get property of non-object
ee/EllisLab/ExpressionEngine/Model/Channel/ChannelEntry.php, line 266

Severity: E_NOTICE
Notice
Trying to get property of non-object
ee/EllisLab/ExpressionEngine/Controller/Publish/AbstractPublish.php, line 99

Severity: E_NOTICE
Notice
Trying to get property of non-object
ee/EllisLab/ExpressionEngine/Controller/Publish/AbstractPublish.php, line 102

Severity: E_NOTICE
Notice
Trying to get property of non-object
ee/EllisLab/ExpressionEngine/Controller/Publish/AbstractPublish.php, line 112

Severity: E_NOTICE
Notice
Trying to get property of non-object
ee/EllisLab/ExpressionEngine/Controller/Publish/Edit.php, line 539

Severity: E_NOTICE

To help explain what is happening have made a screen-grab video of the error (following steps described above) - https://www.dropbox.com/s/qu1qbbg5pwx9np6/Screen%20Recording%202018-05-13%20at%2014.51.52.mov?dl=0

  • Thanks for those details but I’m not able to reproduce. It sounds as if this is happening only to a certain entry/entries. The nature of the errors indicates you may have a lack of integrity in your database records for these entries. Please contact support if you need assistance in figuring out what is off about these entries in your database and how it might have occurred. Since it’s not reproducible, in order to help you our engineers would need access to your environment which can occur with a support ticket.

    If you feel this is in error and that this is a software bug, please provide the steps to reproduce on a fresh installation without add-ons.

    Derek Jones
    14th May, 2018 at 11:31am
  • I’ve done a lot of testing on this. Given that the error appears mid-way through adding data to a new row, it suggests it is being caused by whatever JS process is running on the page rather than the data itself. My guess is that after each cell is filled you run some kind of check and access the database (hence why if the system errors occur and you reload the page, the partially filled in row is still partially filled in, even though the row had not been ‘saved’ formally. At some point something is happening with that validation check that pushes something to report an error.

    My hunch is that the issues is linked somehow to the amount of data stored in the table: so to reproduce you really need to reproduce the amount of data too: I have no way of knowing how much data your engineer put into his / her table - but it is highly unlikely to be the same. As the test video shows, below the critical data amount (if that is what it is) the table works just fine.

    I simply don’t buy the ‘data integrity’ argument. What are you referring to as “these entries”? The table data? Something else? Given that many other smaller tables created in just the same way are working fine - and the one in the report works just fine if you don’t exceed the critical number of rows - to declare without any apparent basis that this is a one-off data corruption issue seems a bit of an easy-out. Anyhow, so I created a completely new entry that is empty of all data and add just the test table data, the bug performs in precisely the same way as it does in the actual data - failing at precisely the same point in each case For this to be due to some kind of data corruption seems highly unlikely.

    If you are saying the only way for me to get you to look into this is to pay you, I guess I have no choice. But if it does turn out to be a bug presumably you’ll refund whatever I pay?

    glawrie
    14th May, 2018 at 11:51am
  • I’ve already spent an extensive amount of time trying to reproduce your error (including when you first mentioned it in Slack and in the forums and I suggested you put in a support ticket) without success. ExpressionEngine doesn’t put any self-imposed limitations on rows of content, nor the size of data for an entry, so if that is the cause, it is likely environmental.

    My suggesting that it could be a data integrity issue is based on the details in your errors. Those line numbers in both the fatal error and the notices indicate that at that point in execution, the Channel Entry no longer has an associated Author, nor an associated parent Channel. I’ve seen that before for instance when the author_id for an entry was set to a member that had been manually deleted from the database using SQL. But it not occurring every time lends more towards an environmental issue.

    So another possible explanation is since it’s happening to you only after a certain number rows is that your environment may be dropping POST fields due to the number of fields or total submitted content. post_max_size limitation, or Suhosin max vars, etc.

    Support tickets get the direct attention of an engineer on your environment, with a guaranteed response time, so there are no refunds for the services rendered. If you’ve not used it before, every valid ExpressionEngine license holder is entitled to three months of this direct support for free. The only other way to assist you with this particular issue would be if you are able to provide instructions on how to recreate this error reliably on a fresh installation, that is not dependent on any environmental limitations.

    Derek Jones
    14th May, 2018 at 12:24pm
  • I guess there is nothing so powerful as a preconceived idea. I’ll talk to the client and see if they are prepared to spend money on this. Unfortunately they are not prepared pay for my time to create fantasy websites in pursuit of your conditions for agreeing that this might be a bug rather than user error, but maybe they will spend money on you doing so - but you are not doing a very good job of selling an open minded positive approach here.

    glawrie
    14th May, 2018 at 12:34pm
  • I’m sorry for your frustration, but I do feel we’ve gone above and beyond here. I’ve pointed to potential problems that your errors suggest may be the issue (data integrity, environmental/POST limitations), and I have spent much time trying and failing to reproduce your error. There aren’t any behaviors or clues that currently point towards it being a bug, other than your strong belief that it must be. You’ve tried Slack, including DMing me, the forums, and now the bug tracker; you’ve spent much of your own valuable time trying to avoid our official support channel, where regardless of what the cause is, our team probably would have solved it for you already. ¯\_(ツ)_/¯

    Derek Jones
    14th May, 2018 at 1:16pm
  • OK - well thanks for that. I guess we just have to agree to disagree about what constitutes a bug. Sorry to have wasted your time etc.

    glawrie
    14th May, 2018 at 1:19pm

You must be signed in to comment on a bug report.

ExpressionEngine News

#eecms, #events, #releases