If you don’t mind, can you tell me how to write an external link so that it looks like this
website.com/shop/namecategory?archive-filter=1&price-min=0&price-max=24?orderby=price
instead of
website.com/shop/namecategory?orderby=price
<a class="nav-link' . esc_attr( $orderby == $id ? ' active': '' ). '" href="' . get_permalink( wc_get_page_id ( 'shop' ) ) . '?orderby=' . $id . '" >' . esc_attr( $name ) . '</a>
-
This reply was modified 5 years, 2 months ago by
chadrex.
-
This reply was modified 5 years, 2 months ago by chadrex.
Hello chadrex,
Thank you for bringing the Cyrillic charset related issue to our attention! Does this problem occur only in the items search box and nowhere else?
As for the link parameters, on the php end it’s always easier to use the built-in WordPress add_query_arg function and do something like add_query_arg( array( 'archive-filter' => '1', 'price-min' => '0', 'price-max' => '24', 'orderby' => 'price' ), get_permalink( wc_get_page_id ( 'shop' ) ) )
Yes, there is another thing, for example, if the attribute (attribute_name) contains Russian letters, then you can not then select the item in the frontend, they are just not clickable. I always use Latin for such parameters, in the original wc widgets the call is most likely by id, not by key. I don’t know how to make it better, it’s just that there is such a thing as extended Latin (e.g. Azeri), which may not work either.
——————–
On the second point, thanks for the answer, should have been a little different (get a full link and disable one of the parameters), did so:
remove_query_arg( 'orderby', $_SERVER['REQUEST_URI'] )
The non-latin product attribute (or custom taxonomy) slugs are indeed not supported, this is a known limitation, please keep it in mind when using our plugin!
Also, please do let me know if the encoding (weird characters like in the filter terms searchbox placeholder) issue jumps out anywhere else apart from that searchbox, we will be looking into it during our work at future plugin releases.
Dear @chadrex,
Seeing a fresh post from you on the forum, I wanted to use the opportunity and ask you if the Cyrillic encoding issue appeared anywhere else apart from the filter terms search box?
I have found this WordPress feature request, from which one could conclude that the utf8mb4_0900_ai_ci isn’t yet fully supported by WordPress.
IF you are familiar and comfortable with php code editing, you could try to debug it a bit by temporarily replacing line 188 of …wp-content\plugins\annasta-woocommerce-product-filters\code\class-a-w-f-filter-frontend.php (in plugin version 1.4.5) that reads
$html .= '<input type="text" placeholder="' . sprintf( esc_attr__( 'Search %1$s', 'annasta-filters' ), strtolower( $this->settings['title'] ) ) . '" class="awf-terms-search">';
by this
$html .= '<input type="text" placeholder="' . sprintf( 'Search %1$s', strtolower( $this->settings['title'] ) ) . '" class="awf-terms-search">';
or this
$html .= '<input type="text" placeholder="' . sprintf( esc_attr__( 'Search %1$s', 'annasta-filters' ), $this->settings['title'] ) . '" class="awf-terms-search">';
… to check if one of the functions (esc_attr__ or strtolower) doesn’t work properly with utf8mb4_0900_ai_ci.
That said, I also wanted to let you know that we have programmed to enhance the terms search box placeholder creation for the next plugin release, which may help you resolve the issue from a different angle.
It’s strange, I sort of wrote the answer, but he left … In any case, the last option is definitely working. I will also add that this bug did not always appear, as I understood the pattern was that 3 or more filters were activated …
That is, at some moments it was displayed normally. In any of your options helped, the issue is resolved. Thank you
