## Installation

by Jeff Taylor -
Number of replies: 7
I have a new setup on a multipurpose server, and seem to have resolved most of the issues, however when I try to select a subject in the library browser I get the error "/webwork2/instructorXMLHandler: Not Found" and problems cannot be added to the current class. From firefox's net panel, I also see that it is getting a 404 trying to read https://<domain>.edu/webwork2/instructorXMLHandler. Of course the file is actually located at /webwork/webwork2/lib/WeBWorK/ContentGenerator/instructorXMLHandler.pm so I'm not sure why a full path isn't being requested or why the path is for webwork2 rather than webwork. I tried adding a symlink to the root folder for webwork2 -> webwork/webwork2/ but that didn't make any difference.

Our installation is accessed via https://<domain>.edu/webwork/. In site.conf I have:

$webwork_url = '/webwork';$server_root_url = 'https://<domain>.edu';

At this point I'm stuck. I don't know if I have a path issue somewhere or if I missed something during the setup, but I haven't been able to find any new info while searching the web that leads me to a solution. Can anyone provide suggestions on what else to look for?

by Michael Gage -
I just noticed that you are using /webwork as segment path to webwork ($webwork_url = '/webwork'; ) The default value is /webwork2 and I notice that the callback is using webwork2 even though you have specified$webwork_url='/webwork';

It's possible that you've found a bug -- your choice of webwork for the segment name should be honored in the callback but there maybe something hardwired in the javascript.

I believe that if you change $webwork_url to /webwork2 temporarily you should be able to test this. You can report bugs to "issues" on github.com/openwebwork/webwork2 or to bugs.webwork.maa.org (or on this forum). In reply to Michael Gage ### Re: /webwork2/instructorXMLHandler: Not Found by Jeff Taylor - Apache was not happy about me trying to change the name like that. I'm guessing maybe apache is supposed to be restarted after making the change to$webwork_url? Unfortunately this is not something I have control over.

Would you be able to point out where webwork is using a hard-coded path? I found a couple of instances under /webwork/webwork2/lib/WeBWorK/ContentGenerator/ and made the following changes:

instructorXMLHandler.pm -> 126
$FORM_ACTION_URL = "$server_root_url/$webwork_url/instructorXMLHandler"; renderViaXMLRPC.pm -> 122$FORM_ACTION_URL = "$server_root_url/$webwork_url/html2xml";

These do not seem to have corrected the problem though. Is this something that requires an Apache restart? Did I use the wrong syntax? Is this not even the right area to be making these changes?

by Michael Gage -
I'm afraid that you do have to restart the server in order for changes in .pm files and sometimes in configuration files such as site.conf to take place immediately. (Those files will be read again when new child process is created, so eventually the changes would show up -- but that is no way to debug the situation.)
sudo apachectl graceful

is a pretty safe command -- it kills inactive processes and restarts new ones but allows the current active process(es) to finish.

The changes you suggest look like the right ones to fix the hard coded bug, but I'll need to do further testing to be sure. Stay tuned.

-- Mike

by Jeff Taylor -
OK I'll send a message off to the server folks to request a restart for the changes in the .pm files. Will let you know how it looks afterwards...

by Michael Gage -
Hi Jeff,

Unfortunately those changes are not going to be enough. There are references to /webwork2 which are hard coded into javaScript files which are
used by the Library browser. (they are in /webwork2/htdocs/js

The javaScript files are not currently checking configurations in site.conf.
They should of course, but I don't have a quick fix to enable this.

Unless there is a good reason not to I suggest that you change your site.conf file
so that $webwork_url='/webwork2'; restart the server and see what happens then. I think that will work better. (You will also want to restore instructorXMLHandler.pm and renderViaXMLRPC.pm to their original versions.) I'll put this issue on the bug fix list and we'll try to sort it out in a future release. In reply to Michael Gage ### Re: /webwork2/instructorXMLHandler: Not Found by Jeff Taylor - I missed your reply this morning until I logged back in, however apache was restarted earlier with the code changes I made above, which generated some ugly errors... Use of uninitialized value$WeBWorK::Constants::PG_DIRECTORY in concatenation (.) or string at /usr/local/adm/config/apache/htdocs/webwork/webwork2/lib/WebworkClient.pm line 109.
Syntax error on line 45 of /usr/local/apache/htdocs/webwork/webwork2/conf/webwork.apache2-config:
Global symbol "$webwork_url" requires explicit package name at /usr/local/adm/config/apache/htdocs/webwork/webwork2/lib/WeBWorK/ContentGenerator/renderViaXMLRPC.pm line 122.\nCompilation failed in require at (eval 459) line 2.\n\t...propagated at /usr/local/perl-5.14.1/lib/5.14.1/base.pm line 94.\nBEGIN failed--compilation aborted at /usr/local/adm/config/apache/htdocs/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/PGProblemEditor3.pm line 20.\nCompilation failed in require at (eval 458) line 2.\nBEGIN failed--compilation aborted at /usr/local/adm/config/apache/htdocs/webwork/webwork2/lib/WeBWorK.pm line 88.\nCompilation failed in require at /usr/local/adm/config/apache/htdocs/webwork/webwork2/lib/Apache/WeBWorK.pm line 37.\nBEGIN failed--compilation aborted at /usr/local/adm/config/apache/htdocs/webwork/webwork2/lib/Apache/WeBWorK.pm line 37.\n So it looks like$webwork_url hasn't been read yet when these two .pm files are loaded into the system. Maybe that's why you had the path hard-coded?

I'll go ahead and change the site.conf path to webwork2, undo the previous changes, and see what happens then...