Somehow my Joomla after an upgrade from 3.4.7 to 3.4.8 is not formulating the base URL properly. The base is supposed to be "www.domain.com/en-us/" for the English version of the site. It renders the following as the base url "www.domain.comhttp://www.domain.com/en-us/www.domain.com/"
further rendering the following url for resources, such as for "green_leaf.png": "www.domain.comhttp://www.domain.com/en-us/www.domain.com/images/green_leaf.png". Consequently, the pages full missing page elements.
SEF is enabled. Multi Language Filter Plugin is enabled. Any ideas what could be the cause of this besides, the configuration and the htaccess files? Those file are pretty standard.
The first things I would confirm are
- in system > global configuration > site -- is URL rewriting set to yes and have you renamed htaccess to .htaccess?
- if yes then ftp to your site, open configuration.php in a text editor, locate the line setting the $live_site variable and change to
public $live_site = 'http://www.domain.com';
Good luck!
I have tried your suggestion, to specify the $live_site variable in the configuration.php file as you indicate, even though I have also been recommended to leave it empty. The results were the same, the issue remains.
Here is the latest on this matter:
I have created a local copy of the site on my machine from a backup that was still Joomla 3.4.7. The same issue appears. I have reverted back to an earlier backup with Joomla 3.4.6 version of the site, and the site's page was restored to normal. This is with the same exact .htaccess and configuration.php across the 3 Joomla versions.
I have also tried with "Options +FollowSymLinks" commented out in the .htaccess file that came with J3.4.8. On both the live hosted site and a locally hosted copy, same exact results, namely:
Using Google Chrome (with Language Filter Enabled and set to Remove URL Language Code)
On the live hosted site:
www.domain . comhttp://www.domain.com/www.domain.com/
On the localhost copy of the site: localhost/domainfolder/localhost/domainfolder/http://localhost/domainfolder/localhost/domainfolder/domainfolder
So this issue might be pertaining to Joomla versions 3.4.7 and 3.4.8. The challenge is that 3.4.6 also has critical security vulnerabilities.
Also tried with Language Filter Disabled - Same result (Base URL formulated as above) with the difference that all the languages are displayed at the same time on the home page with the resources that are not found because of the faulty base url.
Related
How to tell TYPO3 v10 (globally) to generate absolute links in frontend? config.absRefPrefix doesn't seem to work any longer. Also, using absolute urls as base in site configuration doesn't have any effect. Still relative links in frontend.
EDIT:
config.absRefPrefix seems to work for embedded resources (script, img etc.) but not for usually generated hyperlinks (MenuProcessor, RTE links etc.). Do i really need to set option absolute=1 for all my links generated by view helpers and configure RTE processing to generate absolute links? Thought that's why the global option "absRefPrefix" exists...
This problem already exists since TYPO3 v9. There is a ticket in the bug tracker regarding this issue. I assume that in TYPO3 v12 config. absRefPrefix might be removed completely.
In the ticket comments you can find a number of hints, how to implement absolute links in various places:
use (NO/ACT/...).stdWrap.typolink.forceAbsoluteUrl = 1 for HMENU
for links in the CKEditor RTE this config make every link absolute:
lib.parseFunc_RTE.tags.a.typolink {
forceAbsoluteUrl = 1
forceAbsoluteUrl.scheme = https
}
if you want to globally rewrite all links to absolute links, you can implement the middleware mentioned in the ticket.
I have a website on a 1and1 server. I have 2 domains on the package; the default url somenumbers.websitehome.co.uk and my actual URL.
The problem is, Joomla quotes the somoenumbers.websitehome.co.uk in system e-mails instead of my actual URL. They both point to the same directory I just don't want to give a stupid URL to my users.
I think I have narrowed it down to the $siteUrl variable but I'm not sure how to go from here.
Thanks
James
At first I thought this sounded largely like a DNS issue - but then you said you only have 1 Joomla installation and both domains point to that directory.
If they're both pointing to the same directory, then both domains will display the same Joomla installation. That is, unless you're checking to see where they are coming from and having the content display dynamically based upon how they got to your site - but from your comments I doubt you're doing that. How your domains are behaving is the expected response if you're pointing them both to the same directory.
If you want 2 sites on the same hosting? Setup 2 databases (or apply different prefix for each site and use 1 database) and set up each website in it's own directory.
Adjust the DNS of each domain name (and subdomain name) to point the appropriate directory.
From there, use the .htaccess file and SEF URL's to get rid of any indicator of the directory so that it displays the same as if the site was in the root directory.
That is the best way to accomplish what you're after - because from the sounds of it Joomla is doing exactly as it should, displaying correctly what is in the directory since both domain names point to the same directory.
$siteUrl should be left blank.
We can see many HTML page using src="//example.com/myjavascript.js" to include a .js and let the browser use http:// / https:// depending on the current scheme of the page URL.
Is this a valid URI ?
Yes, it is definitely valid. It is a "scheme relative" or "protocol relative" URI. In the spec since the beginning. Quite helpful to deal with http/https issues.
Read a much better description and caveats:
Is it valid to replace http:// with // in a <script src="http://...">?
A few points to keep in mind:
There are some minor issues on IE 7 & 8 with double downloads
If you are viewing an HTML page from a file the browser will replace the scheme with file://, and not load your JS file from the server like it would with a full URL starting with http:// or https://.
Edit for modern webdev practices:
While the URL is still valid, it is now recommended to use https for third party resources (and, serve those resources from secure pages). The performance or compatibility issues from years ago are largely resolved with updated protocols and browsers.
As a warning... we encountered issues with this methodology NOT being supported in Internet Explorer when used inside the HTML BASE tag (IE8 and 9 confirmed, didn't test any others before patching the issue).
After newly implementing SSL on a website, we had initially updated the BASE tags across the application to simply reference "//www.mydomain.com" : but the page templates broke (in IE only) on all scripts which did NOT live at the root of the site. Makes sense, since the BASE tag was not picking up the stylesheet or other relatively-linked resources which assumed they were being referenced from root, not from a nested location.
Since the BASE URI was our own domain anyway, we fixed the issue by setting the BASE tag's value to "https://www.mydomain.com". No matter if the client is browsing the site in SSL mode or out, at least it will work cross-browser now and can ALWAYS find its content - and by forcing https at all times, we ensure we don't get any content-mismatch warnings in the process by setting the BASE path to an http location while browsing a page using https.
It is valid indeed and I have just learned this in the hard way!! We broke a customization feature so you should always validate an URL like this (in .NET):
Pay attention to:
White spaces (Trim)
"scheme relative" URI (UriKind.RelativeOrAbsolute)
public bool IsValidUrl(string resourceUrl)
{
Uri uri;
if (Uri.TryCreate(resourceUrl.Trim(), UriKind.RelativeOrAbsolute, out uri))
{
return uri.IsWellFormedOriginalString();
}
return false;
}
To be able to use Edgecast CDN, we had to write a custom media provider which worked well with before the site was upgraded from 6.5 rev 111230 to 120427. After the upgrade, none of the images showed up on the website. I debugged the code and found a probable cause. In the upgrade following fix was included -
By default, media URLs will now be generated relative to the site root (such as /~/media/images/picture.ashx or /virtualFolder/~/media/picture.ashx) instead of relative to the current page. Such URLs are considered SEO friendly, and also improve caching. (346213, 332285)
This is now adding a leading slash "/" at the beginning of the media urls. So urls are not getting generated as "//mediaserver/abc.jpg". The 'MediaUrlOptions.VirtualFolder" is being set to "/" by default. I want to confirm that this is the issue and also if I can override this in code but I want to find out if this can be controlled from the config file instead of making this change in the code.If this is not the issue then how can I fix this problem?
In the interest of providing the answer here:
Remove the slash in the Media.MediaLinkPrefix setting due to Sitecore automatically adding it now:
<setting name="Media.MediaLinkPrefix" value="/mediaserver" />
As well as in the following one:
<handler trigger="/mediaserver/" handler="sitecore_media.ashx" />
Also, Media API improvements have been made since version 6.5.0 rev. 120427. Now it is possible to elegantly override the MediaProvider class using a web.config setting per reference number 312358 in release notes on the SDN:
http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/ChangeLog.aspx
Thanks in advance for any help you can provide!
I have a website built in Ruby on Rails. My site has a webpage, located at example.com/communityboard, that you can use to enter a separate Community area (an off-the-shelf bulletin board called bbPress.)
I want users who type in the URL example.com/community to be redirected to example.com/communityboard . It used to work this way, but for some reason, the redirect no longer works in any browser but IE.
We accomplished this redirect by placing an index.html file in the /community folder where bbPress had been installed. The entire code for the index.html file reads
<meta http-equiv="refresh" content="0;url=http://example.com/communityboard">
Back when we built the site, I was told that a meta refresh redirect using an index.html file was the best option. The redirect had to address ONLY a single page (http://example.com/community) and not all of the sublevels of the community bb (which lives at http://example.com/community/index.php). Otherwise, the community bb and all of its sublevels would be redirected.
So... my questions:
Why is the meta refresh redirect not working anymore?
How can I fix it?
Thanks again for any help you can offer!
If it's only working in IE, it's possible there's a script or parsing issue that's breaking other browsers. I would run the HTML through a validator like http://validator.w3.org/.
Meta-refresh is a legacy practice that is now discouraged -- the wikipedia entry contains more info and links to alternative solutions: http://en.wikipedia.org/wiki/Meta_refresh.
Here's what happened according to my developer. I don't fully understand the explanation, so I'm not sure I can answer follow-up questions! "With the old mongrel cluster, Apache would recognize "/community" as a directory, silently forward to "/community/", which would then pick up the forwarding index.html file. With Phusion Passenger," which I guess we're using now, "Apache sends the request directly to Passenger if "/community" is not a regular file, and Passenger was returning the 404 error. As a fix, we've disabled passenger in the community folder, which fixes the problem."