I have tested this item 🔴 unsuccessfully on 6ade43a

With and -out PR all featured Articles are shown if using index.php?option=com_content&view=featured&date_filtering=relative&relative_date=1

It's very strange. If I use index.php?option=com_content&view=featured&date_filtering=relative&relative_date=2 without PR I have

SELECT DISTINCT a.id, a.title, a.alias, a.introtext, a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, 
  CASE WHEN c.published = 2 
  AND a.state > 0 THEN 2 WHEN c.published != 1 THEN 0 ELSE a.state END as state,
  CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,
  CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.language,  LENGTH(a.fulltext) AS readmore, a.ordering,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,c.published, c.published AS parents_published, c.lft,
  CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias

  FROM k3mhz_content AS a

  LEFT JOIN k3mhz_categories AS c 
  ON c.id = a.catid

  LEFT JOIN k3mhz_users AS ua 
  ON ua.id = a.created_by

  LEFT JOIN k3mhz_users AS uam 
  ON uam.id = a.modified_by

  LEFT JOIN k3mhz_categories as parent 
  ON parent.id = c.parent_id

  WHERE a.featured = 1 
  AND a.access IN (1,1,5) 
  AND c.access IN (1,1,5) 
  AND c.published = 1 
  AND a.state = 1 
  AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2017-10-10 08:00:42') 
  AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2017-10-10 08:00:42') 

  ORDER BY c.lft,  
  CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END  DESC , a.created DESC  
  LIMIT 9

With PR I have

SELECT DISTINCT a.id, a.title, a.alias, a.introtext, a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, 
  CASE WHEN c.published = 2 
  AND a.state > 0 THEN 2 WHEN c.published != 1 THEN 0 ELSE a.state END as state,
  CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,
  CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.language,  LENGTH(a.fulltext) AS readmore, a.ordering,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,c.published, c.published AS parents_published, c.lft,
  CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias

  FROM k3mhz_content AS a

  LEFT JOIN k3mhz_categories AS c 
  ON c.id = a.catid

  LEFT JOIN k3mhz_users AS ua 
  ON ua.id = a.created_by

  LEFT JOIN k3mhz_users AS uam 
  ON uam.id = a.modified_by

  LEFT JOIN k3mhz_categories as parent 
  ON parent.id = c.parent_id

  WHERE a.featured = 1 
  AND a.access IN (1,1,5) 
  AND c.access IN (1,1,5) 
  AND c.published = 1 
  AND a.state = 1 
  AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2017-10-10 08:00:42') 
  AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2017-10-10 08:00:42') 
  AND a.created >= DATE_SUB('2017-10-10 08:00:42', INTERVAL 2 DAY)

  ORDER BY c.lft,  
  CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END  DESC , a.created DESC  
  LIMIT 9

The PR adds the where clause a.created >= DATE_SUB('2017-10-10 08:00:42', INTERVAL 2 DAY)

I have tested this item ✅ successfully on 6ade43a

I have tested this. Without, patch I got that all articles are displayed. But, with patch applied Only articles created in the last 24 hours are displayed if using index.php?option=com_content&view=featured&date_filtering=relative&relative_date=1.

But, for this index.php?option=com_content&view=featured&date_filtering=range&start_date_range=(url_ecoded yesterday sql format)

it's not working. With and -out PR all featured Articles are shown .

@eshiol can you please inform where to test as i had test on Backend.

Should not this be designed as in #18248 ?
using $this->getUserStateFromRequest()?

sorry for the silly question,
but how do you set that options from backend ?

What I understand now, this is designed for (manage from) front-end, not back-end.
Visitors can create URLs like ...&date_field=modified&.... and slow down whole website, administrator won't manage this directly from menu.

IIRC relative filters does not work in postgreSQL.

A little similar is in filter_tag, visitor can set own tag to filter but administrator can predefine some tags in menu item.

yes, but how a normal user can set these parameters if not from backend ?

how to go on with this PR?

Despite it may work as author described, for me this is a wrong direction.

Crawlers, bots should not have ability to explore joomla website by sending requests like:

• index.php?option=com_content&view=featured&date_filtering=relative&relative_date=1
• index.php?option=com_content&view=category&id=1&date_field=modified&relative_date=1
• index.php?option=com_content&view=featured&date_filtering=range&start_date_range=...

This functionality should be only available in menu items and modules (they can use $model->setState())

At now (before this PR) as the filtering dates does not work IMO this functionality may be limited to only modules and menu items.

This PR will be closed at 26th November 2017 if there is no other Decision in the Meantime.

filters should be set from the backend, I don't think this is the way to go

Status is set on "Needs Review".

I have tested this item ✅ successfully on 6ade43a

Closed a maintainer has already said this it not a good idea