OJS produces links to js/css/href with (multiple) index.php

Hi :smile:

I just updated OJS to 2.4.7-1 with success! Since we currently migrating from PHP 5.2 / Apache 2.2 to PHP 5.5 / Apache 2.4, I copied that installations and moved it to the new server.

All is running fine - except one thing:

I go to: http://my.ojs/

Now I click on any other link (which shows: http://my.ojs/index.php/index/index as example). Then I got page without any stylehseets.

  • OJS text-only
  • links to stylesheets, etc are: http://my.ojs/index.php/lib/pkp/styles/pkp.css and so on.

If I hover now a new link on that page it gives me: http://my.ojs/index.php/index/index.php/index/login

You see, ojs adds index.php on links. That is correct in the first way, but why are they in stylesheet refs? And why does ojs adds it several times? Configs are updates, files_dir path adapted. There is no RESTful links-option enabled or any .htaccess (neither on old nor on the new server).

base_url is the same since I use local DNS redirect.

Only difference: php files are sent to PHP-FPM backend.

How to check whats wrong?

Thanks in advance! :wink:

Okayy… So, the site gets created by smarty.

<?php echo $this->_tpl_vars['baseUrl']; ?> Is the one which creates the prefix to the file refs. How is this variable filed? Who takes care of it?

Another update: OJS ignores the whole base_url setting. It is now set to something senseless - but the site still works and adds the base_url with index.php by itself ?!

If I change something else in the config (database as example) the changes gets reflected - so the config is read by ojs.

Who generates the base_url then and decide to ignore the one in the config?

Your base_url should be set in config.inc.php. This should not include “index.php”. What is your setting?

Another thing to check would be whether you have any mod_rewrite rules in effect.

Also, just because I’m not familiar with PHP-FPM, I would suggest checking to see if disabling that module changes the situation. It can’t hurt to check.

My base URL is set to http://my.ojs

mod_rewrite is off. No -htaccess or anything else

PHP-FPM can’t be just “disabled” as the whole server is configured to use it as separate process.
Would be nice to know, how the baseUrl gets defined on Smarty’s side.

Is this baseUrl anyhow detected via $_SERVER? SCRIPT_NAME maybe? Thats the Only difference. the old PHP 5.2/Apa 2.2 server has SCRIPT_NAME always set to script.php (regardless if there are PATHINFO’s). the new server includes these PATHINFO to SCRIPT_NAME.

I dont know if this matters - just noticed that while side-by-side comparison.

EDIT: base_url does not take any effect. currently it has the value of “bla” which does not change anything. baseUrl in Smarty gets not the value of base_url in the config!

Yes, in this situation the base url is detected by default via the $_SERVER superglobal. See:

What is your $_SERVER['SCRIPT_NAME'] under normal conditions?

Thnaks for your answer!

BTW: Mail-responder is NOT working:

The original message was received at Thu, 28 Jan 2016 06:34:45 -0800
from rm-rstar1.sfu.ca []
554 5.4.6 Too many hops 26 (25 max):

Now my answer:

In old environment: test.php (calling: /test.php/bla1/bla2/bla3)
In new environment: test.php/bla1/bla2/bla3 (calling /test.php/bla1/bla2/bla3)

Script_name contains pathinfo in new environment, but not in old one. Maybe this the problem.

I’ll search now possibilities to change that.

Would be nice now to force usage of base_url :wink:

EDIT: I think this whole thing is connected with my issue: PHP :: Bug #65641 :: PHP-FPM incorrectly defines the SCRIPT_NAME variable when using Apache Since I use Apache 2.4.7… I’ll look further.

Good find, @Commifreak. That looks on track.

Hi again!

This is not fixable by package update or anything else :confused: - Ubuntu won’t fix this in trusty.

They suggest a workaroung if PHP is < 5.5.18/5.6.3. If this matches, the script have to truncate PATH_INFO from the end of SCRIPT_NAME.

I change my local code, to reflect that change. Maybe you are interested in applying this in master as well? This affects all php-fpm users below 5.5.18/5.6.3 as I can see.

I try this code as workaround:

echo substr($_SERVER["SCRIPT_NAME"], 0, -strlen($_SERVER["PATH_INFO"]));


EDIT: I got it working now, by editing getRequestPath and getBasePath. But maybe I wait until 16.04 LTS… We’ll see…

Maybe something like:

    function getRequestPath() {
        $_this =& PKPRequest::_checkThis();

        if (!isset($_this->_requestPath)) {
            if ($_this->isRestfulUrlsEnabled()) {
                $_this->_requestPath = $_this->getBasePath();
            } else {
                // Check if we have affected PHP-Version to this bug: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1511414
                if(version_compare(PHP_VERSION, '5.5.18') == -1 || version_compare(PHP_VERSION, '5.6.3') == -1) {
                    $_this->_requestPath = substr($_SERVER["SCRIPT_NAME"], 0, -strlen($_SERVER["PATH_INFO"]));
                } else {
                    $_this->_requestPath = $_SERVER['SCRIPT_NAME'];

But I also had to adapt getBasePath:

            if ($_this->_basePath == '/' || $_this->_basePath == '\\' || $_this->_basePath == '/index.php') {

(added OR basePath == index.php. maybe I missed something but without it, the urls are not valid.