Hiding posts on page 15 should redirect back to page 15

[TSP]

When hiding a single post (from the Options menu on the post) you are taken back to the page you where on. This is good and works as expected. 

However, when using the multi-select tool and choosing to hide from the moderator toolbox overlay, then you are taken back to the first page. You should be left on the page you were on. 

[Sonya*]

The same issue has been reported by my moderators.

[Joey_M]

I've got two hidden posts which I cannot locate or delete, I've only found them in a third-party app.

If I click on them it says they cannot be found.

[Marcher Technologies]

1 hour ago, Joey_M said:

I've got two hidden posts which I cannot locate or delete, I've only found them in a third-party app.

If I click on them it says they cannot be found.

Unrelated to the original post, should probably submit a ticket so staff can take a look at your database and see if it's something that needs fixed in the codebase.

4 hours ago, TSP said:

When hiding a single post (from the Options menu on the post) you are taken back to the page you where on. This is good and works as expected. 

However, when using the multi-select tool and choosing to hide from the moderator toolbox overlay, then you are taken back to the first page. You should be left on the page you were on. 

Please note, I am NOT arguing against this. That tool allows one to select posts across pages of a topic. Please define what it should do if you select a post on page 1, 5, 10, and 15 to delete while viewing page 20, which no longer exists as of deleting those posts.

This is the kind of thing that the code has to account for in honoring this request.

[TSP]

2 hours ago, Marcher Technologies said:

Please note, I am NOT arguing against this. That tool allows one to select posts across pages of a topic. Please define what it should do if you select a post on page 1, 5, 10, and 15 to delete while viewing page 20, which no longer exists as of deleting those posts.

This is the kind of thing that the code has to account for in honoring this request.

If they are hiding posts and the moderator can see hidden posts then it will be the same. Otherwise I think it should redirect to the page that contains the first visible post after the post that was last hidden.

[Matt]

Original suggestion is sensible. I'll make a note.

[Sonya*]

On 6/7/2019 at 6:37 PM, Marcher Technologies said:

Please note, I am NOT arguing against this. That tool allows one to select posts across pages of a topic. Please define what it should do if you select a post on page 1, 5, 10, and 15 to delete while viewing page 20, which no longer exists as of deleting those posts.

This is the kind of thing that the code has to account for in honoring this request.

I have no clue what was defined in previous versions. But our moderators really miss the feature after upgrade. It was there and now it is gone. It worth to see how it has worked in previous versions.

[newbie LAC]

On 6/12/2019 at 1:02 PM, Sonya* said:

But our moderators really miss the feature after upgrade. It was there and now it is gone. It worth to see how it has worked in previous versions.

Related to https://invisioncommunity.com/news/product-updates/44-seo-improvements-r1116/

Quote

Pagination
The most visible change is that we've taken pagination out of query strings and placed it in the path.

For example, the current pagination system looks a little like:
yoursite.com/community/forums/123-forum/?page=3

Which is fine but it gets a little confusing when you add in a bunch of sort filters like so:
yoursite.com/community/forums/123-forum/?sort=asc&field=topic&page=3

A better approach would be to make a clear signal to both Google and humans that pagination is a separate thing.

Invision Community 4.4 does this:
yoursite.com/community/forums/123-forum/page/3/?sort=asc&field=topic

Before pagination changes

ips.utils.url.getParam('page')

return page number

Now that code return undefined

But correct function is getPageNumber

		/**
		 * Returns the page number from the URL
		 *
		 * @param 	{string} 	name 	Parameter to return
		 * @param 	{string} 	[url] 	Url to parse (uses current url if none specified)
		 * @returns {string}
		 */
		getPageNumber = function (param, url) {

 

ips.utils.url.getPageNumber( 'page' )

 

[Daniel F]

The redirect issue was fixed recently (but I don't think that it made it into 4.4.7).

If you're on page 5 and you're deleting something via multimod, it will redirect you to page 5 IF it still exists once the posts were deleted or back to page once if that many posts were deleted that page4 is the last one.

[Martin A.]

On 9/24/2019 at 10:30 AM, Daniel F said:

The redirect issue was fixed recently (but I don't think that it made it into 4.4.7).

If you're on page 5 and you're deleting something via multimod, it will redirect you to page 5 IF it still exists once the posts were deleted or back to page once if that many posts were deleted that page4 is the last one.

As far as I can see, it does not. I see that the code in Content\Controller is looking for the "page" param, but that does not exist in the request. In the JS (ips.ui.pageAction.js) you're trying to get this using "ips.utils.url.getParam( 'page' )", but since you've changed the page param to "/page/X" that function is not able to find it. But there is one named "ips.utils.url.getPageNumber" that you should use instead. 

An alternative fallback would be to look at the pagination element.

$( 'ul[data-ipspagination] li.ipsPagination_active a' ).data( 'page' );