The problem I am facing is as follow:
I created a new page in Wordpress with a url rewrite '/foo/'. Probably I hit something
(just configured things in the Admin panel not in the database!) an now /foo/ just points to my index and doesn't point to the given page (anymore!). If I just change '/foo/' to something like this '/foo-1/' it works perfectly.
I think it's to hard figure it out what goes wrong but maybe someone has a good suggestion or knows which data I need to remove from the database!
Thanks in advance,
Nick
Whenever you are fiddling with URL rewrites ( especially with new custom_post_types and taxonomies, but basically everywhere ) it is very important not to forget flush_rewrite_rules(); which basically take care of flushing the WP rewrite rules ( like it's name ) - thus allowing you to declare new ones without a conflict.
Related
I'm trying to force display the list view in my Woocommerce store but I can't seem to get it working.
The theme has support for list view and you can force it by appending "?product_view=list" so a category URL becomes:
http://subliminalscience.com/product-category/icbch-hypnosis-certification/?product_view=list
Instead of the default one:
http://subliminalscience.com/product-category/icbch-hypnosis-certification/
I added this Rewrite Rule to my htaccess but it doesnt:
RewriteRule ^product-category(.*)$ http://subliminalscience.com/product-category$1?product_view=list
It seems Wordpress ignores this Rewrite rule. Any ideas?
I'm surprised this answer stands as the only one.
Making changes in .htaccess to force this sort of behaviour seems really unnecessary and obviously isn't useful for others trying to solve this issue, especially those users on nginx servers or on shared hosting without .htaccess access.
You should try to fix this in PHP using an action.
Looking at your question, I can tell that theme you have is checking for GET data in the URL bar, which is the ?key1=value1&key2=value2 part of an URL. GET is an HTTP method that you can read about here if you want to learn more.
You can actually set GET data in PHP, and you can safely put this into your functions.php file.
You will want to create a function that simply checks the current page, and if it's a product category page sets the GET data.
At the bottom of your functions.php, you'd want to add something like this:
<?php
//Force all category pages to list view.
add_action('woocommerce_before_main_content','force_category_list_view', 5);
function force_category_list_view(){
if(is_product_category()){
$_GET['product_view'] = 'list';
}
};
?>
I actually can't test this, but I think it'd work. Essentially, in the woocommerce template archive-product.php, the first action that runs is 'woocommerce_before_main_content'. What we're doing is calling our function, which checks the page is indeed a product category. If it is, it sets the GET variable as list, which is exactly what the URL is telling the page to do already.
Mainly this is just a better practise than altering your .htaccess, but someone determined could also override that GET data by changing the URL to read ?product_view=list&product_view=xyz I can't imagine this would be an issue in this instance, but in other instances it might be.
The WP is redirecting the home page to the home_url (or site_url not sure since both are the same values) even when arrived to the page using the parked domains. This started after the recent update. Also, I confirmed, no htaccess, server configs nor any plugins doing the redirect.
After thorough research the solution I found are placing the following in the functions.php remove_action('template_redirect', 'redirect_canonical');. That solution is years old and don't seem to work anymore.
The way I set it up is I park the domains to the WP site, and the contents displayed are based on the domain. Just happens on the index page, if it has any urls appended, it works. Any help is appreciated.
It looks like the new version of the WP enforced the redirect on homepage. My issue was resolved with the remove_filter('template_redirect','redirect_canonical');. I wasn't able to see the change in effect after I applied that fix because the browser cached it somehow. I tested it on the Private mode, and it worked. I had to clear the cache to see it working.
I ran into the same issue and got i fixed, thanks to your answer. However, what are the implications of removing that filter? It sound important by name, so did you experience some new issues so far?
PS: i would have posted a comment to the previous answer, but my stackoverflow points are below 50...
LTDInvestments is actually correct. In your wp-config.php, ensure that 'WP_HOME' and 'WP_SITEURL' have values which are lowercased.
This fixed it for me; I guess case-sensitivity is something you should mind throughout your wp-config.php and wp-admin settings.
This works for me (as for version 5.9.3):
add_filter( 'redirect_canonical', 'disable_redirect_canonical', 10, 2 );
function disable_redirect_canonical( $redirect_url ) {
return false;
}
Note: this removes redirecting for urls that partly match slug of content that exists for example domain.com/terms will no longer redirect to domain.com/terms-and-conditions but instead return a 404 page.
Also changing the WordPress Address (URL) and Site Address (URL) to all lower case works.
So here's the problem: We don't like the fact that WordPress doesn't allow duplicate slugs, even for sub categories meaning we cannot have urls like:
product-1/guides
product-1/articles
product-2/guides
product-2/articles
That's very annoying! One solution we are considering is setting up our slugs like this:
product-1/product-1-guides
product-1/product-1-articles
product-2/product-2-guides
product-2/product-2-articles
But in our htaccess - can we use it to pick up such urls and rewrite them as prettier urls which have the product name removed from the sub folder? We don't mind hard coding these as we'll only ever have 5-10 products on the site.
This would keep the WordPress install happy with unique slugs, but the SEO tick in the box with better looking urls.
I just need a hand with the syntax please?
EDIT 1:
After looking at the WordPress Rewrite API, I'm failing to get anywhere with what I think is a really simple test. I have the following code in my functions.php which is running as I tested an echo, but no rewriting is taking place?
add_action( 'init', 'productRewrites' );
function productRewrites() {
add_rewrite_rule('^wordpress/james?','index.php?author_name=jwilson','top');
}
Nothing happens when I hit:
mysite.com/wordpress/james
Edit 2:
Cool I realise I now have to click save each time. The problem I now have is the following does not work not when I use $matches[1] - it only works if I hard code the author_name value (to jwilson for example):
function productRewrites() {
add_rewrite_rule(
"writer/([^/]+)/?",
"index.php?author_name=$matches[1]",
"top");
}
When I use $matches[1] it just returns everything! So clearly isn't using ([^/]+) in the url?!
you have to reset permalink structure
in order to do that, move to Settings -> Permalinks and press Save changes button
First I have www.mywebsite.com/blog/ Which is another wordpress Blog under www.mywebsite.com.
Then I created a page inside www.mywebsite.com which has a url of www.mywebsite.com/blog/.
I want to change the first www.mywebsite.com/blog into www.mywebsite.com/blog2 so It won't confuse me anymore.
After changing the permalinks in the admin panel. I can't access www.mywebsite.com/blog anymore.
Is there any way to access the page of the original www.mywebsite.com/blog2/wp-admin? and view the duplicated page www.mywebsite.com/blog/?
Please comments if my question confuses you.
Thanks.
When moving your site, give the guide to moving wordpress or, in this case better, the guide of changing the wordpress url a glance.
Suppose you changed the URIs where you cannot move the files, but still can access the login page (through a redirection or something) you can recover your installation easily.
wp-login.php can be used to (re-)set the URIs. Find this line:
require( dirname(__FILE__) . '/wp-load.php' );
and insert the following lines below:
//FIXME: do comment/remove these hack lines. (once the database is updated)
update_option('siteurl', 'http://your.domain.name/the/path' );
update_option('home', 'http://your.domain.name/the/path' );
run it (once) and you are done. Test your site to make sure that it works right. If the change involves a new address for your blog, make sure you let people know the new address, and consider adding some redirection instructions in your .htaccess file to guide visitors to the new location. Delete those lines from your wp-login.php.
I am trying to pass an email address to a wordpress page like so:
http://www.website.com/?email=fakeemail#yeahwho.com
However, Wordpress turns it into this:
http://www.website.com/?email=fakeemailyeahwho.com
I even try URL encoding it like so:
http://www.website.com/?email=fakeemail%40yeahwho.com
But Wordpress is too smart and still removes the %40.
I understand that # is a reserved character, but I should be able to still use the URL encoded version. Alas, Wordpress does not want it to be so.
How can I force Wordpress to respect the # sign? I'm guessing I'll either have to hack the internals, or do some mod_rewrite magic.
from http://www.webopius.com/content/137/using-custom-url-parameters-in-wordpress
First, add this to your theme's functions.php file (or make a custom plugin to do it):
add_filter('query_vars', 'parameter_queryvars' );
function parameter_queryvars( $qvars )
{
$qvars[] = 'email';
return $qvars;
}
Next, try passing ?email=fakeemail-AT-yeahwho.com in the URL and then converting it back with something like this:
global $wp_query;
if (isset($wp_query->query_vars['email']))
{
$getemail = str_replace( '-AT-', '#', $wp_query->query_vars['email']);
}
// now use $getemail
This would only not work in the very rare occurrence of an email that actually has "-at-" in it. You could replace for an even more obscure string like '-AT6574892654738-' if you are concerned about this.
Whatever your final solution, don't hack the core to get it to work. :)
I was having a similar problem and I was able to isolate the issue to an SEO plugin. I'm sure the plugin added a filter to the functions.php but as the plugin wasn't being used uninstalling the plugin also resolved the issue.
I also had this problem, but it wasn't caused by a plugin. It was a result of the 301 redirect that WordPress does with regard to your Site URL having, or not having, a www. in it.
If my Site URL was defined as http://www.mydomain.com, then this would work as expected: http://www.mydomain.com/?email=user#domain.com
If the user came to the site as: http://mydomain.com/?email=user#domain.com (NOTE: no www), then WordPress would redirect to this: http://www.mydomain.com/?email=userdomain.com (NOTE: the stripped # symbol)
My solution was to hard code the www redirect in the htaccess file, so WordPress would never have the opportunity to mess with my URL. This page gives example htaccess lines to redirect non www to www and vice versa: http://dense13.com/blog/2008/02/27/redirecting-non-www-to-www-with-htaccess/
I was having a similar problem today when trying to pass Mailchimp data through to a Gravity Form in Wordpress. I found a solution. The original question stated that Wordpress was also stripping %40, but it didn't for me in this instance.
1) In Mailchimp create a new Merge tag. I called mine 'Email Param' and * |EMAIL2| *
2) Export your list of subscribers
3) Copy the normal 'email' column content into the new 'Email Param' column.
4) Do a Find and Replace for all # symbols to %40
5) Import your list and tick the box that Auto-updates that list
6) Update your URL to include the new parameter
* |EMAIL2| *
That worked for me.