As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

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.

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).

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.

Last edited by mbria on Wed Apr 25, 2012 10:04 am, edited 1 time in total.

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.

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:

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.

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?

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:

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.

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.)

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".

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...

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).