• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Inlineedit plugin - BUG?

rdiana

Member
Dear friends,
the inlineedit element has changed its aspect! Look at the attached image, on the left you can observe inlineedit of some days ago, on the right the aspect of the current plugin (AFTER a Github update): is it a bug? can you fix it?

Many thanks...

Roberto
 

Attachments

  • inlineedit.jpg
    inlineedit.jpg
    45.8 KB · Views: 372
I really wish I could use this plugin, as the project I?m developing oftentimes has hundreds of rows - and users don?t want to have to open the edit window every time they want to make a simple change in a few dollar amounts on any one row.

This plugin still seems to still have plenty of bugs ? javascript related. Other plugins will sometimes cause the spinner to freeze and the only way to resume is to go to another web page.

The most annoying bug is that the popup is not ?always on top? - so the Save and Cancel icons cannot be seen if the row is the only row (or is at or near the bottom of a list).

Also Ajax validation is not run on the entered data when saved. That alone makes the plugin worthless for my project.:(

Please see what you can do to fix that ? as I could really use this plugin.
 
To followup - I forgot to mention the "Editable elements" option of this plugin doesn't seem to do anything.

The tooltip isn't too specific - but I tried all 3 possible ways I could think of for listing the "full element names" (as the tooltip says) - but no matter what I tried, all elements were still editable.

e.g. I tried...
tablename___field1,tablename___field2
{tablename___field1},{tablename___field2}
'{tablename___field1}','{tablename___field2}'

And nothing changed.
 
I'm a persistent guy - but just want to make sure the developers at Fabrik understand all the details.

In testing the inlineedit plugin today, it seemed to work fine on a test List I created. (But those elements were all simple ?field? elements ? read on.)

So I turned the inlineedit plugin back on in the actual production list/table that I want to use it on, and kept getting the same problem I mentioned 2 posts back (and in another thread I?m sure).

When I double-clicked an element to edit, the value in the editbox would go blank but the inline popup would not appear ? or at least it was not ?on top?. I could not actually see any part of it at all ? but if I hit the tab key (as part of the ?Save on tab? feature) ? the word ?loading? with the animated circle under it would appear, and remain forever.

Looking into Firebug, this error showed in the ?XHR? tab

500 unable to process db join element id:1166

The url was?
Code:
http://www.mydomain.com/index.php?element=fb_prn_pay___br_plus_amt_high&elementid%5B0%5D=123&elid=123&format=raw&formid=13&inlinecancel=1&inlinesave=1&listid=12&listref=12_com_fabrik_12&option=com_fabrik&rowid=4&task=form.inlineedit
This was a database join element.

OK ? so to help in debugging, I unpublished that element and tried again. This time I got (in the XHR tab of firebug)?

500 unable to process db join element id:115

This was a ?user? element used to put the userID into the row?s table record (that element is not even set to display in the list).

What is weird is that the actual HTML ?500 Page? never shows ? it just freezes with that ?loading? notice and spinner spinning.

I came to the conclusion that the bug I am experiencing with the inlineedit plugin is only occurring in lists that have non-?field? elements.

I then got to thinking that maybe, if ONLY I could filter the elements controlled by the plugin (as it is supposed to work ? see my last post) - then I would only include the ?field? elements (they are all I want to be edited anyhow) and perhaps the bug would go away?

So it sounds like your first concern should be getting that filtered comma delimited list of affected columns to work correctly in the inlineedit plugin. Then if that helps the problem ? until you get to the root of the bug - then you could explain to users the ?issues? with the plugin and insist they must filter to only ?field? type elements - and explain that you are working on the ?other issues?. How?s that for a plan?

I need this plugin to work ? It?s why I chose to try Fabrik in the first place.
 
To followup - I forgot to mention the "Editable elements" option of this plugin doesn't seem to do anything.

The tooltip isn't too specific - but I tried all 3 possible ways I could think of for listing the "full element names" (as the tooltip says) - but no matter what I tried, all elements were still editable.

e.g. I tried...
tablename___field1,tablename___field2
{tablename___field1},{tablename___field2}
'{tablename___field1}','{tablename___field2}'

And nothing changed.
Maybe it might be csv style, do like this:
tablename___field1,tablename___field2
 
Yes, a databasejoin element is breaking inline editing (even if it's not shown in list view). Without such an element I can
edit field and date elements
define which elements are editable (syntax tablename___field1,tablename___field2)

As soon as the DBjoin element is enabled FF console is showing
500 Internal Server Error 394ms mootools-core.js (Zeile 485
when trying to edit an element (for a moment the "loading" spinner can be seen)
 
(It's good to know that for once it's not just me being a "stupid user".:p)

Do you think it will take long to fix it?

How about the Ajax validation issue? Any chance of Ajax validation rules being applied to the inlineedit plugin?

friendly bump :)
 
I'll try this again - bump

Any idea if anyone is looking into fixing the problem? Or should I just concede to not using inlineedit for lists that have databasejoin elements? And again, what about Ajax validation?
 
I've altered the forms that I need to use the inlineedit plugin so that they do no contain a databasejoin element in them and inlineedit seems to work fine - even when specifying columns to filter the plugin to.

BTW - The key is to restricting the inlineedit plugin to certain columns is to just use a comma delimited list that includes the full Fabrik element names that should be affected by the plugin - without any brackets or quotes. (Don't ya just love it when I answer my own questions?)

So my other question still remains unanswered...

Is integration with Ajax Validation on the horizon for the inlineedit plugin?
 
The most annoying bug is that the popup is not ?always on top? - so the Save and Cancel icons cannot be seen if the row is the only row (or is at or near the bottom of a list).
I would think tHis would be some thing specific to your site's css, where the popup z-index is less than other parts of the DOM,

500 unable to process db join element id:115
Theres something not 100% right with the loading of the inline form, which is causing this error, for now I'm simply not throwing the notice if its the inline editor that is calling the form. As the db element is not loaded on the inline form it works fine.

What is weird is that the actual HTML ?500 Page? never shows ? it just freezes with that ?loading? notice and spinner spinning.
We needed to catch that in the ajax code an iterogate the status header, which is now raised as a simple alert, although as stated above the initial error should no longer be triggering.

I came to the conclusion that the bug I am experiencing with the inlineedit plugin is only occurring in lists that have non-?field? elements.
The issue was that any element which inherits from the database join element (user, db join or cdd), when included in the list would cause issues.

Also Ajax validation is not run on the entered data when saved
A first stab at this is implemented now, so update from github and test please
 
The zindex thing mysteriously went away when I switched templates (back to Beez5). Funny thing is - I'm back to using another 3rd party template by the same company "framework" and it has still been working fine. It's not the first time I've had that same sort of issue with popups - and I know what a pain they can be to debug. (Have I told you lately - I hate javascript?:p)

I downloaded from Github - but it's getting late (after midnight here) - so i won't get around to testing it til morning.

Thank You for addressing this, Rob - it's important to me!;D
 
[...]
A first stab at this is implemented now, so update from github and test please
The improvement is that the inlineedit popup remains ontop even as the Ajax begins to process. But the 500 error persists in Firebug (while not actually showing the 500 page) as the animated Ajax icon continues to spin. And even clicking ?Cancel? in the inlineedit popup does not kill the Ajax spinner.
 
hmm can you point me at the page please?
Did you check that you had cleared your browser cache - sometimes that causes issues when updating js scripts.
 
hmm can you point me at the page please?
Did you check that you had cleared your browser cache - sometimes that causes issues when updating js scripts.
I must clear my browser cache on the average of every 15 minutes.

Why do you need me to provide access to the site? I have no problem doing so ? but it would take a little work to create a special user account (and subscription). And the bug is not unique to my site ? I?m sure.

Rather than you trying it out on my system ? how about if someone tests it to see if they have differing results than what I report here? My guess is you tried it once and thought it was working fine.

If you can?t duplicate the problem I am having, by following my simple example, then I?ll be glad to create an account so someone can look at my system to try to figure out ?my? problem.

Would you, (or any of the in-house Fabrik ?testers? ? or any other users reading this post) just?

  1. Create a simple test List (as I explained in my first post in this thread) ? and add a few rows.
  2. Enable the inlineedit plugin and specify a numeric field/element in ?Editable elements?
  3. Create a Validation rule for that element.
Then let me know what happens when you edit a few of those elements ?inline?.

I tried using numerous Validations plugins ? notempty, isgreatororlessthan, etc. and they all crash the plugin when validation fails. If the validation fails, the inlineedit popup remains and will not go way no matter what you enter.

I tried a little debugging on my own ? but I?m lost.

When run on the admin backend, the Firebug error showed red for ?Get blank.png?. It sounds like you are assuming a file http://www.mydomain.com/administrator/images/blank.png exits. (There is no administrator subfolder named ?images?.) Or maybe that isn?t even related to the inlineedit plugin ? I have no idea.

So I created a menu item and tested the List on the front end. Same problem. (And yes the file http://www.mydomain.com/images/blank.png does exist, so the red error in Firebug wasn?t there as was on the backend ? but the plugin still ?misbehaves?.)

If you edit a number in the number element (a ?valid? number), it seem to work ok, ONCE ? but entering an invalid number breaks the plugin.

If you entered a valid number and then go back and edit that same element ? the inlineedit popup will show the old value. And if you edit another element it stops working.

It seems like you can only edit one row. If you edit one row successfully (with a valid number entered) then move to another row, the inlineedit popup will stop responding and the popup won?t go away no matter what you try doing.

Can anyone else PLEASE try this - and let me (us) know if you have the same results.
 
I must clear my browser cache on the average of every 15 minutes.
I was just checking - its a common issue that often causes people not to see changes we have made in the js code

When run on the admin backend
ah OK the back end!
I must not have read that earlier or you hadn't mentioned. Things work fine on the front end. This is why I often ask people to point me at the page as:

1) Text descriptions of a set up often leave out vital information no matter how accurate we try to be, or alternatively I glaze over the part that actaully matters.

2) Setting up specific tests is time consuming and not guaranteed to re-produce the bug, as often bugs are dependant upon other things installed in Joomla (templates, plugins modules etc)

So yes I did have a test case set up exactly in the way that had been described, and just the fact that I was testing on the front end meant that it worked for me.

There should be a fix now in git hub for the backend

When run on the admin backend, the Firebug error showed red for ?Get blank.png?. It sounds like you are assuming a file http://www.mydomain.com/administrator/images/blank.png exits. (There is no administrator subfolder named ?images?.) Or maybe that isn?t even related to the inlineedit plugin ? I have no idea.
I don't think that is coming from our code, I just did a global search on 'blank.png' and didn't find anything
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top