1. Fabrik 3.8 has been released. As usual, we strongly recommend that you backup your site (using Akeeba) before upgrading. Report any issues in the forums, we will answer promptly.

Inlineedit plugin - BUG?

Discussion in 'Fabrik 3.x Testing' started by rdiana, May 5, 2012.

  1. rdiana

    rdiana Member

    Level: Community
    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...


    Attached Files:

  2. rdiana

    rdiana Member

    Level: Community
    friendly bump:)
  3. rob

    rob Administrator Staff Member

    Level: Community
    thanks for pointing that out - it should be fixed @github
    1 person likes this.
  4. rdiana

    rdiana Member

    Level: Community
    Dear Rob,
    many many thanks for your solution, it works fine!
    Best regards,

  5. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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.
  6. Bauer

    Bauer Well-Known Member

    Level: Supporter
    friendly bump:)
  7. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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...

    And nothing changed.
  8. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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 (Text):
    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.
  9. mk13

    mk13 New Member

    Level: Community
    Maybe it might be csv style, do like this:
  10. Bauer

    Bauer Well-Known Member

    Level: Supporter
    Isn't that exactly what my first "e.g." example reads????

    friendly bump:)
  11. troester

    troester Well-Known Member Staff Member

    Level: Standard
    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)
  12. Bauer

    Bauer Well-Known Member

    Level: Supporter
    (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 :)
  13. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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?
  14. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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?
  15. rob

    rob Administrator Staff Member

    Level: Community
    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,

    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.

    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.

    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.

    A first stab at this is implemented now, so update from github and test please
  16. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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
  17. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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.
  18. rob

    rob Administrator Staff Member

    Level: Community
    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.
  19. Bauer

    Bauer Well-Known Member

    Level: Supporter
    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.
  20. rob

    rob Administrator Staff Member

    Level: Community
    I was just checking - its a common issue that often causes people not to see changes we have made in the js code

    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

    I don't think that is coming from our code, I just did a global search on 'blank.png' and didn't find anything

Share This Page