Broken Tags Element....

rrwilson

Member
Hello,

This is a repost of what I had posted on the Community forum before signing up a moment ago, dipping our toe in yet further! Community post deleted to keep it organised.

Many thanks,

Richard.

---
Hi all,

I am just dipping my toe into Fabrik to see if it meets our needs before committing ourselves. It is great but the our hopes for the tabs functionality is driving us mad. It looks great in theory, but I am suspicious that something is broken at our end or in Fabrik.

1) Tags are not being looked up
- both when only using the core joomla tags table or another table
- also after typing in the min chars

2) When tags are created in a form when adding a record (that is possible, even if it is blind due to no lookups) they are added to the tags table in an apparently broken way
- The lft and rtl fields are set to 0, when the shouldn't be
- In the tags component admin list the added tags have blank Access Level entries (tags created when tagging an article, for example, have Public access listed, but the point is they have access listed). Language is also "Undefined"

I have been going round and round. Permissions and ACLs seem fine. I really hope I am being daft in some way.

Any pointers appreciated!

Many thanks,

Richard
 

Attachments

  • snapshot1.png
    snapshot1.png
    32.4 KB · Views: 214
  • snapshot2.png
    snapshot2.png
    48.8 KB · Views: 222
  • snapshot3.png
    snapshot3.png
    12.4 KB · Views: 205
I think it's not totally broken but totally slow
1) Tags are not being looked up
- both when only using the core joomla tags table or another table
- also after typing in the min chars
This is working on my site - if you are waiting for long time (and you have to type at least 3 chars)

The element is not working in popup forms https://github.com/Fabrik/fabrik/issues/1640
It's no core element and I think it's not used very often and so not really up-to-date.
 
Morning, thanks for the reply.

Good to know about popups, but I am not using them (yet). I don't think it's a speed issue. It is running on an overspecified local machine with excess resources and joomla tags are punchy elsewhere, when publishing articles :(
 
Plus there is also the problem that they are not being written properly to the DB in my case from what I understand (point 2) :(
 
I only wanted to add my observations.
As I've said I assume the tag element is not up-to-date and may need some improvements.
 
I only wanted to add my observations.
As I've said I assume the tag element is not up-to-date and may need some improvements.
Thanks :) It's important to know that it's do'able. Given the important role of tags nowadays outside of basic content, that's a relief :)
 
I had seen the official Joomla XML approach. But that wouldn't fit in so neatly to another environment, like Fabrik or CB and all of their plus points. Plus the official XML approach uses the Joomla component as it stands, which I guess means you wouldn't be able to have more than one tag table, which is crucial in our case.
 
I have been battling with this but with no success :(

To explain it better, please see the attached screen shots that have the 'story' written on them to see what I see.

Thanks again in advance

------------------

snapshot4.png

---------------

snapshot5.png
--------------------------------



snapshot4.png


-------------------


snapshot5.png



-------------



snapshot6.png



---------------



snapshot7.png



--------------



snapshot8.png



------------------


snapshot9.png


-------------------

snapshot10.png


----------------




snapshot11.png
 
Thanks Hugh. I have just added it. I have added a temporary port forward for this to my dev machine. Please do let me know when I can close that hole.

I have added the joomla and phpmyadmin users for you. FTP is trickier. I hope that's ok for now....

Richard.
 
I'm testing a fix here, I'll push it up to github as soon as I've finished testing.

I've altered our tag saving to directly call the com_tags backend model save() method, instead of just updating the database ourselves. That should correctly set the bounds and rebuild the tags table to maintain the nested set integrity.

-- hugh
 
Thanks again Hugh. This definitely moves things forward.

1) I have popped in that new tags.php which has sorted the lft & rgt numbering, which is now correct on new tag addition from a Fabrik form! Unfortunately, I still can't lookup tags sadly from the official Joomla tags component, so I guess that wasn't the cause :(

2) I also noticed that all tags now seem to go in the core tags table - the "Table for tags (empty = J! core tag table)" field now seems to be ignored. It would be great if that improvement of that core Joomla by Fabrik could be resuscitated in some way. Its about permissioning of tags and being able to segregate them into groups for different contexts. That is a huge Fabrik plus if you want to take tags to the level of being useful in an application/CCK context, rather than just for articles as a CMS. But even a CMS probably needs it.

Do let me know what I can do/try myself or reopen on my machine for you to pop in.

Richard
 
I also noticed that all tags now seem to go in the core tags table - the "Table for tags (empty = J! core tag table)" field now seems to be ignored.
Are you running the latest GitHub? This is working on my site, tags are inserted in the alternate tag table (without lft/rgt etc. in this case, but I think Fabrik doesn't need it)
I still can't lookup tags sadly from the official Joomla tags component
This is working, too. But it needs about 4 seconds to show the tags (after typing the 3 minimum characters), so not really usable.

In list view there are some warnings
Warning: array_combine(): Both parameters should have an equal number of elements in C:\xampp54\htdocs\j33\plugins\fabrik_element\tags\tags.php on line 511

Warning: array_unique() expects parameter 1 to be array, boolean given in C:\xampp54\htdocs\j33\components\com_fabrik\helpers\html.php on line 2466

Warning: Invalid argument supplied for foreach() in C:\xampp54\htdocs\j33\components\com_fabrik\helpers\html.php on line 2468

But as far as I can see the tags are displayed correctly.
 
Morning all, great to see the site is back up! :) Heart stopping when these things happen :eek: Hopefully not too stressful!

The post-14th's posts have gone now, so I thought that I should recap as Hugh was going to pop in through my backdoor port forward.

The above tags.php issues were all fixed by later replies and new changes to the version on github, which is great and really whet our appetite :D The followup issues that resulted are below. Links are to under my testing site listed on "My Sites" to show the issues. Please let me know if I can do anything also.

1) Embedding the fabrik plugin as a form fails on record update with a continual round and round loading gif
    • index.php/cb-profile/userprofile (last tab)
    • index.php/article-with-fabrik-tags
    • NB : index.php/article-with-iframed-fabrik-tags (I'd wondered if an iframe would sort the problem, but that just resulted in the iframe redirecting nidely to the updated form, but with entire site with menus, etc. within the iframe, which seems obvious now - but was worth a try)
2) The tags field is rendered badly on a fabrik form embedded in CB when inputting chars, even if that form is fine when embedded elsewhere. Only the top pixels of the letters are visible while typing blind to select tags:
  • index.php/cb-profile/userprofile (last tab)
  • image attached
  • Running latest Chrome Version 49.0.2623.87 (64-bit) from Google's debian package on Linux
  • "Inspect elements" was useful, both for inspecting and to adjust markup to see if rendering fixed
    • field pixel height not the issue I think . It is equal both where typing tags is rendered properly or where 'blind'/missing pixels (29px)
    • field pixel length does not seem to matter.
      • I have checked this by increasing the length of the field via Chrome elements source where pixels are missing on tag input, which did not stop the issue when the longer field renders.
      • the field input also rendered properly where the field pixel length was shorter than the problem CB example or in a working tags field in an article fabrik form plugin. e.g. quickly obvious in that site in a site that results from the above iframe refresh/redirect
Thanks all,

R
 

Attachments

  • snapshot15.png
    snapshot15.png
    14.5 KB · Views: 192
Hmm, in my Chrome it's looking ok
Edit: didn't test the correct place

With every character typed the input width is increasing (25,32,39,46...) but as soon as a tag is found the width is re-set to 25px.
Overflow-x and -y is hidden.
The characters are "vanishing" in the normal forms (Your Skills, Article with Fabrik tags), too (type 'cloud' and wait a moment) but it's not so obvious because it's seems there's less padding.

I think the issue is the setting width to 25px, no idea where and why this is done.
 
Last edited:
Hi troester, thanks again for looking. I am a wee bit confused though, as we might be talking about different things. On the other hand, it could very well be my ignorance regarding your point about an overflow... To try to help explain myself better just in case, I have recorded my screen to show what I see. The vimeo vid shows the two probs of 1) the loading gif sticking when saving in an embedded fabrik form and 2) inputting tags completely blind in an embedded fabrik form in CB (but from the start and without delay).

I see what you mean re prob 2 above, about waiting for a few moments in normal forms and some extremely minimal disappearance happening some seconds after. Is this not a different thing though?:
  • What you describe needs a user delay, so that presumably seems more to do with what's happening to the formatting as it is being processed by the ajax tag magic(?). That seem very different to what happens in prob 2 when typing tags into the fabrik form embedded into CB. There is no delay and pixels are instead missing from the start.
    • The video linked section from around 05.15 shows nearly all the lower input pixels being cut without any delay.
    • Do you not see this too?
  • What you describe seems to happen to different pixels, as prob 2 loses nearly the entirey of the bottom pixels, leaving only a few px of the top of the tallest letters and the cursor.
But again, does this all relate to the overflow you mention?

 
I'm thinking aloud ;)(so Hugh or Rob may hear it)
The problem is: this is the input size in the CB tab. It's because CB is doing
.cb_template * {
box-sizing: border-box;
}
on <li class="search-field">
(What is box-sizing: border-box; doing?)
So you won't see your complete characters. You can try to add custom CSS to your Fabrik form
li.search-field {box-sizing:initial}
upload_2016-3-18_13-59-9.png


This is the input size in direct fabrik forms
upload_2016-3-18_14-5-21.png


The width (overflow) problem can only be seen (in CB and in normal forms) if you are typing more than 3 characters AND there's an existing tag for these characters (because then the width is reset to 25px which will cut all after about 3 characters). I assume it's not your main problem here.
 
We are in need of some funding.
More details.

Thank you.

Members online

No members online now.
Back
Top