Bugs with JTags APIs

[Bakual]

Hi all

Just wanted to note that while trying to implement tags into my component, I found some bugs related to the various JTags APIs (in 3.1 Beta 4).

I'm listing the TrackerItems/PullRequests in case someone is interested to confirm and test it.

• Access control in tag view only works for items with an access column. Extensions without access control on item level get their tagged items not listed in this view since core_access will be set to 0 in the #__ucm_content table.
  https://github.com/joomla/joomla-cms/pull/996
  http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30588
• JUcmContent can't constructed using only the type_alias. One always has to provide the table so the constructor doesn't fail. This is because the constructor looks for  the information at the wrong place, and also there are errors in the SQL (wrong JSON and a missing quote).
  https://github.com/joomla/joomla-cms/pull/991
  http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30584
  

[Bakual]

Second issue is fixed in master. Thanks to Mark and Elin for confirming and testing.

First issue is confirmed but still needs tests.

[Bakual]

• There is a bug when creating the ContentType using JTableContenttype->save($item).
  This needs a patch from someone who knows Regex as the generic alias-check used is to strict for the type_alias.
  

Am Dienstag, 16. April 2013 13:53:00 UTC+2 schrieb Bakual:

[piotr_cz]

Probably there is a bug in TagsTableTag->save:
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_tags/tables/tag.php#L59

`$item->urls` should be `$array['urls']`

Sorry for not creating PR, I'm short on time


On Apr 17, 12:54 pm, Bakual <werbema...@bakual.ch> wrote:
>    - There is a bug when creating the ContentType using

>    JTableContenttype->save($item).
>    This needs a patch from someone who knows Regex as the generic
>    alias-check used is to strict for the type_alias.
>
> Am Dienstag, 16. April 2013 13:53:00 UTC+2 schrieb Bakual:
>
>
>
>
>
>
>
>
>
> > Hi all
>
> > Just wanted to note that while trying to implement tags into my component,
> > I found some bugs related to the various JTags APIs (in 3.1 Beta 4).
>
> > I'm listing the TrackerItems/PullRequests in case someone is interested to
> > confirm and test it.
>

> >    - Access control in tag view only works for items with an access

> >    column. Extensions without access control on item level get their tagged
> >    items not listed in this view since core_access will be set to 0 in the
> >    #__ucm_content table.
> >    https://github.com/joomla/joomla-cms/pull/996
>

> >    http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...
> >    - JUcmContent can't constructed using only the type_alias. One always

> >    has to provide the table so the constructor doesn't fail. This is because
> >    the constructor looks for  the information at the wrong place, and also
> >    there are errors in the SQL (wrong JSON and a missing quote).
> >    https://github.com/joomla/joomla-cms/pull/991
>

> >    http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...

[Bakual]

Sorry, forgot to add Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30555

[Bakual]

Did a PR and Tracker for you:

https://github.com/joomla/joomla-cms/pull/999

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30595

Do you know where it is used? In my testing server, the urls are saved correctly into #__ucm_content. So I don't know where this table is even used and can't test it.

[piotr_cz]

Well, this is something what is unclear to me about Joomla.

While saving the model (Tag), some fields are encoded to JSON:
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_tags/models/tag.php#L290

Than the data are being passed to TagsTableTag->bind, and these are
encoded to JSON once again:
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_tags/tables/tag.php#L59

Seems to me that author took code from model and pasted it to table.


What is the correct place?


On the other side while loading data from table, these are decoded in
getItem method and not TagsTableTag->load



On Apr 17, 1:46 pm, Bakual <werbema...@bakual.ch> wrote:
> Did a PR and Tracker for you:https://github.com/joomla/joomla-cms/pull/999http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...

>
> Do you know where it is used? In my testing server, the urls are saved
> correctly into #__ucm_content. So I don't know where this table is even
> used and can't test it.
>
> Am Mittwoch, 17. April 2013 13:18:29 UTC+2 schrieb piotr_cz:
>
>
>
>
>
>
>
>
>
> > Probably there is a bug in TagsTableTag->save:
>

> >https://github.com/joomla/joomla-cms/blob/master/administrator/compon...

[Mark Dexter]

Hi. We are in the process of significant refactoring of the methods for saving tags. We hope to have some new code to show tomorrow. Please bear with us. Thanks! Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.

[Amy Stephen]

Please, please, please consider holding on the Tags component and instead offer it first as an official extension on JED. Today is the intended day for release. Since this is a core solution, extensions will write to the API and a significantly refactored API rushed in the last minute could very easily wind up with new errors.

There is no shame in taking a more prudent approach, in fact, there is a lot of benefit to allow extension developers time to install it as an extension and work with it for a release cycle and see what they say. A little time might even build enthusiasm and generate a little PR for joint announcements with devs.

I know it sounds disappointing, but in all honesty, it's the best approach to ensure stability. Thanks for considering.

[Mark Dexter]

Amy, if you look at the implementation, it is very deeply tied into the core CMS. The PLT has already decided to include tags for 3.1, so we are past the point of discussion. It's going to be a great addition to Joomla imho. Mark

[Bakual]

Agree with Mark here. It's not really possible to offer it as an extension on JED. It doesn't really matter if 3.1 is released this week or next. But if's important that tags are included and are working.

[Amy Stephen]

That makes sense, Mark. Please take the time you need.

[Bakual]

Not a bug but a bit a strange thing: The field_mappings in #__content_types are stored like this:

{"common":[{"core_content_item_id":"id, ...}], "special": [{"fulltext":"fulltext"}]}

 

Which means it translates into this when json_decoded:

$field_mappings->common[0]->core_content_item_id

$field_mappings->common[0]->...

$field_mappings->special[0]->fulltext

 

Imho the array part is unneeded. I don't think there will be more than one "common" or "special" mappings within one entry.

So the JSON should read like this instead:

{"common":{"core_content_item_id":"id, ...}, "special": {"fulltext":"fulltext"}}

 

And it would need changes where the field mapping is read.

I could make a PR for this but would love to get some feedback first. Also it's quite close to release, so not sure if it makes sense to change that or just leave it as is. It's not like something is broken, it's more a design question.

 

 

Am Dienstag, 16. April 2013 13:53:00 UTC+2 schrieb Bakual:

[Mark Dexter]

That makes sense to me, unless someone sees something I'm missing. Mark

--

[Michael Babker]

This one's already been fixed: https://github.com/joomla/joomla-cms/commit/043ae3e478fc4f91cd74239f4edf4974a7075ee7

[Bakual]

Changing the storage format of field_mappings: Removing the unneeded array part in it.

Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30607

PR: https://github.com/joomla/joomla-cms/pull/1001

[Bakual]

There is also a bug within the similar tags module.

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&feedback=Successfully%20added&tracker_id=8103

It happens when you have two tagged items with the same id, but from different extensions. Like an article with id = 1 and a contact with id = 1. Then it will not show the matching item because the SQL thinks it's the same item.

Am Dienstag, 16. April 2013 13:53:00 UTC+2 schrieb Bakual:

[elin]

Mark and I have posted a pr here and we'd appreciate a round of testing.

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30621

Thanks all for issue reports, they really help make Joomla better.

Tonight I'll be updating dev docs to reflect the changes in the apis and implementation in extension (which now involves many fewer lines of copy and pasted code).

Elin