[com_content] articles view (modal) - Implement searchtools

[andrepereiradasilva]

Summary of Changes

This PR adds JLayout searchtools to com_content articles modal view.
Also adds the status column, moves the category to below the article title and makes some minor visual changes to be more synchronized with the non modal view.

Before PR

After PR

Testing Instructions

1. Use latest staging
2. In the backend edit any article and press "+Article" button on the editor, how will see a modal window with the old filter. Note: you can also create a "Single article" menu item type and select the article there.
3. Apply this patch
4. Repeat 2. and you'll see the new searchtools
5. Now test search, ordering, filter, etc. Also select an article. In other words, test if everything works fine.

That i know of, correct me if i'm wrong, this view is used in:

1. "+Article" button in any editor (frontend and backend) -> all articles
2. Menu item "Single Article", "Select" button -> all articles
3. When language associations are enabled. Article "Associations" tab -> articles filtered by language

All this views should be tested.

Observations

That i know of, this is the first searchtools implemented on a modal view, so suggestions and improvements are welcomed.

[RonakParmar]

@andrepereiradasilva Thanks for the patch.
I have applied this path and works fine for me.
Here is my system information:

Joomla! Version: Joomla! 3.4.8 Stable [ Ember ] 24-December-2015 19:30 GMT
Joomla! Platform Version: Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
PHP Version: 5.4.45-3+deb.sury.orgprecise+1
System Linux desktop 3.5.0-54-generic #81precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64

---

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

[RonakParmar]

I have tested this item ✅ successfully on b81e103

---

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

[infograf768]

I have tested this item 🔴 unsuccessfully on b81e103

Multilingual sites: This PR breaks forcedLanguage when articles associations are set as one can choose another language than the language it should be associated to. In that case the Select Language should not be proposed.

---

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

[andrepereiradasilva]

@infograf768 could you describe the steps you made to test so i can try to resolve the uissue you're referring?

[infograf768]

Multilingual site:
Edit an article in one language, go to associations tab
"Select" an article for a specific language: the modal opens.
Remark that only the articles tagged to this specific language are displayed and one CANNOT change language to display articles not tagged to the said lang.

I click on the Select button for Italian:

The code to NOT display the language dropdown depends on the filter.forcedLanguage setting.

[andrepereiradasilva]

ok, i see will check that later. thanks

That i know of, correct me if i'm wrong, this view is used in:

1. "+Article" button in any editor (frontend and backend) -> all articles
2. Menu item "Single Article", "Select" button -> all articles
3. When language associations are enabled. Article "Associations" tab -> articles filtered by language

[infograf768]

Yep.

[joomla-cms-bot]

This PR has received new commits.

CC: @infograf768, @RonakParmar

---

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

[joomla-cms-bot]

This PR has received new commits.

CC: @infograf768, @RonakParmar

---

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

[joomla-cms-bot]

This PR has received new commits.

CC: @infograf768, @RonakParmar

---

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

[andrepereiradasilva]

@infograf768 made some changes that i think resolves the issue you described.

The idea would be we could use this PR to replicate, in other words, with the necessary adaptations, implement searchtools on other modal views.

So IMHO this should be tested with time and with all possible scenarios (functionality in all views where it's used, B/C, security, etc).

[joomla-cms-bot]

This PR has received new commits.

CC: @infograf768, @RonakParmar

---

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

[infograf768]

This works great.

Comments:
I see no reason to take off filtering by Author or Tags or MAx Levels.

Is it also possible to reset the category field (i.e. in fact Clear) when Selecting an article for another language? Otherwise one has to clear each time when choosing an association for a different language.

Note: I had tested here another solution where searchtools filters were customised. But I had to specifically introduce the variable in filters.php
In fact, I think we should improve SearchTools by letting display or not specific fields, a bit similar to what is done for layout edit params.php
See https://github.com/joomla/joomla-cms/blob/staging/layouts/joomla/edit/params.php#L21-L23

[andrepereiradasilva]

Comments: I see no reason to take off filtering by Author or Tags or MAx Levels.

ok, will show them.

Is it also possible to reset the category field (i.e. in fact Clear) when Selecting an article for another language? Otherwise one has to clear each time when choosing an association for a different language.

ok. i see. if we use "+article" modal and them the language associations modal it populates the filter with previous selected filter. i think each forced language needs a exclusive state context.

Note: I had tested here another solution where searchtools filters were customised. But I had to specifically introduce the variable in filters.php
In fact, I think we should improve SearchTools by letting display or not specific fields, a bit similar to what is done for layout edit params.php
See https://github.com/joomla/joomla-cms/blob/staging/layouts/joomla/edit/params.php#L21-L23

Yes, i also see some changes that searchtools could be simplified (ex: not adding layout overrides just because of the client selector) and also add some more flexibility, but that if for a future PR IMHO.

[joomla-cms-bot]

This PR has received new commits.

CC: @infograf768, @RonakParmar

---

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

[joomla-cms-bot]

This PR has received new commits.

CC: @infograf768, @RonakParmar

---

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

[andrepereiradasilva]

@infograf768 can you check now?

BTW one thing i noticed: in the frontend edit, the status icons don't have colors.

"+Article" editor button in Frontend

"+Article" editor button in Backend

Update:
The difference is:

• Backend: https://github.com/joomla/joomla-cms/blob/staging/administrator/templates/isis/less/icomoon.less#L12-L36
• Frontend: https://github.com/joomla/joomla-cms/blob/staging/templates/protostar/less/icomoon.less

i can update the protostar less, but will it have any influence in other things? Can it be changed safely?

[infograf768]

This now works fine for me.
I would not touch at icomoon.less as you can see that protostar is never using coloured icons.
If you were, we would also have to change icon-cancel and possibly icon-save, etc.

[andrepereiradasilva]

ok sure.

[infograf768]

I have tested this item ✅ successfully on 936494c

This works fine

remains to do Contacts and Newsfeeds (It looks like this last one has issues with forcedlanguage)

---

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

[andrepereiradasilva]

com_contact: #9198
com_newsfeeds: #9206
com_categories: #9208

and there are other modal layout lists that i think should follow the same logic: users and modules

A list of list views modal.php files:

Core:
/administrator/components/com_content/views/articles/tmpl/modal.php
/administrator/components/com_newsfeeds/views/newsfeeds/tmpl/modal.php
/administrator/components/com_categories/views/categories/tmpl/modal.php
/administrator/components/com_modules/views/modules/tmpl/modal.php
/administrator/components/com_modules/views/positions/tmpl/modal.php
/administrator/components/com_users/views/users/tmpl/modal.php
/administrator/components/com_contact/views/contacts/tmpl/modal.php

Hathor overrides:
/administrator/templates/hathor/html/com_newsfeeds/newsfeeds/modal.php
/administrator/templates/hathor/html/com_modules/positions/modal.php
/administrator/templates/hathor/html/com_users/users/modal.php
/administrator/templates/hathor/html/com_contact/contacts/modal.php

[infograf768]

As this series of patches contain the same change to the category field type, I suggest, before going further to get a milestone from maintainers.
@wilsonge ?

[joomlacorner]

This works fine.

---

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

[joomlacorner]

I have tested this item ✅ successfully on 936494c

This works fine

---

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

[brianteeman]

RTC

---

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