[Resolved] using the latest version of wp-Views plugin issue with add_rewrite_rule()

[Author]

Posts

[lenas]

Restarting an old ticket:

When using the latest version of Toolset Views plugin, I am experiencing an issue with the add_rewrite_rule() function not redirecting with all the parameters. In Toolset Views plugin version Version 2.3.0 , this is not an issue.
Ex: add_rewrite_rule( '^our-products/banquet-tables/?', 'index.php?pagename=our-products&wpv-tables=banquet&wpv-product_cat=tables', 'top' );

The second parameter is not being passed.

Currently i have tried adding it both in the custom code section of toolset (as previously advised) and it's still in functions.php file.

An easy way to check whether the second parameter was passed is to see if Banquet is selected in the left rail product filter.

Thank you!!

[Beda]

Can you link me to the older thread?

add_rewrite_rule() is a WordPress core method used for altering the URL under which you reach certain posts or pages or other content on the site.
Clasically you'd edit that in the Post types settings in Toolset > Post Types under the rewrite rules, but those are not dynamic as that function seems to allow.

So I understand, you use it to catch ^our-products/banquet-tables/?, but that Regex to me looks broken.
It has pattern errors, and should never have worked.
^ asserts position at start of a line
then all good with the first sting our-products, but
/ is not escaped, and hence should be escaped, because an unescaped delimiter must be escaped wit ha backlash (\/)
again all good with the next string banquet-table, but
/ is again not escaped, and when closing with
?, the preceding token will not be quantifiable.

So it seems the required $regex is not working and hence the function you use cannot work.
Can I ask if the same works with Non Toolset content?
It shouldn't, according the analysis of the regex.
I think something like below is correct:

^our-products\/banquet-tables\/?

Now, if we where to use that in our function we should be able to match the our-products/banquet-tables/ url only if it precisely starts with our-products/banquet-tables/ and is followed by anything.

However the WP Codex says the function should match the regex against the requested URL - which is not stated where that URL comes from, and in the example they make it actually is suggesting to come from $redirect, see the example here https://codex.wordpress.org/Rewrite_API/add_rewrite_rule
That's certainly wrong, that cannot be the case, it would be a infinite loop of rewriting and make poor sense.

Hence, something is not mentioned in the Codex I assume, and I think to understand it properly that $regex will match the current URL and rewrite to $rewrite.

However, even using the exact example setup of WordPress Codex, it will not rewrite anything in a vanilla WordPress install, I tested this locally without Toolset.

Could you help me creating a minimal (and justified by purpose of usage) example where I can test this before and after the update of Views?
Of course, if Toolset broke the behavior we will need to fix it, however right now, it seems to me this is not working without Toolset either.

Please let me know what I miss so I can adjust my approach and help you adequately.

Thanks!

[lenas]

Hi, here is the old thread: https://toolset.com/forums/topic/when-using-the-latest-version-of-wp-views-plugin-issue-with-add_rewrite_rule/

The rewrite rule was working perfectly on Toolset Views 2.3.0, please feel free to revert back to this version and you should see it working.

I don't believe we have another similar redirect that is not using Toolset and i can't think of one I can create to test as products is our only parameter driven data and it's all on toolset.

thank you!

[Beda]

As mentioned in the previous reply, I have tested the function without even using Toolset, and I am sure it does not work like instructed on the Codex.
The instruction from the Core Codex is unclear, it seems that doc is either wrong, out of date, or incomplete, fact is, the function does nothing even Toolset is disabled, on a vanilla WordPress install.

If you could outline how you set up a working redirect like shown on the Codex - using Toolset Views 2.3, if you prefer, or no Toolset at all, I can then try to follow that, however for me, as I show above, it does not work either with or without Toolset.

That function is not a Toolset function and it is made for redirects of posts URLS as the Codex shows, so there are many application cases, and Toolset Views Query URLs would be the last to alter with that Filter, but it should be possible if what is stated in the codex works.
But as said, it does not, as tested locally.

As I have no access to your site, I cannot see for myself how this is setup, however I doubt it would help as online it is difficult to debug such issues. If you can provide me with a copy of the site, or I can also try to have a look directly at the site, however the best here would be a copy.
This ecause that can be used locally for me to analyze the problem step by step.

Note also, Toolset Views has no influence whatsoever over rewrite rules, generally speaking.
That is - if any - handled in Toolset Types Post Type registration, taxonomy registration and slug composing of the posts.
It cannot be altered with/thru Views.
Toolset Views surely creates URL query arguments - but those are not a part of the permalink or rewrite URL of posts.

It is hence confusing that an update to Views should have altered the WordPress core feature to rewrite URL's.
(Which as said, locally does not work even without Toolset, with that function, however it works fine with the backend settings).

Maybe I will grasp the issue and find the solution quicker on a local testing site, you can create a copy following these steps https://toolset.com/faq/provide-supporters-copy-site/.
I will need to know where you add the code, what URL you call and what will be returned instead (or should).

Then I can analyze this and eventually spot the issue

[lenas]

I have uploaded the old version of your views plugins so that you can see it working fine: hidden link

You should have full access to the environment as provided for this or the other ticket you are working on.

[Beda]

Well, the Views in that page have no Query Filter added so calling any ?= parameter will never work.
Neither hidden link, nor hidden link have a Query Filter responding to any of the redirects or URL query parameters you add in the code.

I see you have Front End filters in those Views but without query filters they are useless.
Nothing will be filtered if there is no Query filter, but just a Search filter (front end)

There seems to be a problem with both views actually:

This View has some query filters that are missing from the form. Maybe you have removed them:
Filter by post search
Filter by tables-features
Filter by product_cat
Filter by wallbed-feature
Filter by luggage-cart-feature
Filter by food-warmer-feature
Filter by dance-floor-feature
Filter by market
Filter by buffet-station-features
Filter by stages-risers-features
Can they also be removed from the query filtering?

This View has some query filters that are missing from the form. Maybe you have removed them:
Filter by color
Filter by stages-risers
Filter by tables
Filter by ptype
Filter by functionality
Filter by shape
Filter by attached-seating
Filter by seating-capacity
Filter by ada
Filter by accessories-caddies-feature
Can they also be removed from the query filtering?

The problem its that there are NO query filters, so the message is wrong, there are no filters in those views.
At least this view does not even have the Search filters hidden link, but this view actually has the Search filters, however the QUERY filters are missing, hence nothing can be filtered:
hidden link

Additionally I see the Views are broken (no code highlighting) hence there are more conflicts interacting here.

1. The Views like this will not produce any filtered results.
2. The Code you use, even if working, won't filter or select anything as the filters are missing.
3. Finally, your snippet is inactive: hidden link > code.
I am not sure if you have the code in your theme instead?
Because I see the checkbox checked when using the Views version you suggest to check, pointing to some difference between current and older Views versions - but these views would not have worked either in any older version as the query filters are missing.

But then, I see you do a lot of redirects in your theme with wpv-items so it could be that you customized the queries with code...

In other words, we are not any step further than before.
I need a copy of this site and I need to know how to setup a redirect like you do that works, because a clean such redirect does not work.

I see a lot of the code in the theme uses API from the Toolset Plugins, so it could be that you fully build your query with some API for Views, but it is not done in the 2 Views included on that archive linked.

I need to understand how you achieve this problem, to replicate it, and the developers to fix it.

Otherwise we cannot help with this.

Locally, the function does not work if you use or not Toolset.
I replicated this several times, and Toolset will not fix the function if it is not working.
I assume I miss some crucial step.

Can you please send me a copy of this site, and explain where I find the code, and all involved items, so I can debug this locally?

Thank you for your collaboration.

[lenas]

I don't think you understand the logic of our theme (with wpml). Let's close this thicket, we will just continue using the older version of the wp views plugin.

[Beda]

Yes, that is right.
But I can help you once I understand it and I can do so along with your instructions and a local test.

I actually only need to know how to replicate the Views issue, which as said, it is not clear how you make these views respond to any filter generically speaking, but I can see the difference you show within the versions, so I want this to be fixed.

You should not stay on an outdated version, this will then create other problems.

I need a copy of this site, along with the steps (or if the steps are very simple, just the steps) to achieve this issue.
As I tested repeatedly locally the function of WordPress is *not working* as such and cannot be used to redirect anything, as tests show.
So there must be something else to the entire setup.

I will also ask help from the developers on this, in case I miss something.

[lenas]

Please close this ticket, i no longer feel comfortable "collaborating" with you.

[Beda]

OK - I hope someone else can help you with this.

I would like to solve it but cannot understand how the issue is reached.

I am sorry for this.