Inlineedit not working

[Bauer]

It looks like the inlineedit plugin stopped working (or maybe this is a php7 thing?)

When a element is saved the response returned to the onSuccess function is triggered - but the value returned is always blank. So the cell is always replaced with a blank.

If you go to re-edit the same cell, when the popup comes up the value you last entered is shown again as the input value. Yet the cell always is replaced with a blank (unless you select 'Cancel' rather than 'Save').

It looks like the problem is the ajax request call is returning success, yet the returned value is always empty.

So after saving an inlineedit, the cell is always replaced with a blank - and I looked, the database table is never updated.

The cell becomes blank because this code gets run...

                'onSuccess'  : function (r) {
console.log(r);                 
                    td.removeClass(this.options.focusClass);
                    td.empty();
                    td.empty().set('html', r);

and r (the ajax response sent to the console.log) is always blank - unless it fails validation, then it produces an error and the ajax spinner just freezes. (And BTW, that 1st td.empty() is not needed because the next line makes it redundant)
(See attachment).

Mootools and Ajax are not my favorite languages to debug as I'm not very proficient in their use. So I have been unable to figure out why the edited data is not being stored, yet returns success.

 

[Bauer]

Somehow, I got this working again - except for when the validation fails.
I'm pretty sure it had to do with the 'Show validation icon' being set to yes in the element, though I've been too busy to re-confirm..

But the problem still remains with the mootools error shown in the console IF I edit an element fails the validation rule. If I turn off the validation it works.

So it looks like, when the modal popup is rendered without headers (such as for the inlineedit popup), Fabrik needs to come up with a way of sending the validation failure error message to a simple javascript alert - rather than trying to put it in the Joomla system message div - which I'm pretty sure is what is going on here with the "Cannot read property insertBefore of null"- and what triggers the the error that is shown.

I don't understand mootools well enough to know how to do that. I tried intercepting the xhr message that is returned in the inlinedit.js save event - but by that point the 500 error is already triggered.

 

[Bauer]

I don't give up easy.
These 2 bugs I posted this weekend are definitely related. The problem with the inlineedit not updating the table and returning a blank in the td - is only happening on columns set as type Integer. Decimals work fine.

Funny that the problem in my other post - regarding a blank being rendered in the td in a list for 0 (zero) values (even without inlinedit plugin enabled on that list) - is also only happening in columns set as Integers.

I'm convinced that is someone can figure out why that is happening, and fix it - then the inline edit plugin will work again too.

 

[Bauer]

Why do these things always happen to me on Fridays - so I ruin my weekend trying to figure it out?

I have been arguing now for 2 years - pleading that the inlinedit plugin NOT be redacted from Fabrik.
There is really nothing wrong with it that can't be fixed with a little work - and it is the most important tool in the Fabrik package - at least when it comes to my project.

OK here's the story...
I've found what was causing the blank responses. The only real problem I still have is how to handle the validation errors (shown in the attachment above).

But I noticed that Hugh just tweaked some code recently to handle that for another ajax routine in another plugin - and he has a good grasp on 'how the engine works'. Basically, for the inline edit plugin (and anything that uses a modal div popup div that isn't an inline page) we need a way of displaying the error in an alert rather than what it's doing now - which then breaks mootools and freezes the javascript.

But, while diving into the code trying to debug this issue, I came across a few efficiency issues in the form.php code...
There are some errors in the validate function code that makes it more complex and much slower than it needs to be.

Also, every element in every group included in the list is being checked for validation rules - not just the ones shown in the list - when it should really only be the columns that have been configured for inlineedit. And for that matter, since each element is submitted individually, validation should ONLY be made on the column being edited. I'm sure that could be done - and THAT would speed up the inlinedit plugin immensely.

If I get time 'later' today (it's 1:30am here and I'm about to fall out), I'll post the immediate changes at github (for the efficiency problems that I found, which affect all plugins and should help speed up validation) - and then start working on the tweaks for inlineedit.

Now in the meantime, I'm hoping that someone who understands mootools Requests better - and how the validation error is passed back to the inlinedit.js, can fix that mootools error (or at least point me to exactly where it's done). Then I'll be one happy camper again.

 

[coullet]

I agree, inline edit is a very important plugin.. and it would be even better like an excel sheet

But i don't have level for this sort of dev...