使用 CodeIgniter 分页时丢失 URI 段
我有一个 / payment 界面，用户应该能够通过价格范围、银行和其他内容进行过滤。这些过滤器是标准选择框。当我提交过滤器表单时，所有发布数据都会转到另一种称为付款/搜索的方法。该方法执行验证，将发布值保存到会话 flashdata 中，并通过 URL 传递 flashdata 名称将用户重定向回 / payment 。
所以我的没有过滤器的标准分页链接完全像这样：
payments/index/20/
payments/index/40/
payments/index/60/
如果您提交过滤器表单，则返回的 URL 是：
payments/index/0/b48c7cbd5489129a337b0a24f830fd93
这非常有效。如果我将零更改为其他内容，它就可以很好地分页。然而，唯一的问题是<< 1 2 3 4>>页面链接不会保留分页偏移量之后的哈希值。 CodeIgniter 正在生成页面链接，忽略该附加 uri 段。
我的 uri_segment 配置已设置为 3：
$config['uri_segment'] = 3;
我无法将 uri_segment 设置为 4，因为该哈希可能存在也可能不存在。我该如何解决这个问题有什么想法吗？ CI 是否必须将偏移量作为 uri 中的最后一段？也许我正在尝试不正确的方法，所以我洗耳恭听。
谢谢你们。
编辑：您可能会问，为什么我要通过 uri 传递 flashdata 名称？因为它允许用户打开多个浏览器选项卡并在每个选项卡中执行不同的搜索。对于您执行的每个过滤，都会生成一个新的 flashdata var。
I have a /payments interface where the user should be able to filter via price range, bank, and other stuff. Those filters are standard select boxes. When I submit the filter form, all the post data goes to another method called payments/search. That method performs the validation, saves the post values into a session flashdata and redirects the user back to /payments passing the flashdata name via URL.
So my standard pagination links with no filters are exactly like this:
payments/index/20/
payments/index/40/
payments/index/60/
And if you submit the filter form, the returning URL is:
payments/index/0/b48c7cbd5489129a337b0a24f830fd93
This works just great. If I change the zero for something else, it paginates just fine. The only issue however is that the << 1 2 3 4 >> page links wont keep the hash after the pagination offset. CodeIgniter is generating the page links ignoring that additional uri segment.
My uri_segment config is already set to 3:
$config['uri_segment'] = 3;
I cannot set uri_segment to 4 because that hash may or may not exists. Any ideas of how can I solve this? Is it mandatory for CI to have the offset as the last segment in the uri? Maybe I am trying an incorrect approach, so I am all ears.
Thank you folks.
edit: Why am I passing the flashdata name via uri you might ask? because it allows the user to open several browser tabs and do different searches in each tab. For each filtering you do, a new flashdata var is generated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于来自 Google 的用户，这里是解决方案：
在分页配置数组中，我为此更改了我的 base_url：
其中，segment(3) 是我的偏移量，segment(4) 是哈希值。因此，在这种情况下，哈希可能存在也可能不存在，并且分页仍然有效。
另一种方法可能是这样的：如果您转到支付，并且 URL 中没有 flashdata ID，它会将用户重定向到支付/搜索，并创建一个带有空过滤器的空数组。然后它重定向回 Payments/_NEW_FLASHDATA_ID_HERE_。这样，URL 中将始终具有 flashdata ID，并且您可以像往常一样在最后一个 URI 段中拥有分页偏移量。
Just for users coming from Google, here is the solution:
In the pagination config array, I changed my base_url for this:
Where segment(3) is my offset number and segment(4) is the hash. So, in this case, the hash may or may not exists and the pagination will still work.
Another approach could be this: If you go to payments, and there is no flashdata ID in the URL, it redirects the user to payments/search and create an empty array with empty filters. Then it redirects back to payments/_NEW_FLASHDATA_ID_HERE_. This way, the URL will always have a flashdata ID in the URL and you can have the pagination offset in the last URI segment as usual.
为什么不将哈希设置为会话项？
然后，哈希值将可用，直到您取消设置它
或直到您销毁会话为止。
Why not set the hash as a session item?
The hash will then be available until you unset it
Or until you destroy the session.
为什么不检查哈希是否存在并根据该哈希值设置
uri_segment？Why aren't you checking to see if the hash exists and set the
uri_segmentbased on that?