We are building the XSLT paths with intrahtdocs, it should be intranetdir (and assume that have the usual git structure)
Created attachment 100589 [details] [review] Bug 24852: Adjust XSLT paths for dev installs We are building the XSLT paths with intrahtdocs, it should be intranetdir (and assume that have the usual git structure). For instance, on a dev box, the XSLT base path was outside of the git repo: /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/xslt/ Now it will be: /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/xslt/ Test plan: 0. Do not apply the patch, set dev_install to 1 in $KOHA_CONF 1. Modify a xslt in the git repo, and in the "htdocs" path, in a different way: /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl 2. Restart all the things and refresh a bibliographic record detail page Notice that you see the change from the "htdocs", outside of the git repo 3. Apply the patch 4. Repeat 2. Notice that you now see the change you made on the file from the git repo 5. Set dev_install to 0 in $KOHA_CONF 6. Repeat 2. Notice that you now see the change from htdocs
We need that, right?
(In reply to Jonathan Druart from comment #2) > We need that, right? Yes
Do we need more? For a gitify I am doing this for koha-conf: s/koha\/opac\/cgi-bin\/opac/koha\/opac/ s/koha\/opac\/htdocs/koha\/koha-tmpl/ s/koha\/intranet\/cgi-bin/koha/ s/koha\/intranet\/htdocs/koha\/koha-tmpl/ s/doc\/koha-common/koha\/docs/ s/bin\/cronjobs/misc\/cronjobs/
Maybe, I do not know exactly what is missing. In debian scripts we are testing the dev_install config flag, so I think it makes sense to test it from the code as well. Or we go backward, remove the specific paths and adjust KOHA_CONF?
(In reply to Jonathan Druart from comment #5) > Maybe, I do not know exactly what is missing. > In debian scripts we are testing the dev_install config flag, so I think it > makes sense to test it from the code as well. > > Or we go backward, remove the specific paths and adjust KOHA_CONF? I am open for both solutions. From a maintenance perspective it may be easier to adjust some koha-conf paths in a Dockerfile or so than duplicating code in various places. Note that the dev_install flag helped us to run the debian scripts as-is without gitifying them as well.
I never liked the way we specify things in the koha-conf.xml file :-D If we did that, we would need: intrahtdocs intracgidir opachtdocs opaccgidir and why not something for the API as well...
(In reply to Tomás Cohen Arazi from comment #7) > I never liked the way we specify things in the koha-conf.xml file :-D > > If we did that, we would need: > intrahtdocs > intracgidir > opachtdocs > opaccgidir > and why not something for the API as well... I have the impression that you did not understand me or vice versa :)
I have the feeling that we are going to far. I would go for this patch, it's simple and written. Then we can discuss something bigger on a separate bug report?
(In reply to Marcel de Rooy from comment #8) > (In reply to Tomás Cohen Arazi from comment #7) > > I never liked the way we specify things in the koha-conf.xml file :-D > > > > If we did that, we would need: > > intrahtdocs > > intracgidir > > opachtdocs > > opaccgidir > > and why not something for the API as well... > > I have the impression that you did not understand me or vice versa :) I understand what you propose and I like it. I just took the chance to say I never liked our current config. And I love the dev_install thing.
(In reply to Jonathan Druart from comment #9) > I have the feeling that we are going to far. I would go for this patch, it's > simple and written. Then we can discuss something bigger on a separate bug > report? Well, this would be the first occurrence in a perl module. So it is not only a matter of "I wrote it already".
I do not want to overthink this patch. Feel free to suggest something if you think it's not good enough for a first step.
Just saying, that's definitely a bug. It works for the OPAC, only. Please suggest something if you disagree with this patch.
(In reply to Jonathan Druart from comment #13) > Just saying, that's definitely a bug. It works for the OPAC, only. > > Please suggest something if you disagree with this patch. I dont object to it. But former comments still apply.
(In reply to Marcel de Rooy from comment #14) > (In reply to Jonathan Druart from comment #13) > > Just saying, that's definitely a bug. It works for the OPAC, only. > > > > Please suggest something if you disagree with this patch. > > I dont object to it. But former comments still apply. Which ones? The one where you ask if we need more paths?
(In reply to Jonathan Druart from comment #15) > (In reply to Marcel de Rooy from comment #14) > > (In reply to Jonathan Druart from comment #13) > > > Just saying, that's definitely a bug. It works for the OPAC, only. > > > > > > Please suggest something if you disagree with this patch. > > > > I dont object to it. But former comments still apply. > > Which ones? The one where you ask if we need more paths? 6/11
> 2. Restart all the things and refresh a bibliographic record detail page > Notice that you see the change from the "htdocs", outside of the git repo That's puzzling, I see the git repo version. Can't find the issue after double checking. > 6. Repeat 2. > Notice that you now see the change from htdocs Still git version. So with and without the patch. With dev_install 1 and dev_install 0, I always see the git repo version. A diff between the two files confirmed the difference. Does anyone else has the same issue?
(In reply to Victor Grousset/tuxayo from comment #17) > So with and without the patch. With dev_install 1 and dev_install 0, I > always see the git repo version. > A diff between the two files confirmed the difference. > > Does anyone else has the same issue? Hum indeed. There is something that changed somewhere but I cannot find what/where. So there is still an issue but less important. Marking as won't fix (for now at least).