lib-edocs now edocs
Mark Jordan
We've made lib-edocs.lib.sfu.ca live as edocs.lib.sfu.ca. However, I just went to http://edocs.lib.sfu.ca/collectionsSFU/qubit/ -- all was well until I browsed or searched. Not found... I assume qubit registers the site's base URL and since it was installed on lib-edocs, that base URL doesn't match up any more.
Cc'ing qubit-dev to see if there's a quick fix...
Mark
Mark Jordan
Head of Library Systems
W.A.C. Bennett Library, Simon Fraser University
Burnaby, British Columbia, V5A 1S6, Canada
Voice: 778.782.5753 / Fax: 778.782.3023
mjo...@sfu.ca
Mark Jordan
Jack Bates
Here's the low down, AFAICT: I think the edocs site works with the
script name in the URL: http://edocs.lib.sfu.ca/collectionsSFU/qubit/web/index.php/page/about
- but not with what symfony calls the "no_script_name" URL:
http://edocs.lib.sfu.ca/collectionsSFU/qubit/web/page/about
The app generates URLs according to the "no_script_name" setting in
apps/qubit/config/settings.yml - maybe you could please post your copy
of that file?
The setting is cached in the "prod" environment, so a change requires
clearing the cache: http://qubit-toolkit.org/wiki/index.php?title=Clear_cache
Now, the installer checkHtaccess action should detect whether
"no_script_name" URLs work, enable the setting if so, and disable it
otherwise: http://edocs.lib.sfu.ca/collectionsSFU/qubit/web/index.php/sfInstallPlugin/checkHtaccess
- but I am getting some weird oscillating behavior at that URL. Every
other request, it appears to work, so enables "no_script_name", which
leads to the problem you originally reported. The other requests, it
finds a problem, so disables "no_script_name". The problem it reports
is that Apache Options directives are not allowed in .htaccess files.
However, be this the case, I don't think it should affect
"no_script_name" URLs - if "no_script_name" URLs worked, the installer
would swallow this error.
Basically what concerns me is that the installer should never enable
"no_script_name" unless the following URL prints some magic words:
http://edocs.lib.sfu.ca/collectionsSFU/qubit/web/sfInstallPlugin/callback
It looks to me like that URL never prints the magic words, but
"no_script_name" gets enabled. I couldn't reproduce this on my
workstation. In plugins/sfInstallPlugin/lib/
sfInstall.class.php:checkHtaccess(), it would be helpful to know the
values of $url and $noScriptNameUrl, on the occasions when
checkHtaccess action reports an error and when it reports success.
Also my guess is that in one case it returns on line 319, and in the
other case it returns on line 333 - can you confirm this?
On Mar 6, 10:02 am, Mark Jordan <mjor...@sfu.ca> wrote:
> Sorry guys, I should have added that edocs.lib.sfu.ca is an alias to lib-edocs.lib.sfu.ca.
>
> Mark
>
>
> > Hi Richard,
>
> > We've made lib-edocs.lib.sfu.ca live as edocs.lib.sfu.ca. However, I
> > registers the site's base URL and since it was installed on lib-edocs,
> > that base URL doesn't match up any more.
>
> > Cc'ing qubit-dev to see if there's a quick fix...
>
> > Mark
>
> > Mark Jordan
> > Head of Library Systems
> > W.A.C. Bennett Library, Simon Fraser University
> > Burnaby, British Columbia, V5A 1S6, Canada
> > Voice: 778.782.5753 / Fax: 778.782.3023
Mark Jordan
----- "Jack Bates" <jack....@gmail.com> wrote:
> Oi Mark, this one has me stumped : (
Wow, it's not very often you hear that!
>
> The app generates URLs according to the "no_script_name" setting in
> apps/qubit/config/settings.yml - maybe you could please post your
> copy
> of that file?
attached, as a zip
>
> - but I am getting some weird oscillating behavior at that URL. Every
> other request, it appears to work, so enables "no_script_name", which
> leads to the problem you originally reported. The other requests, it
> finds a problem, so disables "no_script_name". The problem it reports
> is that Apache Options directives are not allowed in .htaccess files.
> However, be this the case, I don't think it should affect
> "no_script_name" URLs - if "no_script_name" URLs worked, the
> installer
> would swallow this error.
>
> Basically what concerns me is that the installer should never enable
> "no_script_name" unless the following URL prints some magic words:
> http://edocs.lib.sfu.ca/collectionsSFU/qubit/web/sfInstallPlugin/callback
>
> It looks to me like that URL never prints the magic words, but
> "no_script_name" gets enabled. I couldn't reproduce this on my
> workstation. In plugins/sfInstallPlugin/lib/
> sfInstall.class.php:checkHtaccess(), it would be helpful to know the
> values of $url and $noScriptNameUrl, on the occasions when
> checkHtaccess action reports an error and when it reports success.
> Also my guess is that in one case it returns on line 319, and in the
> other case it returns on line 333 - can you confirm this?
How would I go about testing this, by simply printing out the variables and hitting the installer URL?
In case it matters, edocs is a simple DNS alias to lib-edocs (IT Services requires that we use 'lib-' on all our servers):
host edocs.lib.sfu.ca
edocs.lib.sfu.ca is an alias for lib-edocs.lib.sfu.ca.
lib-edocs.lib.sfu.ca has address 142.58.211.89
Mark
Jack Bates
> > other request, it appears to work, so enables "no_script_name", which
> > leads to the problem you originally reported. The other requests, it
> > finds a problem, so disables "no_script_name". The problem it reports
> > is that Apache Options directives are not allowed in .htaccess files.
> > However, be this the case, I don't think it should affect
> > "no_script_name" URLs - if "no_script_name" URLs worked, the
> > installer
> > would swallow this error.
>
> > Basically what concerns me is that the installer should never enable
> > "no_script_name" unless the following URL prints some magic words:
> > It looks to me like that URL never prints the magic words, but
> > "no_script_name" gets enabled. I couldn't reproduce this on my
> > workstation. In plugins/sfInstallPlugin/lib/
> > sfInstall.class.php:checkHtaccess(), it would be helpful to know the
> > values of $url and $noScriptNameUrl, on the occasions when
> > checkHtaccess action reports an error and when it reports success.
> > Also my guess is that in one case it returns on line 319, and in the
> > other case it returns on line 333 - can you confirm this?
>
> How would I go about testing this, by simply printing out the variables and hitting the installer URL?
- and maybe hit it a couple times, to see if the values change?
> In case it matters, edocs is a simple DNS alias to lib-edocs (IT Services requires that we use 'lib-' on all our servers):
>
> host edocs.lib.sfu.ca
> edocs.lib.sfu.ca is an alias for lib-edocs.lib.sfu.ca.
> lib-edocs.lib.sfu.ca has address 142.58.211.89
how...
Mark Jordan
Richard just called me and it appears that clearing the cache has made things right. I'll let him confirm however. There are a couple of shell access permissions we have to fix for him but these should not be related to access to the web front end.
If clearing the cache didn't solve all, I'll follow up on the debug stuff.
Mark
Mark Jordan
Head of Library Systems
W.A.C. Bennett Library, Simon Fraser University
Burnaby, British Columbia, V5A 1S6, Canada
Voice: 778.782.5753 / Fax: 778.782.3023
Mark Jordan
----- "Jack Bates" <jack....@gmail.com> wrote:
> >
> > > It looks to me like that URL never prints the magic words, but
> > > "no_script_name" gets enabled. I couldn't reproduce this on my
> > > workstation. In plugins/sfInstallPlugin/lib/
> > > sfInstall.class.php:checkHtaccess(), it would be helpful to know
> the
> > > values of $url and $noScriptNameUrl, on the occasions when
> > > checkHtaccess action reports an error and when it reports
> success.
> > > Also my guess is that in one case it returns on line 319, and in
> the
> > > other case it returns on line 333 - can you confirm this?
> >
> > How would I go about testing this, by simply printing out the
> variables and hitting the installer URL?
>
> Right on, hit this URL:
> http://edocs.lib.sfu.ca/collectionsSFU/qubit/web/index.php/sfInstallPlugin/checkHtaccess
>
Visit the URL above to see the output. I've added
var_dump('<p />$url is ');
var_dump($url);
and
var_dump('<p />$noScriptNameUrl is ');
var_dump($noScriptNameUrl);
Mark
Mark Jordan
Anything else I need to do on my end for this?
Mark
Mark Jordan
Head of Library Systems
W.A.C. Bennett Library, Simon Fraser University
Burnaby, British Columbia, V5A 1S6, Canada
Voice: 778.782.5753 / Fax: 778.782.3023
mjo...@sfu.ca
Jack Bates
installer here on my workstation, and am working on a fix. I think
your site should work in the meantime, so long as you keep the
"no_script_name" setting in apps/qubit/config/settings.yml set to
"off". The installer will incorrectly twiddle this setting until it is
fixed : (
On Mar 16, 12:36 pm, Mark Jordan <mjor...@sfu.ca> wrote:
> Hi Jack,
>
> Anything else I need to do on my end for this?
>
> Mark
>
> Mark Jordan
> Head of Library Systems
> W.A.C. Bennett Library, Simon Fraser University
> Burnaby, British Columbia, V5A 1S6, Canada
> Voice: 778.782.5753 / Fax: 778.782.3023
>
> > > > > It looks to me like that URL never prints the magic words, but
> > > > > "no_script_name" gets enabled. I couldn't reproduce this on my
> > > > > workstation. In plugins/sfInstallPlugin/lib/
> > > > > sfInstall.class.php:checkHtaccess(), it would be helpful to
> > know
> > > the
> > > > > values of $url and $noScriptNameUrl, on the occasions when
> > > > > checkHtaccess action reports an error and when it reports
> > > success.
> > > > > Also my guess is that in one case it returns on line 319, and
> > in
> > > the
> > > > > other case it returns on line 333 - can you confirm this?
>
> > > > How would I go about testing this, by simply printing out the
> > > variables and hitting the installer URL?
>
> > > Right on, hit this URL:
>