Language Change PR-staging


User tests: Successful: Unsuccessful:

avatar GeraintEdwards
15 Mar 2017

The custom fields plugin is a welcome addition to Joomla but its usefulness is limited by a lack of configurability.

For instance you can't configure custom fields in com_content, for instance, within the single article view and not in the featured article view.

This PR adds a new config option to config.xml for com_content to allow the site admin user to choose the contexts where they may wish the fields to be available or displayed. The mechanism can easily be extended to other components using the fields plugin.

Summary of Changes

Summary of Changes

  1. Adds config option to com_content to allow user to select where custom fields should be displayed
  2. Adds com_content helper to use this config option
  3. Adds required language strings 

Testing Instructions

Open com_content config and on Integrations tab select 'Featured articles view' as one of the output contexts for custom fields and disable 'Single article view'.

Expected result

Featured articles page will now show custom fields but the article detail view will not.

Similar changes can be added to other components that use custom fields.

avatar GeraintEdwards GeraintEdwards - open - 15 Mar 2017
avatar GeraintEdwards GeraintEdwards - change - 15 Mar 2017
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 15 Mar 2017
Category Administration com_content Language & Strings
avatar mbabker
mbabker - comment - 15 Mar 2017

Honestly, I don't think a component level parameter is going to be good enough. If fields were supported in non-HTML output, I have a use case where we could use fields for the security announcement category on but not enable fields for any other content. As is, I would have to have fields enabled for all category and article contexts (granted it's still an improvement that there are a couple of (in this site's case unused) contexts it could be disabled in, but for this to really be beneficial it's going to have to get "smarter" over time.

avatar GeraintEdwards GeraintEdwards - change - 15 Mar 2017
Labels Added: Language Change PR-staging
avatar GeraintEdwards
GeraintEdwards - comment - 15 Mar 2017

I'm guessing that is a 'Category blog' view limited to a specific category? If so then you would want the context to be set within the category too. Then the validateSection method could check the category of the item (using a static instance type field to cache the results) to see if the fields should be output.

Are you using a custom component for the announcements with a different context? I was working on the contexts available in com_content - I did a search for "onContentPrepare" in the core codebase and that is all I found.

I guess we could set the context parameter field to be one where custom additional contexts could be added like the module position field when editing a module. May not be very intuitive to normal users though.

avatar mbabker
mbabker - comment - 15 Mar 2017

Except for the JoomlaCode issue archive, everything on that site is core (com_content and modules).

On the backend we can set it up just fine. For the frontend though, because the events aren't triggered outside HTML views (not related to this PR but a general issue with the implementation; it's a roadblock for our use case because of the RSS feed) and because the events will run in full for a view context without being able to filter to a lower level (enable for X category and disable for Y) it makes setting that up for us less appealing.

At work we're doing an upgrade and integrating fields into our site and this current setup (all or nothing) is causing a performance hit. The expanded context checking would help with that.

avatar GeraintEdwards
GeraintEdwards - comment - 15 Mar 2017

Once #14558 is merged I was planning on a new PR that would fetch the fields in one go from the getList method of the mode. It seems rather pointless to me to generate a complex query to fetch the item ids a second time before getting the field data - why not simply pass the list of ids into a method to fetch the custom fields in one go.

This would require a new plugin hook, e.g. onGetListData (or similar) in the getItems method of the model to be called after the data base been obtained and passing in a reference to the $items and the key variable. The custom field data would be fetched in a radically simplified means and would be available to your non HTML views (as long as they use the core component model).

That would then leave the need to control the data fetch based on context and/or category, though it would be a fairly simple single query to fetch the data and so would only have limited impact on performance if the custom field data was not needed by the output.

Add a Comment

Login with GitHub to post a comment