[com_content] Use condition show_tags in the view instead of in the model #10519

csthomas · 2016-05-16T20:41:24Z

Summary of Changes

Tags usually slow down content pages, so I changed code to not load tags when it has not been required.

Reasons:

When show_tags is enabled in menu/global then modules which use "model articles" load unnecessary tags but did not use it. The PR removes unnecessary sql queries.
Article view should not load tags if admin do not want to show tags.
After applied patch there is option to show tags only for article view and hide for featured/categories. This is for those who love performance.

Testing Instructions

Change options for "Show tags" in menu items related to com_content.

Test menu item for featured view (test all options for "Show tags") and look at results.
Do the same for menu item of category view.
Check result on article views for above menu items.

andrepereiradasilva · 2016-05-18T23:04:19Z

will this be B/C?

csthomas · 2016-05-19T07:28:42Z

Currently model ContentModelArticle loads tags in view
but ContentModelArticles loads tags in model so there is some inconsistency that should be fixed.

For component content my patch is back compatibility.
I have that changes on production and it works.

For modules that use model ContentModelArticles in general yes.

In short:
In module template will be missing "item->tags" variable
when menu item will have show_tags or show_cat_tags enabled.
I suspect that nobody use that tags when it depends of menu parameters.

Joomla3 built-in modules that use the model are B/C.

When that patch won't be B/C:

If someone created custom template for ex. mod_articles_latest (default.php) and start using tags which depends on menu parameters show_tags then there will be a problem.

andrepereiradasilva · 2016-05-19T07:50:06Z

If someone created custom template for ex. mod_articles_latest (default.php) and start using tags which depends on menu parameters show_tags then there will be a problem.

Gets a Fatal error right?

csthomas · 2016-05-19T07:57:40Z

No, it should get warning or notice that variable in undefined.

csthomas · 2016-05-19T07:58:56Z

@andrepereiradasilva
If you have some example of code I can take a look

andrepereiradasilva · 2016-05-19T08:02:29Z

i don't have an example, i'm just guessing.

i don't know if this ok from a B/C point (it's not my call) but anyhow it would be better if you could prevent that php warning or notice and send a deprecated notice to the deprecated log.

csthomas · 2016-05-19T08:30:56Z

Code from blog_item.php

<?php if ($params->get('show_tags') && !empty($this->item->tags->itemTags)) : ?>

describes that there is no problems with error because function empty check that.

For other unexpected codes I can add empty list of tags for B/C in model/articles.php

// Do not load tags but create empty list for B/C
if ($item->params->get('show_tags', '1') == '1')
{
    $item->tags = new JHelperTags;
    $item->tags->itemTags = [];
}

But I found other bug in my patch

show_cat_tags is not related to article tags but to category (itself) tags.

csthomas · 2016-05-19T10:38:45Z

I have fixed my mentioned bug in the patch.
For do that I have to add a new option to show tags for featured and blog view:
Show only for article view

I also removed default value "1" to be more similar to code from model/articles.php.

About B/C.
Previous similar patch (not mine)
#9038
did not require any deprecated information so I do not think that now it is required. But I may think wrong.

andrepereiradasilva · 2016-05-19T10:39:47Z

as said i'm not the one deciding, was just an idea.

csthomas · 2016-05-19T11:07:47Z

Ok. Thanks for discussion.
If someone can add more advice I listen.

I will be thankful for testing.

Bakual · 2016-05-19T11:30:23Z

You shouldn't need the special case for article view. You can already override the menu settings in the article settings. Which means if the article says to show tags, the tags will be shown even if the category menu item says to hide them. Article settings take precedence over menu settings which take precedence over global settings. There is an exception to that rule, but that doesn't matter in this case 😄

So please remove that added option, it only complicates code and doesn't solve anything.

smz · 2016-05-19T12:16:10Z

Article settings take precedence over menu settings which take precedence over global settings. There is an exception to that rule, but that doesn't matter in this case 😄

Is this a joke, Thomas? The "exception" seems to be the rule here... #9801 (comment)

Bakual · 2016-05-19T12:24:56Z

Is this a joke, Thomas? The "exception" seems to be the rule here

There is only one exception to that rule, and it is if the menu item is specific to the view/id being shown. That is if you have a menu item pointing to article "foo", then the settings from that article "foo" are overriden by the menu item. For the article "bar", the article settings take precedence over the menu item "foo" as usual.
Same for categories. If the menu item is pointing to the category "blubb", then the category options for category "blubb" are overriden by the menu item. But not the options for category "blabla" and not for the articles "foo" and "bar".

Once you figured that out, it's simple and actually makes sense 😄

smz · 2016-05-19T12:30:11Z

Sorry, I don't want to hijack this PR and if you wish we can continue the discussion in #9801, but when you state that

if you have a menu item pointing to article "foo", then the settings from that article "foo" are overriden by the menu item.

That means that menu item options have the precedence over article options, not the other way 'round as you initially stated.

Bakual · 2016-05-19T12:32:59Z

That means that menu item options have the precedence over article options, not the other way 'round as you initially stated.

Yes, in that specific case (menu item is specific to article "foo" and "foo" is displayed) the menu item takes precedence. It's the one exception to the rule. That's what I explained.

smz · 2016-05-19T12:36:03Z

so when the "rule" ("Article settings take precedence over menu settings") does apply?

Bakual · 2016-05-19T12:44:54Z

All other cases as explained.
Of course, if your site is built with menu items for each article, then the menu items always override the article settings as you always have that exception. But that depends on your site structure.

smz · 2016-05-19T12:47:07Z

Got it: "Article settings take precedence over menu settings" apply when there is no corresponding menu item... 😜

csthomas · 2016-05-19T13:10:49Z

Ok
you say about 164 line from model/article.php

                // Convert parameter fields to objects.
                $registry = new Registry;
                $registry->loadString($data->attribs);

                $data->params = clone $this->getState('params');
                $data->params->merge($registry);

But then I have to change show_tags to show for every articles (thousands).

Or I can use weird configuration like:

set up menu item for featured and category view to show_tags=use_article (in article view this will be treats as true)
set up component global parameters show_tags=0
every article set show_tags use global - empty string (this is the default value)

Results:

Then for menu item for category view, show tags will have value "use_article" which is replaced by global
show_tags=0 (because article does not have value) => OK hide tags for category/featured view
For article view joomla get value from menu item show_tags=use_article because article parameter show_tags is not set. => OK show tags for article view

Everything above seems to work so I can agree and remove added option "Show only for article view"

csthomas · 2016-05-19T13:20:23Z

My above comment was to first comment @Bakual

Bakual · 2016-05-19T13:52:03Z

Two things that I noticed from review:

You use params->get('show_tags') to fetch the value, however in most places we use params->get('show_tags', 1) (by default enabled). This seems to be an inconsistency in current code but needs to be addressed to avoid unexpected errors.
You use if ($item->params->get('show_tags') == '1') however that isn't the same as the current check if ($item->params->get('show_tags')), it would fail with the use_article value (which is a stupid value, but that's another topic). Is there a reason you explicitely check for 1 and not just do a boolean check like we do in the other places and did before?

Bakual · 2016-05-19T13:55:11Z

But then I have to change show_tags to show for every articles (thousands).

Yes, as tedious as it may be. Or you could work with template overrides to achieve what you need.
Adding a specific check for a single parameter into core just to please your specific needs is sure the wrong approach.

csthomas · 2016-05-19T17:59:02Z

Current version remove mentioned inconsistency. I had mess with that params now should be ok.

csthomas · 2016-05-23T14:59:03Z

Is there any issue for current version?

mbabker · 2016-05-23T15:09:39Z

Is there any issue for current version?

There's a possible B/C concern in that the article model will now not return tag data at all in com_content (inconsistent with other components which don't even check the value of this parameter) and that anyone using this model would have to manually bind tags data themselves if they are working with it. Then again, considering the terrible implementation of tags in general, at this point I'm inclined to lean toward "who cares?".

csthomas · 2016-05-23T15:59:28Z

Then I think this pull is ready for testing.

brianteeman · 2016-05-24T09:34:21Z

As soon as I see statements such as

I suspect that nobody use that tags when it depends of menu parameters.

and

If someone created custom template for ex. mod_articles_latest (default.php) and start using tags which depends on menu parameters show_tags then there will be a problem.

Then my immediate thought is that we cannot accept this

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10519.}

ggppdk · 2016-07-26T22:42:20Z

If we add a new method to populate then it break B/C.

why it will break B/C ?
the purpose of it would be not to break B/C while at the same time avoid tags being always populated

csthomas · 2016-07-26T22:56:58Z

If I understand you well then you want to do something like:

$item->tags->getItemTags('com_content.article', $item->id); // populate state without loading tags
// then
print_r($item->tags->itemTags); // magic load tags

but there is place where getItemTags method return value directly.
https://github.com/joomla/joomla-cms/blob/staging/templates/beez3/html/com_weblinks/category/default_items.php#L133

ggppdk · 2016-07-26T23:04:58Z

Case 1, using:
getItemTags() load the tags explicitely, no change here

Case 2, some template code assumes, that tags have been loaded, then accessing:
$item->tags->itemTags

would call the magic method and load the tags ??

csthomas · 2016-07-26T23:25:10Z

Something blinded me.
Now I understand, thanks.

csthomas · 2016-07-27T01:44:42Z

Example of magic way:)

Where should we use method setItem? In model or view?

ggppdk · 2016-07-27T07:11:12Z

Where should we use method setItem? In model or view?

Since $item->tags->getItemTags() is currently called in both,

and since the purpose is to replace it with a call to "seItem()" when configuration says not to use tags

I think you can use it at the same places , and don't try to remove it completely from the view ?

Also since the purpose of the "setItem()" is to set an identifier:

typeAlias
itemId

for later retrieval of the tags via magic function __get()

is it a better name instead of setItem(): ?
setItemIdentifier()

csthomas · 2016-07-27T11:08:29Z

I will change method name setItem to setItemIdentifier
tags.php $itemId is OK? or should I use contentItemId?
I will back to 'if ($item->params->get('show_tags', 1))' in views which will contain only setItemIdentifier
If you don't like any code comments or names in PR please correct me.

ggppdk · 2016-07-27T12:29:50Z

tags.php $itemId is OK? or should I use contentItemId?

since in Joomla code "item" means "record" , i think "$itemId" is good enough ?

and it is different from "$Itemid" that reminds of the menu item, right ?

Now about

return (array) $this->itemTags;

since in all PHP versions array typecast of null, is array(),
and since the layout code / overrides , etc that will try to use tags without considering configuration will always expect an array there ?
i think it is good to do it like that

mbabker · 2016-07-27T12:35:21Z

If you're introducing a magic getter then for all intents and purposes you're treating a variable as public. So either use a proper get method or declare the variables public.

Honestly this whole pull request is starting to get a little awkward. What started as looking for a way to stop tags from always being loaded even in contexts where the data was unnecessary is turning into awkward API changes plugged into an already crappy API with tags in general.

What I suggested yesterday with the model state addresses the original concern with what was trying to be accomplished here without the awkward API changes. These are the types of things model state should be used for if not introducing explicit API methods to set behaviors from the outside. To me that was the simplest solution to this issue.

ggppdk · 2016-07-27T12:50:21Z

so you have a solution that will not break B/C and thus can be used today ? and not after 1 or 2 years ?

about magic method it will serve the purpose of not running unneeded and somewhat "performance-unwise" SQL queries
that is one of the purposes of magic __get function to improve performance doing stuff if needed ... why is it bad ?

csthomas · 2016-07-27T13:00:52Z

I broke B/C again to ask you if that is important for article view only.
If fix totally B/C then Joomla 3.7 or J3.6.x:)
I added @deprecated in article view because tagLayout is re-created in template again

mbabker · 2016-07-27T13:37:40Z

so you have a solution that will not break B/C and thus can be used today ? and not after 1 or 2 years ?

Yes. Use the model state as I suggested at #10519 (comment) and you could have a patch merged that is B/C AND allows to opt-out of loading the tags data today.

about magic method it will serve the purpose of not running unneeded and somewhat "performance-unwise" SQL queries
that is one of the purposes of magic __get function to improve performance doing stuff if needed ... why is it bad ?

The patch as is makes two protected properties in all essence public in terms of read access. The $itemId property which has zero manipulation around it whatsoever and $itemTags which does some checks and returns different values. These should be in getItemXXX() methods, magic getters like this aren't giving any benefit over proper API endpoints and even worse can mask errors if you don't implement a proper error handling mechanism for non-existing properties.

I don't see why the new API methods are needed in JHelperTags as they quite frankly aren't adding any real value other than some magic behavior. If you're really insistent on going the new API route, I'm going to insist on properly declared API methods versus magic behaviors.

As is, this patch is NOT backward compatible. The only way to achieve backward compatibility is for the model to continue the existing behavior of default loading the tags data. An API endpoint that in the middle of a major version series stops returning data as part of a method call has introduced a B/C break. This is somewhat confirmed by the fact that this patch requires changes in view classes as a proxy layer for the existing behavior and a need for the magic getter to ensure the data actually loads. A new toggle (i.e. a model state condition) to exclude the tags data, defaulting to the data being loaded to match the existing behavior, is an acceptable backward compatible change because it creates a new API that allows a caller to opt-out of loading the data going forward.

ggppdk · 2016-07-27T13:43:33Z

... A new toggle (i.e. a model state condition) to exclude the tags data, defaulting to the data being loaded to match the existing behavior, is an acceptable backward compatible change because it creates a new API that allows a caller to opt-out of loading the data going forward.

yes , yes

but what about existing sites with template overrides that assume that tags have been loaded, and try to use them without checking configuration ?

ggppdk · 2016-07-27T13:45:34Z

I mean the "model state condition" will have to be left to ON , to retieve tags always regardless of configuration so that the thing remains B/C in all cases

mbabker · 2016-07-27T14:01:23Z

In a module or another extension where you use this model you set the state
value before calling the getItem method. Other modules are already doing
this with other conditions.

So the state value defaults to true but through an explicit change you can
turn it to false without any other implications beyond that data not being
there anymore, which you know because you turned it off.

On Wednesday, July 27, 2016, Georgios Papadakis notifications@github.com
wrote:

I mean the "model state condition" will have to be left to ON , to retieve
tags always regardless of configuration so that the thing remains B/C in
all cases

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10519 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoQlpk0hV8sdfsk8-elc77Ec_ED2tks5qZ2EAgaJpZM4Ifr56
.

mbabker · 2016-07-27T14:05:24Z

The other thing is I don't remember if JObject (which is what the model
state is represented by right now) has a def method similar to the Registry
class. If it does then the model has a simple one line check, $getTags =
$this->getState()->def('load_tags', $item->params->get('tags_condition',
true));

If it doesn't it takes a couple more lines of code (check if value is
defined in state and if not use item param value basically). Either way
it's not all that complex. Similar changes could/should be made to all
models for consistency then.

On Wednesday, July 27, 2016, Georgios Papadakis notifications@github.com
wrote:

... A new toggle (i.e. a model state condition) to exclude the tags data,
defaulting to the data being loaded to match the existing behavior, is an
acceptable backward compatible change because it creates a new API that
allows a caller to opt-out of loading the data going forward.

yes , yes

but what about existing sites with template overrides that assume that
tags have been loaded, and try to use them without checking configuration ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10519 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoRBiWzS0rP89xxG13RfBVoQRi93qks5qZ2CGgaJpZM4Ifr56
.

csthomas · 2016-07-27T14:06:05Z

components/com_content/views/article/view.html.php

+		{
+			$item->tags = new JHelperTags;
+			$item->tags->setItemIdentifier('com_content.article', $item->id);
+		}


@mbabker In above If I replace only name method setItemIdentifier to getItemTags then this break B/C or not?
I do not want to create tags object in show_tags is not enabled.

No. Though it would not affect the com_content views, you're still making
a B/C breaking change in the model. Ultimately that is why I'm making such
a fuss; you can add all the magic behaviors you want to account for that
change elsewhere, but you're still ultimately introducing a breaking change
that has to be accounted for by any consumer of that model.

On Wednesday, July 27, 2016, Tomasz Narloch notifications@github.com
wrote:

In components/com_content/views/article/view.html.php
#10519 (comment):

@@ -152,8 +154,11 @@ public function display($tpl = null)
$item->text = $item->introtext;
}

$item->tags = new JHelperTags;

$item->tags->getItemTags('com_content.article', $this->item->id);

if ($item->params->get('show_tags', 1))

{

$item->tags = new JHelperTags;

$item->tags->setItemIdentifier('com_content.article', $item->id);

}

@mbabker https://github.com/mbabker In above If I replace
setItemIdentifier to getItemTags then this break B/C or not?
I do not want to create tags object in show_tags is not enabled.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/pull/10519/files/ae8a6dd5a07efd29521277ebbc0bc34277a66769#r72445013,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoY8cyl6Ci-G9oyKUgCrscUMZbBSBks5qZ2XOgaJpZM4Ifr56
.

csthomas · 2016-07-27T17:47:42Z

@mbabker about #10519 (comment)

If I go that way then can I change mod_articles_.. and add line like:
$model->setState('load_tags', false); to Joomla core modules.

Do I have to care about custom template that using tags in that modules?
I know that I can do that for my own modules, but what about core mod_articles_...? B/C?

mbabker · 2016-07-27T17:56:05Z

For the core modules you'd probably need to add that as a parameter if it isn't already. I honestly don't know in what case the tags data would get used with latest or related articles but since the functionality's there now you have to assume someone's doing something crazy with it. Then again, at the same time since the modules aren't designed to display associated tags data, you could argue that it's not needed and hardcode it in too. For pure B/C you'd have to do the former; for practical purposes the latter would work. Personally I'd lean toward the latter there because modules have a lot less flexibility and re-use compared to components, but the component models do need to retain some resemblance of B/C since they have re-use potential (i.e. all the articles modules or com_contact's ability to display articles from a user).

csthomas · 2016-07-27T20:26:13Z

Is anyone unhappy with current code?

mbabker · 2016-07-27T21:52:23Z

At a glance it looks fine.

On Wednesday, July 27, 2016, Tomasz Narloch notifications@github.com
wrote:

Is anyone unhappy with current code?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10519 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoW4AVgxBwjJzjfWzVOC0jF8Mh9aaks5qZ77mgaJpZM4Ifr56
.

ghost · 2017-01-08T06:39:34Z

@csthomas is this good for testing?

csthomas · 2017-01-08T17:50:24Z

I have to resolve conflict. Please wait.

csthomas · 2017-01-26T16:11:41Z

I do not have more interest for that PR. I close it.

joomla-cms-bot added the PR-staging label May 16, 2016

csthomas changed the title ~~Use condition show_tags in the view instead of in the model~~ [com_content] Use condition show_tags in the view instead of in the model May 17, 2016

joomla-cms-bot added the Language Change This is for Translators label May 19, 2016

Start using magic __get, __isset

d997e8c

Check show_tags in view, setItem to setItemIdentifier

28d2f8b

Fix inconsistency, little break B/C for article view only

ae8a6dd

csthomas reviewed Jul 27, 2016
View reviewed changes

Instead magic use getState load_tags

12b3404

csthomas closed this Jan 26, 2017

csthomas mentioned this pull request May 26, 2017

[3.7.2] LOTS of duplicate queries #16274

Closed

[com_content] Use condition show_tags in the view instead of in the model #10519

[com_content] Use condition show_tags in the view instead of in the model #10519

Conversation

csthomas commented May 16, 2016 • edited Loading

Summary of Changes

Testing Instructions

andrepereiradasilva commented May 18, 2016

csthomas commented May 19, 2016

andrepereiradasilva commented May 19, 2016

csthomas commented May 19, 2016

csthomas commented May 19, 2016

andrepereiradasilva commented May 19, 2016

csthomas commented May 19, 2016 • edited Loading

csthomas commented May 19, 2016 • edited Loading

andrepereiradasilva commented May 19, 2016

csthomas commented May 19, 2016 • edited Loading

Bakual commented May 19, 2016

smz commented May 19, 2016

Bakual commented May 19, 2016

smz commented May 19, 2016

Bakual commented May 19, 2016

smz commented May 19, 2016

Bakual commented May 19, 2016

smz commented May 19, 2016 • edited Loading

csthomas commented May 19, 2016 • edited Loading

csthomas commented May 19, 2016

Bakual commented May 19, 2016

Bakual commented May 19, 2016

csthomas commented May 19, 2016

csthomas commented May 23, 2016

mbabker commented May 23, 2016

csthomas commented May 23, 2016

brianteeman commented May 24, 2016

ggppdk commented Jul 26, 2016

csthomas commented Jul 26, 2016 • edited Loading

ggppdk commented Jul 26, 2016

csthomas commented Jul 26, 2016

csthomas commented Jul 27, 2016

ggppdk commented Jul 27, 2016 • edited Loading

csthomas commented Jul 27, 2016

ggppdk commented Jul 27, 2016 • edited Loading

mbabker commented Jul 27, 2016

ggppdk commented Jul 27, 2016 • edited Loading

csthomas commented Jul 27, 2016

mbabker commented Jul 27, 2016

ggppdk commented Jul 27, 2016

ggppdk commented Jul 27, 2016

mbabker commented Jul 27, 2016

mbabker commented Jul 27, 2016

csthomas Jul 27, 2016 • edited Loading

Choose a reason for hiding this comment

mbabker Jul 27, 2016

Choose a reason for hiding this comment

csthomas commented Jul 27, 2016

mbabker commented Jul 27, 2016

csthomas commented Jul 27, 2016

mbabker commented Jul 27, 2016

ghost commented Jan 8, 2017

csthomas commented Jan 8, 2017

csthomas commented Jan 26, 2017

csthomas commented May 16, 2016 •

edited

Loading

csthomas commented May 19, 2016 •

edited

Loading

csthomas commented May 19, 2016 •

edited

Loading

csthomas commented May 19, 2016 •

edited

Loading

smz commented May 19, 2016 •

edited

Loading

csthomas commented May 19, 2016 •

edited

Loading

csthomas commented Jul 26, 2016 •

edited

Loading

ggppdk commented Jul 27, 2016 •

edited

Loading

ggppdk commented Jul 27, 2016 •

edited

Loading

ggppdk commented Jul 27, 2016 •

edited

Loading

csthomas Jul 27, 2016 •

edited

Loading