Style sheet urls not complete

[bhughes]

My apologies if this has been brought up before but several hours of searching and dinking has not led me to the answer yet

This is a standard Centos 5.4 server running apache, php, and mysql.

I have a 2.3.1 install that we want to run in a virtual server so that when apache sees events.ourdomain.edu it will see the /ocs directory and just work. There will be a couple of other services running as well on thier own servers. Problem is that if I create the virtual host entry and http://events.ourdomain.edu serves /ocs/index.php like expected the urls for the style sheets don't work. In the header.tpl file I see that a smarty variable $baseUrl is used but I cannot find where it is set. It is not apparently the config.inc.php base_url variable since changing that seems to make no difference even after deleting every file under cache except for the _db ones.

this is what the urls look like by the time they get to the browser.

Without the v-server set and ocs installed in the ocs directory under document root (works):
<link rel="stylesheet" href="/ocs//lib/pkp/styles/common.css" type="text/css" />

With the vserver set and it's documentroot at /ocs (no worky)
<link rel="stylesheet" href="//lib/pkp/styles/common.css" type="text/css" />

Any tips appreciated. I know I can dink with the code and make it work or I am assuming I can but that will go away on an upgrade and I would rather not cause probs for people down the road.

Thanks,
Bret

[simon_w]

Yes, in the latest release this, like a great deal of the url despatch code, is broken

In this particular case I suspect the problem something to do with the labyrinthine routing classes returning a single '/' when the installation is directly in the webroot of a virtual host. The templates are (generally) expecting a $baseUrl variable without a trailing slash, and so paths relative to the base are all prefixed a slash. (inexplicable exceptions to this include the js for the font-resizer in `templates/common/sizer.tpl`, which is why those come up correctly)

There are problems like this *all over* the codebase, but a double '/', whilst messy, is usually normalized and resolved successfully by the webserver. When the double slash appears at the very beginning of a URI, however, it results in an unresolvable address.

I discovered this just this morning. After getting a bit fed up with the mess trying to get vaguely clean urls with OCS 2.1.2, I decided to install the latest code, in the hope that some of these issues would be easier to deal with in 2.3.1. Unfortunately I immediately fell foul of these broken urls all over the installation page and the main header templates.

I've hacked hard-coded urls into my templates for now - don't have time to get to the bottom of this.

[gponceba]

Well here I am with exactly the same problem... in OCS 2.3.1, after upgrading from 2.1.2.

In addition, in OJS 2.3.1 does work properly and I have the same .htaccess and the same "/lib/pkp" folder

And the http://pkp.sfu.ca/bugzilla/attachment.cgi?id=1381 is no longer useful in OCS 2.3.1

Any tips appreciated too....

[mcrider]

Hi all,

The paths to the CSS files should be full URLs, e.g. including http:// and the domain. The {$baseUrl} variable comes from lib/pkp/classes/core/PKPRequest.inc.php::getBaseUrl(), where it tries to set the baseUrl from server variables, or else sets it from the setting in config.inc.php. I can't reproduce this, but its possible that the serverHost variable is being set in the getBaseUrl function, but isn't returning anything useful. I would suggest putting some debug code in the if statements of that function to see whether the if or else is being called, and what the value of _baseUrl is being set to, i.e. change

Code: Select all

if ($serverHost !== null) {
   // Auto-detection worked.
   $_this->_baseUrl = $_this->getProtocol() . '://' . $_this->getServerHost() . $_this->getBasePath();
} else {
   // Auto-detection didn't work (e.g. this is a command-line call); use configuration param
   $_this->_baseUrl = Config::getVar('general', 'base_url');
}

Code: Select all

if ($serverHost !== null) {
   // Auto-detection worked.
   $_this->_baseUrl = $_this->getProtocol() . '://' . $_this->getServerHost() . $_this->getBasePath();
     echo 'foo' . $_this->_baseUrl;
} else {
   // Auto-detection didn't work (e.g. this is a command-line call); use configuration param
   $_this->_baseUrl = Config::getVar('general', 'base_url');
     echo 'bar'. $_this->_baseUrl;
}

Let us know what gets displayed after you've made these changes.

Cheers,
Matt

[gponceba]

foo http://ocs.conferences.com (without final trailing slash)

Elsewhere it must add the trailing slash?

In the source code still appears <link rel="stylesheet" href="//lib/..." type="text/css" />

In header.tpl, {$baseUrl} is '/'.

Any idea? Thanks.

[mcrider]

Hi gponceba,

Well, it should be adding the domain to the stylesheet URLs--in lib/pkp/classes/template/PKPTemplateManager.inc.php, the 'baseUrl' variable is assigned to all templates with the value from Request::getBaseUrl(), and in lib/pkp/templates/common/header.tpl the {$baseUrl} variable should be attached to all the CSS URLs (with the trailing slash after the domain added there). First, I'd suggest looking at your server log for any warning messages, and then echoing the value from '$request->getBaseUrl()' in the PKPTemplateManager (constructor) function of the PKPTemplateManager class, and also printing the value for {$baseUrl} somewhere in the header.tpl file (e.g. at the bottom, add '<h1>{$baseUrl}</h1>'), and seeing what gets displayed.

Cheers,
Matt

[gponceba]

Matt,

"echo $request->getBaseUrl()" in "lib/pkp/classes/template/PKPTemplateManager.inc.php" is "http://ocs.congresos.com" too.

Why (or where) become a "http://ocs.congresos.com" in a "/" in $baseUrl of the templates ??

In my OJS 2.3.1 works great, and both are hosting in the same server. I don't have access to server logs...

Thanks.

Cheers.

[mcrider]

Hi gponceba,

Like I said, the trailing '/' is added in lib/pkp/templates/common/header.tpl wherever {$baseUrl} is called, e.g. <link rel="stylesheet" href="{$baseUrl}/styles/common.css" type="text/css" />. I'd suggesting checking to see if the {$baseUrl} is being printed out in that template.

Cheers,
Matt

[gponceba]

Sorry Matt, I don't express and read myself very well in English.

<h1>{$baseUrl}</h1> is printing as <h1>/</h1> in
- /pkp/lib/templates/common.tpl
- /pkp/lib/templates/common.tpl
- /pkp/lib/templates/breadcrumbs.tpl
- /templates/common/navbar.tpl
- /templates/about/index.tpl
...

Any suggestion?

[mcrider]

Hi gponceba,

Does this line exist in the constructor for PKPTemplateManager.inc.php? :

Code: Select all

$this->assign('baseUrl', $request->getBaseUrl());

Cheers,
Matt

[gponceba]

Hi Matt,

yes, between

$this->assign('defaultCharset', Config::getVar('i18n', 'client_charset'));
$this->assign('baseUrl', $request->getBaseUrl());
$this->assign('requiresFormRequest', $request->isPost());

And even though I changed
$this->assign('baseUrl', $request->getBaseUrl());
by
$this->assign('baseUrl', 'http://ocs.congresos.um.es';
continuously <h1>{$baseUrl}</h1> printing the same <h1>/</h1>

However,
"echo $request->getBaseUrl()" in "lib/pkp/classes/template/PKPTemplateManager.inc.php" is "http://ocs.congresos.com" !! :S

Cheers.

[mcrider]

Hi gponceba,

Hmm.. well this is odd! I'd suggest grepping your code base for something like assign('baseUrl' to see if that template variable is being assigned somewhere else, overridding the one in PKPTemplateManager. Can you think of any other modifications you've made to the system?

Cheers,
Matt

[gponceba]

Hi Matt,

the upgrading to OCS 2.3.1 was by full package. No changes in the original code. Database issue?

Other users of this post also have the same issue.

Could this have something to do with my other issue? (viewtopic.php?f=13&t=5732&p=23431#p23431)

Thanks,

Cheers.

[asmecher]

Hi simon_w and gponceba,

Would either of you be willing to temporarily grant access to your server so I can investigate further? We haven't been able to duplicate this locally. If so, please contact me via PM or direct email.

Regards,
Alec Smecher
Public Knowledge Project Team

[asmecher]

Hi all,

This appears to be caused by a bug in the font size block plugin -- it's reassigning the baseUrl variable incorrectly, causing anything that subsequently uses it to have trouble. There will be a patch posted shortly.

Regards,
Alec Smecher
Public Knowledge Project Team