New one-year, hard-coded limit to blocks in 4.4.2

[Gabriel Torres]

Hello,

One of the new features of 4.2.2 is a new hard-coded, one-year limit to blocks in the Pages application. I understand this was done to improve performance, as limiting the amount of data you pull from the database server improves performance.

The side effect of this new limitation is that our blocks now don't show all the information we need.

For example, we have a block that lists our most popular articles, and with 4.4.2, this block only shows the most popular articles posted in the past 365 days instead of all times.

Another example, we have a block that lists our products, and with 4.4.2 this block only shows the products released in the past 365 days instead of all products.

My suggestion is to respect the "past year" checkbox that is available when configuring blocks, as now this checkbox is simply ignored. This way I believe you could help users like me who want all data, and users who don't need all data and can limit the scope of the queries to improve performance.

I know you probably won't implement that, but I thought it would be interesting to open a topic about this, to see if other website owners have the same needs as us here.

Thanks! :)

Gabriel.

[Adlago]

37 minutes ago, Gabriel Torres said:

I know you probably won't implement that, but I thought it would be interesting to open a topic about this, to see if other website owners have the same needs as us here.

This topic is about the same problem

 

[Adlago]

PS. I have written enough about this topic. From almost 24 hours I'm waiting for a solution to this issue in my ticket. Apart from an unreasonably fruitless visit by a staff member, nothing else is done on my ticket. I am considering backing back to 4.4.1 because all this change for blocks is causing me business damages that I will pay for, even though the perpetrators hide and remain silent here.

[bfarber]

We're not online on the forums 24/7 unfortunately, so we can respond to every topic and immediately. Additionally, the change is not a "bug" and as such it's not something that can be immediately addressed through a ticket.

Having said that, this change is being revisited and reviewed internally.

[Fast Lane!]

Wow what a mess. This will break all types of things for me as well. I'll hold off upgrading for a while. 

[sudo]

26 minutes ago, Adlago said:

PS. I have written enough about this topic. From almost 24 hours I'm waiting for a solution to this issue in my ticket. Apart from an unreasonably fruitless visit by a staff member, nothing else is done on my ticket. I am considering backing back to 4.4.1 because all this change for blocks is causing me business damages that I will pay for, even though the perpetrators hide and remain silent here.

Its not too hard to hack out the change tbh based on the code changes I have seen. Just remove a part of a line on 327 of system/Content/Widget.php and it should work as before although that is never ideal it would get you going again given the urgency for you. I would tell you specifically what to edit but I dont want to post code here. I know IPB dont recommend edits but it shouldnt be a big deal either.

 

For me simply having the limit to a year checkbox pre-ticked with a warning on that widget page that says going over 365 days can cause performance issues would be enough, allow the admin to decide whats needed.

[Adlago]

11 minutes ago, sudo said:

Its not too hard to hack out the change tbh based on the code changes I have seen. Just remove a part of a line on 327 of system/Content/Widget.php

A change from 365 to 1800 solves my problem.
Thank you so much.

[sudo]

1 minute ago, Adlago said:

A change from 365 to 1800 solves my problem.
Thank you so much.

Just a pointer, I have a local git repo I drop the updated source code into each time a new release comes out via gitkraken and it makes seeing the code changes a lot simpler.

[Fast Lane!]

There should just be a selection to have unlimited (enter 0 days) or a cap (enter days). Default can be 365 days. 

[Gabriel Torres]

3 hours ago, Adlago said:

PS. I have written enough about this topic. From almost 24 hours I'm waiting for a solution to this issue in my ticket. Apart from an unreasonably fruitless visit by a staff member, nothing else is done on my ticket. I am considering backing back to 4.4.1 because all this change for blocks is causing me business damages that I will pay for, even though the perpetrators hide and remain silent here.

Here it is how I fixed this:

\system\Content\Widget.php

/* Limit to days */
		if ( isset( $this->configuration['widget_feed_restrict_days'] ) and $this->configuration['widget_feed_restrict_days'] > 0 and $this->configuration['widget_feed_restrict_days'] <= 365 )
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P' . $this->configuration['widget_feed_restrict_days'] . 'D' ) )->getTimestamp() );
		}
		else
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P1Y' ) )->getTimestamp() );
		}

Simply remove the "else" statement:

/* Limit to days */
		if ( isset( $this->configuration['widget_feed_restrict_days'] ) and $this->configuration['widget_feed_restrict_days'] > 0 and $this->configuration['widget_feed_restrict_days'] <= 365 )
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P' . $this->configuration['widget_feed_restrict_days'] . 'D' ) )->getTimestamp() );
		}

 

[sudo]

46 minutes ago, Gabriel Torres said:

Here it is how I fixed this:

\system\Content\Widget.php

/* Limit to days */
		if ( isset( $this->configuration['widget_feed_restrict_days'] ) and $this->configuration['widget_feed_restrict_days'] > 0 and $this->configuration['widget_feed_restrict_days'] <= 365 )
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P' . $this->configuration['widget_feed_restrict_days'] . 'D' ) )->getTimestamp() );
		}
		else
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P1Y' ) )->getTimestamp() );
		}

Simply remove the "else" statement:

/* Limit to days */
		if ( isset( $this->configuration['widget_feed_restrict_days'] ) and $this->configuration['widget_feed_restrict_days'] > 0 and $this->configuration['widget_feed_restrict_days'] <= 365 )
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P' . $this->configuration['widget_feed_restrict_days'] . 'D' ) )->getTimestamp() );
		}

 

Just remove:

and $this->configuration['widget_feed_restrict_days'] <= 365

That way when no days are specified the limit is 365 but otherwise it will go longer if specified longer.

[SoloInter]

 

[Koper74]

And I thought I was the only one with this problem. 

After a rather not-so-positive response to my support request, I manually changed the date of ~250 records yesterday - it is a shame I did not wait and have a look here first...

[SoloInter]

I wrote to the support yesterday, we exchanged more than 20 messages where he asks me to disable the cache, to put the language by default, the default theme, to do different manipulation to ultimately say "pay attention at the limit of one year ".

What a waste of time and energy for that. Change an item like this without warning, not be able to identify the problem because even at IPS it is not obviously obvious.

Result, since this update, the number of messages is in free fall, the topics are no longer commented, it's really a change that smells faeces. I'm so angry.

[SoloInter]

New answer from the staff : 

Quote

Hello,

As mentioned, this is something in which is being discussed internally at present. I am however a little confused by your specific concern there. Its order by recently updated, so it would be only items which have been recently updated in the last year, not items created in the last year.

 

But no, it's the date of creation that prevails and not the date of update.

[Koper74]

2 minutes ago, Archimed said:

But no, it's the date of creation that prevails and not the date of update.

exactly

[Sergey_SV]

Seems that IPS is taking  the hardcoding limits to the next level, first it was the search in PM which is hardcoded to be limited to 1 year, now this. What next?....

[Adlago]

I think such hardcore IPS limits can only apply to this own site.
When this platform is used by many thousands of customers, any limitation should only be managed by a site owner / administrator.
Any other justification is discrimination and irrationality.

[BobSperanza]

15 hours ago, Gabriel Torres said:

Here it is how I fixed this:

\system\Content\Widget.php

/* Limit to days */
		if ( isset( $this->configuration['widget_feed_restrict_days'] ) and $this->configuration['widget_feed_restrict_days'] > 0 and $this->configuration['widget_feed_restrict_days'] <= 365 )
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P' . $this->configuration['widget_feed_restrict_days'] . 'D' ) )->getTimestamp() );
		}
		else
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P1Y' ) )->getTimestamp() );
		}

Simply remove the "else" statement:

/* Limit to days */
		if ( isset( $this->configuration['widget_feed_restrict_days'] ) and $this->configuration['widget_feed_restrict_days'] > 0 and $this->configuration['widget_feed_restrict_days'] <= 365 )
		{
			$where[] = array(  $class::$databaseTable . '.' . $class::$databasePrefix . $class::$databaseColumnMap['date'] . '>?',  \IPS\DateTime::create()->sub( new \DateInterval( 'P' . $this->configuration['widget_feed_restrict_days'] . 'D' ) )->getTimestamp() );
		}

 

 

Thank you for this! I hope this is not having any side effects.

 

Honestly, this is really the worst feature they could have added. We all have threads opened more than one year ago and still active today, or do they think we all have forums with threads active just for a few days ? 🧐 Hopefully this will be fixed in the next release.

 

[SoloInter]

New answer from the Staff :

 

Quote

I have just spoken to my colleague, and we will be releasing a patch for this issue at some point later today.

Youhouuu :)

[Kjell Iver Johansen]

7 minutes ago, Archimed said:

New answer from the Staff :

 

Youhouuu :)

Ohh.. no! The big red banner again!

[Gabriel Torres]

Hi guys!

I can confirm that the new patch available as of today solves the issue. Simply click on "Support" inside the ACP to apply it!

Many thanks for everybody who joined my topic showing that the problem was not just with me here.

Cheers!