I am concerned this may not be possible (at least not easily) in Magento (1.4).
So we currently have a site set up:
shopping-public.mysite.com
Searching through core_config_data and the source code, shopping-public is referenced quite a few times.
What I want to accomplish is to have the following subdomain work on the same code base, AND have all the links between pages match up:
shopping-development.mysite.com
I have set up ServerAlias shopping-development.mysite.com in the .conf file, and it works - that is, I'm getting there, and the page is being presented.
However, it does NOT work in the sense that:
a) the references to the CSS files and JS files are still to shop-public.mysite.com, and
b) links to products and other pages are still to shop-public.mysite.com
How do I solve (a) and (b) so that, regardless of the subdomain (or even domain), asset file links and page links change relative to the (sub) domain I am on?
I am fairly new to Magento, and there are a LOT of xml values that reference this involved..
Magento have a lot of configuration.
core_data
htaccess if use apache need test rewrite rules ok or no.
and maybe hardcoded index.php with switch case?
But firstly try clean cache.
Magento will, as you can see, always attempt to redirect back to the primary domain. To achieve this, I think you'd probably be best using different store views/sites and then using .htaccess to load the specific site required.
With this approach, there would be a concern over duplicate-content in Google's eyes I'm sure.
Related
I am trying that when someone opens this link: [url]www.example.com/invite/1234randomhashtag[/url]
Will be redirected to:
www.example.cloud/index.php?cl=register_new_user&fnc=register&hash=1234randomhashtag
Now this can easily be done with the PHP header.
However I have also found the oxutilsurl class. Is it even possible to do this with this class? Does it help?
Oxid does not support you by changing the original oxid routing mechanics in a way that they would work for you. There is a way to set up static redirects within the general settings inside the oxid admin backend (see SEO tab). But those do not support wildcards (/invite/*) like you would need them.
Theoretically speaking, if you really wanted to have a solution for this one inside an oxid module (to avoid hacking the core, and having it bundled within a module) you could extend one of several oxid functions that are being called before oxids very own mvc based routing logic is reached and manually redirect at that point. Basically this could be done in every core function that is being called before you get routed to the 404 page (oxseodecoder::processSeoCall)
Considering the official info from oxid, that lists the non overloadable classes, you should be able to extend oxshopcontrol::start (or even oxseodecoder::processSeoCall) and add something like the following:
if(preg_match("/\/invite\/.*/", $_SERVER['REQUEST_URI'])){
$randomHash = basename($_SERVER['REQUEST_URI']);
oxRegistry::getUtils()->redirect($this->getConfig()->getShopURL().'index.php?cl=register_new_user&fnc=register&hash='.$randomHash , false, 301);
}
Anyway, I think the simplest, fastest and most performant approach on this one would be setting up url redirects within the .htaccess file inside your shops root directory.
The following should work:
RewriteRule ^invite/([A-Za-z0-9-]+)/?$ index.php?cl=register_new_user&fnc=$1 [NC,L]
You could put that code immediately under RewriteBase / inside the .htaccess file within your shops root directory.
I put that rewrite rule together with information from this article.
OXID has no dynamic routing based on url parts.
There is a SEO URL entry in the database for every valid SEO Url.
You could generate a SEO Url when someone uses your invitation function and remove the url after couple of months.
Or you need to change your generated urls a bit and make it look like this:
www.example.com/invite#1234randomhashtag with # instead of /
and then parse your hash from $_SERVER["REQUEST_URI"] and set your variables or redirect to the final URL
But you still could solve this outside of OXID with .htacess rewrite rules (i guess) or another php micro framework like "Slim" or "Lumen" running in /invite/ directory and redirecting your visitor back to the shop
I want to mask some of the subdirectories and pages for my website. For example:
I want to change
www.example.com/blog.php?post=post1
to
www.example.com/blog
or something similar to that. I have seen examples about redirecting and such but that doesn't seem to work for what I want and I would like to stay away from iframes if possible. I just want the address bar to not reflect my internal directory structure and page names. I want it to keep showing /blog while they are moving from post to post. Thanks.
P.S. I am not using wordpress or any other CMS or blogging system.
You can use apache mod_rewrite for that.
Mod Rewrite Generator
And if You don't want to have the same url on blog-post/article change, but to display different content, all I can think of this moment is by using either POST method or browser cookies, but, that would require a lot of page reloads, and it simply is not recommended for wide use. If You are building per_se (one person only) panel or similar, than url doesn't matter that much, but, speaking of blog..
It is quite reasonable to hide .php extension or url query index/key, but not what You would like to accomplish.
Like I said, it is possible, but Luke .. don't do that.
Blog should be bookmarkable on each and every #stop, and that happens just because of unique urls and hash values. Without these two, no hyperlinking possible *(not to mention seo penals and flaws + dozen of other unwanted obstacles, page caching for instance).
If I use user interface Tools - Domain mapping (changeing last to first url)
Would result in broken images.
Based on http://codex.wordpress.org/Moving_WordPress I would assume, it makes sense to use https://interconnectit.com/products/search-and-replace-for-wordpress-databases/. My question is : Is there a better way to change domain mapping so that it does not result in broken images.
When I have changed domain before on a single site installation I have used the database find and replace method (always backup first!) and I've found this to work sufficiently for that.
If you want an alternative you could use rewrites for the old domain to point to the correct files for the images.
There has been some info posted here in regards to rewrites for a similar issue https://wordpress.stackexchange.com/questions/53873/host-wp-content-on-other-domain-much-like-a-cdn#answer-53881
Just redirect any request from the old domain for images to the correct folder. This will however require you to keep the original domain for the foreseeable future.
You can find info on all the Wordpress rewrites here http://codex.wordpress.org/htaccess
I hope this answers your question
Not fully sure if this is possible or not, but Ive been tasked with rebuilding a handful of sites that, their internal workings is a mystery as to how they are still functional. Raised before MVC, CMS, etc were even really known about. In the days of PHP 4 on the cusp of 3, if that gives you any idea. So.. I have a mess, a big on, that I am trying to rebuild using a MVC, which thats not really the problem.
The problem is, is the 20,000 or so files and images that have been stored in articles, and various other things on this site over the ages. So there is sites every where that have hotlinked images and other files, not to mention the hardcoded urls in the articles, which will eventually be converted correctly but theres so many.
Anyway. Bottom line is I wanna know if theres a means of mean taking failed image and file requests and mapping them to a new folder that will have either all these images or files in them. Is this something htaccess can do alone or is this something I will have to come up with a means of serverside script and htaccess? or is it the worst case where I am going to have to take the hit for files not found, and route them all to a single error page, saying the files have been moved?
Not sure what would be a good course of action for this problem so I havent tried anything yet, kinda trying to feel it out and see where I have to go from there.
You can use redirection for all image extensions to specific folder:
RewriteRule (.*)\.(gif|jpg|png)$ /my/new/folder/$1.$2 [R,L]
Hope this helps...
My site currently handles URL's like this...
/?p=home
/?p=profile&userid=1
/?p=users.online
/?p=users.online&page=23
/?p=mail.inbox
/?p=mail.inbox&page=12
... and so on, there is probably at least 120-150 different pages, on my site a page is built like this,
index.php includes a main config file which then includes function/class files into it
index.php then includes a header file
index.php then includes the page file which is from the url ?p=pagename
index.php then includes a footer file
That is how every page on my site is compiled, through the index page like that and I have been considering/thinking about cleanning up the URL's as I am re-writing/restructuring most of my sites code right now, it's the perfect time to do it if I am going to do it. What I mean by cleanning up the URL's is using mod-rewrite so the URL structure above would look like this instead...
/home
/users/1 //user ID might switch to use username as well
/users/online
/users/online/23 or /users/online/page/23
/mail/inbox
/mail/inbox/12
So first of all is there any downfalls to doing this, does it create a lot more processing work since it is using mod_rewrite?
Also would it be hard to write the regex or whatever is needed to match the file names in the format that I show above, I listed only a few of the pages but there would be at least 100 different URL pages I have blogs, bulletins, forums, all kinds of stuff
Absolutely. That's one of Apache's main purposes, so it's been designed to do it very efficiently. In fact, I'd emplore you to use that method.
It makes cleaner URLs for visitors
It's fantastic for SEO
It makes the website more professional
It makes it easier for users to guess URLs if they are trying to find a certain page without actually traversing through your site ti find it.
There are no downfalls, and a ton of advantages to using that URL structure. Go for it!