Individual Name for Each Journal within MULTIPLE OJS inst.

[mbria]

Wonderful news Alec. Thanks a lot.

Hmm, getting the whole environment duplicated over here unfortunately takes more time than I can invest

I full understand. Any case, the script and the whole environment is now "replicable" for others.
I'm a little surprise nobody else tried to do something similar... if it's done, why nobody published comments, recommendations or a simple howto?
For middle-big scenarios (20-50 magazines) looks like it should be a quite common approach, isn't it?
Sometimes we forget the return to the community and this is a kind of sad.

I generally avoid that sort of involvement, but I'd like to support the work you're doing and that might be the easiest way.

I know we crossed the line some posts ago and all this goes beyond the kind of support once could expect in a free software project and won't exist (at least for free) in a privative one. Thanks a lot for supporting of our work.

but if you're currently working on a non-production environment and would be willing, maybe you could give me a temporary login to tinker with the PHP? ... PM me if that's possible.

I asked today to open a firewall to make it possible. I expect tomorrow the whole thing will be reachable (at least web and ssh).
I will PM you as soon as I see all the stuff working.

Thanks again,
Marc Bria

[mbria]

Hi,

I recently upgrade to OJS 2.3.6 and I noticed the redirections we defined for OJS 2.3.4 are not working now.

If you are using the "multimagazine" script I wrote for OJS 2.3.4, you need to replace the content of the /source/templates/htaccessMagazine.base template with following rules:

Code: Select all

# Rules for magazine %revistaTag%
RewriteRule ^%revistaTag%$ %revistaTag%/
RewriteRule ^%revistaTag%/(.*)$ ojs-%revistaTag%/index.php/%revistaTag%/$1 [L,QSA]
RewriteRule ^ojs-%revistaTag%/%revistaTag%/(.*)$ ojs-%revistaTag%/index.php/%revistaTag%/$1 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ojs-%revistaTag%/(.*)$ ojs-%revistaTag%/index.php/index/$1 [L]


Alec... do you know about any changes in last versions related with this?

I will look further into this, but I just wanted to ask before I squeeze my brain.

Cheers,
m.


that former redirections don't work.

[asmecher]

Hi mbria,

Off the top of my head I don't think there were any changes made that would affect rewriting... Versions 2.3.5 and 2.3.6 are maintenance releases and the changes are almost entirely minor bugfixes. You might try quickly reviewing the patch between the two versions to see if anything around URL processing has changed (http://pkp.sfu.ca/ojs/download/patch/ojs-2.3.4_to_2.3.6.patch.gz).

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Sorry for the silence.

You are right Alec. All works fine. No changes.

Summarizing for those interested in the proposal (or for me if I don't remember how we made it run ):

1) Patch is required: for lib/pkp/classes/session/SessionManager.inc.php

Original code:

Code: Select all

    ini_set('session.cookie_path', $request->getBasePath() . '/');

Replace with:

Code: Select all

    // ini_set('session.cookie_path', $request->getBasePath() . '/');
    ini_set('session.cookie_path', Config::getVar('general', 'session_cookie_path')); //MBR: To allow RESTful with multiple OJS.


2) Add a new variable to your config.inc.php:

Code: Select all

    ; Variable to allow multiple OJS sites with RESTful URLs in a multisite configuration
    session_cookie_path = /


WARNING: Remeber to set RESTful and ALL base urls to fit your needs.

3) Set htaccess rules are as follows:

For a subdomain as http://yoursite.com/ojs-magazineTag/magazineTag

Code: Select all

# Rules for magazine "magazineTag" in an OJS istalled as "ojs-magazineTag"
RewriteRule ^magazineTag$ magazineTag/
RewriteRule ^magazineTag/(.*)$ ojs-magazineTag/index.php/magazineTag/$1 [L,QSA]
RewriteRule ^ojs-magazineTag/magazineTag/(.*)$ ojs-magazineTag/index.php/magazineTag/$1 [L,QSA]


RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ojs-magazineTag/(.*)$ ojs-magazineTag/index.php/index/$1 [L]


For a full domain site as: http://www.yoursite.com/magazineTag

Code: Select all

# Rules for magazine "revistaTag" on domain "www.yoursite.com"
RewriteRule ^revistaTag$ revistaTag/
RewriteRule ^revistaTag/(.*)$ ojs-revistaTag/index.php/revistaTag/$1 [L,QSA]
RewriteRule ^ojs-revistaTag/revistaTag/(.*)$ ojs-revistaTag/index.php/revistaTag/$1 [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ojs-revistaTag/(.*)$ ojs-revistaTag/index.php/index/$1 [L]

RewriteCond %{SERVER_NAME} ^www.yoursite.com
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ revistaTag/$1 [L]


I think that's all.

BTW Alec... I'm really happy with this multiple OJS installation and (from my humble perspective) I recommend it as a good practice for big OJS installations.
I believe is more versatile than the standard one, good performance, site independence (users, templates, plugins...). Do you agree? What about an official wiki page to describe it all?

And until you guys develop a "drush" equivalent for OJS , the script I did really makes my live easier (preconfigured site creation, delete, update, autohtaccess). I'm thinking in improving it to help in backup/restore tasks, better updates, play nice git instead of local copies of OJS source codes, add crontabs... and so on.

I will follow posting here any advance.

As always, thanks A LOT for your help,
m.

[asmecher]

Hi mbria,

Thanks -- this is an ideal kind of contribution for us. We'll be convening some of our development and hosting partners in the coming months as part of our sustainability initiative, and part of that process will involve helping other groups to put together some best practices. We probably have three different hosting options in mind, with something like yours as one of them. Once we start that conversation I'll keep you up to date.

At the least, we can integrate some of the changes you've posted here to facilitate this kind of environment in future releases. I'm scheduling that against version 2.4, which should see release around the end of the second quarter. See http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=7073 for details.

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Thanks alec for the support. If code is compliant with an standard and "symlinked" installations, it will facilitate things a lot.

In this sense, there is still an issue that need to be fixed before everybody could enjoy this fast and easy.

The point is that "/tools" (like upgrade.php or runScheduledTasks.php) are failing when are called from php-cli.

This is the error I get:

Code: Select all

redi:~/ojs# php /home/ojs/htdocs/ojs-dag/tools/runScheduledTasks.php
<h1>DB Error: Access denied for user 'ojs'@'localhost' (using password: YES)</h1>ojs2: DB Error: Access denied for user 'ojs'@'localhost' (using password: YES)

From my understanding, this happens because tools folder is symlinked so php is unable to find the right config.inc.php and perform the tasks.

First and fast solution will be a /tools folder duplications but this is against the idea of code sharing (less caching, code mantainance...) so I was asking myself if /tools code could be patched to suggest a config.inc.php or a working folder.

As always, if you drive me to the right direction, I love to give a first try.

I will improve and update the script to be republish.

About the magazine's script I'm developing, I'm unsure if this is the right approach as far it was done to accomplish the task and not to be elegant or fit well with OJS. I mean that probably a php-cli aplication (like you guys did with "tools") will be better to do the job than a bash-script.

Any case, the script is growing and right now this is what could be done:

Code: Select all

redi:~/ojs/scripts# ./magazine.sh
Syntax: ./magazine.sh <action> <shortname> [<contact-mail> [<owner-name> [<magazine-title>]]]
        <action>: help:      Script syntax.
                  list:      Lists all the magazines of the service.
                  createall: Creates a full ojs-magazine from the BASE template.
                  deleteall: Deletes the folder structure and DB of an ojs-magazine.
                  createdb:  Creates the DB of an ojs-magazine from BASE template.
                  delete:    Backups and deletes the folder structure of an ojs-magazine.
                  htaccess:  Recreates the global htaccess file.
                  crontab:   Recreates the global crontab file.
                  r-links:   Recover symlinks for an specific site (for instance, relinks to ojs-2.3.6 to  instead of ojs-2.3.4)
                  setdomain: Recreates config files to let the magazine respond under a domain like www.example.com
  <magazine-tag>: Short name of the magazine that will be used as an ID
                  (folders and DB) and as an URL (pe: magazine01).
                  Comment: The tag ALL is reserved to operate against every magazine
                  of the system (Not implemented yet).
          <mail>: (opcional) Email prefix (without @uab.cat) of the main magazine contact
                  (Pe: marc.bria)

I like to extend it with backup, restore and upgrade actions.

Please, let me know if somebody wants/needs the last version so I will repackage it all.

Cheers,
m.

[asmecher]

Hi mbria,

I'm continuing to follow this with great interest. Please carry on and when you're ready for a code review I'd be happy to take a look. A bash script is a good way to accomplish this -- you're only excluding Windows platforms and symlinking won't work there anyway.

I've taken a look over the Config and CliTool classes and I don't immediately see why your configuration is not getting picked up. OTOH you should see an error message if it's looking in the wrong place. Could you dump the CONFIG_FILE constant to see where it's trying to load the file from?

Thanks,
Alec Smecher
Public Knowledge Project Team

[mbria]

Thanks Alec.

Let's see if I'm able to explain it fast and easy:

1) Common shared OJS code is at: /home/ojs/source/versions/ojs-2.3.6-redi
2) My specific magazine code is at: /home/ojs/htdocs/ojs-test-config (with tools folder linked to /home/ojs/source/versions/ojs-2.3.6-redi/tools)
3) I modify runSheduledTasks.php to print_r(CONFIG_FILE) as you requested.
4) From "/home/ojs/htdocs/ojs-test-config" directory I run "php tools/runScheduledTasks.php"

This is what I get:

Code: Select all

/home/ojs/source/versions/ojs-2.3.6-redi/config.inc.php
<h1>DB Error: Access denied for user 'ojs'@'localhost' (using password: YES)</h1>ojs2: DB Error: Access denied for user 'ojs'@'localhost' (using password: YES)


Same happens if I call "php /home/ojs/htdocs/ojs-test-config/tools/runScheduledTasks.php".

I don't dig to discover how tools look for the right config.inc.php but looks like they don't resolve symlinks and go directly to the absolute real path.

May be a param for CliTools to specify the config file is the easy and fast way to deal with it?
I will give a first try overwriting CONFIG_FILE at runShecduledTasks.php but it didn't work.
Then I try to overwrite the object as follows:

Code: Select all

$tool->scriptName='/home/ojs/htdocs/ojs-test-config/config.inc.php';

scriptName property is overwriten but I get same results... access deneid to the DB:-(

Thanks again Alec for your the unbelievable support,
m.

PD: I will repackage the full scenario ASAP.

[asmecher]

Hi mbria,

I think I see the problem: it's the INDEX_FILE_LOCATION constant, defined in tools/bootstrap.inc.php for CLI users but defined in index.php for regular web users. Try fixing that to the right location (temporarily -- if this works we can work out a good permanent solution) and see if it fixes the problem.

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

More testing (a deeper one) is required but looks like this little change in bootstrap.inc.php does the job !!

Code: Select all

//define('INDEX_FILE_LOCATION', dirname(dirname(__FILE__)) . '/index.php');
define('INDEX_FILE_LOCATION', realpath(dirname(dirname($_SERVER["SCRIPT_FILENAME"]))). '/index.php');

Pice of cake !!

We are overwhelmed now, but it will look for time to dig deeper into it to see if there is any side effect.

BTW, the "issue" explained: http://blog.eye48.com/post/17154778683/ ... on-learned

Thanks alec,
m.

PD: I'm going to stamp a t-shirt with "Alec is my master". Is there anybody else is interested?

[asmecher]

Hi mbria,

Great, glad to hear that works!

I think the best solution might be to change the way that tools are invoked. Currently the CliTool.inc.php class will chdir into the installation directory (determined using the INDEX_FILE_LOCATION constant, which doesn't work if we're running from a symlinked environment).

If we don't chdir, we can use the getcwd() function to deterine the current directory, which *should* be the directory that contains config.inc.php. Then we can define the INDEX_FILE_LOCATION from that instead. (Instead of calling chdir, CliTool should check to see that config.TEMPLATE.inc.php exists in the current directory; if not, display a "you are not in the right directory" error and exit.)

Does that make sense?

(p.s. I don't think I'd be brave enough to wear one of those t-shirts -- someone might blame me if something goes wrong.)

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Hi Alec,

It makes a lot of sense to me. Let me know if I can help.

Going back to a further point (scripting language), I missed a few comments:

I started the script with bash because I need something running ASAP, but make sense to me a migration to PHP as far as OJS is PHP and (as you pointed) is platform independent. Further more, PHP we can reach OJS api to develop more advanced tasks than install, update or backup...

In other words, this script could be a good starting point but my hope is it will be obsolete when you guys take the idea and extend CliTools to do the magic.

Don't misunderstand me: I'm not giving on it, delegating to you the responsible. I love to follow working on this project but it's obvious that nobody else knows OJS code better than you, so you must take the lead.

Any case, we are not in a hurry and meanwhile I will follow working with this script as a temporary solution for those that like to follow this approach.

Am I talking rubbish? Opinions? Next step?

Cheers,
m.

PD: BTW, after tones of posts and a few years of "virtual relation" you can call me Marc instead of "mbria".

[asmecher]

Hi mbria -- Marc, that is --

I've posted a bug for this and uploaded a proposed solution at http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=7175; this would force tools to be executed from the base directory but would make it more compatible with symlinked environments. Could you see if that patch resolves the problem?

I wouldn't worry overmuch about whether the tool is implemented as a bash script or a PHP script; there are a few shell script tools already in the system. When Windows supports symlinks, then we'll have to get more serious about supporting symlinked environments there...

Thanks,
Alec Smecher
Public Knowledge Project Team

[mbria]

Today I got time to cleanup and package the script... so finally version 1.0 is released:
https://github.com/marcbria/mojo

Sorry a lot for the delay...

Any contribution, feedback or proposal is welcomed.

Cheers,
m.

[mbria]

I just finished 2.3.x translations so today I started with the 2.4.x branch... the point is that the symlinked installation is not working with 2.4.x code although I patched SessionManager, config.inc and bootstrap (as explained previously in this post).

With the new branch I'm unable to login in similar way it happens before (wrong redirection to):
http://revistes.uab.cat/ojs-trad242/log ... 242%2Fuser

And log shows the following error:

Code: Select all

[Tue Jan 22 18:44:42 2013] [error] [client 188.79.95.91] ojs2 has produced an error\n  Message: WARNING: Missing argument 1 for PKPHandler::setupTemplate(), called in /home/ojs/source/versions/ojs-2.4-redi-trad/pages/login/LoginHandler.inc.php on line 121 and defined\n  In file: /home/ojs/source/versions/ojs-2.4-redi-trad/lib/pkp/classes/handler/PKPHandler.inc.php\n  At line: 423\n  Stacktrace: \n  Server info:\n   OS: Linux\n   PHP Version: 5.2.6-1+lenny16\n   Apache Version: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny16 with Suhosin-Patch\n   DB Driver: mysql\n   DB server version: 5.0.51a-24+lenny5, referer: http://revistes.uab.cat/ojs-trad242/login?source=%2Fojs-trad242%2Fuser

I will follow with this tomorrow... trying to discover if I missed something or setupTemplate changes in 2.4 branch.

Meanwhile if somebody (alec? ) has a clue, is really welcomed.

Cheers,
m.