I'm using VuFind 2.3. with Aleph 21 and login is currently not working.
Depending on the services I have selected, I get a different response with a failed login.
We cannot log you in at this time. Please try again later. Is received when I use LDAP or ILS
Invalid login -- please try again. Is received when I use Database.
It seems like the database method is at least working and telling me that the account doesn't exist.
I would like to use LDAP or ILS to authenticate users, what can I do to troubleshoot this to understand where ILS or LDAP configuration changes need to be made?
Thanks,
Mike
Michael Sweeney
Head of Library Systems
University Library, LI-B35A
University at Albany
1400 Washington Avenue
Albany, NY 12222
Phone: 518-442-3638
Fax: 518-442-3088
Email: msweeney2@...<mailto:msweeney2@...>
http://library.albany.edu/

Hello,
Just a heads-up that (as discussed on the previous developers call) I have updated VuFind's master branch to use Solr 4.10.4. I strongly recommend reindexing your records after merging this revision.
Please let me know if you run into any problems -- I plan to do some deeper experimentation with the new version next week, but so far, all tests on the branch-in-progress seemed positive enough to allow this update to go forward.
I'll also soon begin work on a Solr 5 upgrade. I expect that will be more disruptive than this one, so it will probably not happen before the 2.5 release; I expect we'll stick to 4.10.4 for a while, unless another minor point release comes along with important bug fixes.
- Demian

Hello All,
We are in the process of extending the Sierra ILS driver to leverage the new functionality provided by API v2.0. We wanted to reach out and see whether anyone else has done/is doing the same thing, as well as gauge the interest in the resulting code. If anyone is operating in the same realm, please let me know. Thanks!
Brad

Markus,
Sounds like a good plan.
I think perhaps the vendor folder change would be a good thing to consider for VuFind 3.0 -- and I think we're nearing the point of discussing major changes for a potential 3.0 given other factors like Solr 5, etc.
And, of course, as I've said before, I don't envision a VuFind 3.0 as being anywhere near as disruptive a change as VuFind 2.0 was. However, there's an accumulation of potentially disruptive desirable changes that might be less surprising to the user base if they came along with a major version bump.
I think this should be a major theme of this year's VuFind summit, and also something we can begin discussing on the developers calls. Of course, I'll have more to say in the very near future after I have begun experimenting with Solr 5.
- Demian
________________________________
From: Markus Mächler [markus.maechler@...]
Sent: Friday, July 31, 2015 5:23 AM
To: Demian Katz; vufind-tech@...
Subject: Re: [VuFind-Tech] Local composer dependencies
Dear Demian
We discussed the issue this week. We prefer removing the vendor folder and go with only one composer.json file. Since it is a cleaner and a wider spread approach from a developers point of view. I guess it would still be possible to provide downloads of “all in one” packages that include the dependencies.
However since we need a solution for our dependencies now we will go for the approach with a second vendor folder.
We will share any experiences, may it be good or bad ones.
Kind regards
Markus
On 24 Jul 2015, at 13:11, Demian Katz <demian.katz@...<mailto:demian.katz@...>> wrote:
Good points! A couple more things suggested by this:
1.) The problem with relying on composer.lock is that, in my experience, Composer doesn't always respect composer.lock files across versions, and it seems to change fairly rapidly. Having to constantly assist users getting a mysterious "you have a lock file from an old version of Composer" messages is not desirable. However, the idea of bundling a composer.phar file could counteract this potential problem, so that's definitely a good idea!
2.) The other challenge with removing the vendor folder is that developers relying on Git will have to remember to update the dependencies after pulling, just in case something has changed. This creates another source of human error which could waste time and cause confusion. Perhaps this can be offset with some kind of Git hook that automatically runs the composer update after a pull, but I don't have any experience with Git hooks, so I'm not sure how feasible this is, or whether it's possible to make it work properly cross-platform.
Like you, I have not yet concluded which way I prefer -- but honestly I think you've made both options sound more attractive, even though neither is clearly superior in all ways.
- Demian
________________________________
From: Markus Mächler [markus.maechler@...<mailto:markus.maechler@...>]
Sent: Friday, July 24, 2015 3:26 AM
To: vufind-tech@...<mailto:vufind-tech@...>
Subject: Re: [VuFind-Tech] Local composer dependencies
I have not yet concluded which way I would prefer but I can add some points to the discussion.
Make a second vendor folder
-I see your point on Composer’s job to load the most appropriate version of all components. However if there are compatibility issues it is also possible that Composer can not resolve them at all and throws an error. We can not completely avoid that.
- If we use the approach with a second, local composer.json we do not run into merge conflicts with the composer.json and the composer.lock file.
Remove vendor folder from repository
- If we would add our dependencies to the same composer.json as VuFind then the vendor folder definitely needed to be removed from the repository. Otherwise merge conflicts within the vendor folder might occur that can not be resolved.
- As long as the composer.lock is still in the repository we can be sure that the downloaded dependencies work with the current core implementation.
- For less-technical users we could include a composer.phar and provide a shell script that needs to be called that does the entire installation (or it could even be part of a click installer).
Looking forward to hearing some more thoughts on this.
On 22 Jul 2015, at 19:24, Demian Katz <demian.katz@...<mailto:demian.katz@...>> wrote:
Markus,
As you may already be aware, VuFind's use of Composer remains something that I'm a bit conflicted about. On the one hand, the current approach, with dependencies committed to the repository, makes VuFind deployment very simple -- users just check out the repo and go; no need to install or understand Composer. On the other hand, this is certainly not best/common practice -- most projects expect their users to retrieve their own dependencies.
I'm still debating whether VuFind should change to match the more common best practice or whether we should continue on the current course for the sake of our less-technical users.
That issue aside, the solution you propose is an interesting workaround for the current architecture. The problem is that I suspect that it will only work under certain circumstances. Part of Composer's job is to look at the whole dependency tree and load the most appropriate versions of all of the components. I could envision a scenario where a core VuFind dependency and a local dependency both depend on the same third-party component, but each run of composer resolves to a different version of the shared dependency, leading to possible unexpected/broken behavior. This may or may not be likely -- but it's at least possible.
Bottom line: I'm not sure whether it's better to implement this solution (which is a bit complicated and potentially error-prone) or to more strongly consider the possibility of changing VuFind's overall Composer strategy (also a little bit complicated and potentially error-prone, but at least in a more conventional way).
I'm definitely interested to hear your (and others') thoughts on this.
- Demian
-----Original Message-----
From: markus.maechler@...<mailto:markus.maechler@...> [mailto:markus.maechler@...]
Sent: Wednesday, July 22, 2015 10:49 AM
To: vufind-tech@...<mailto:vufind-tech@...>
Subject: [VuFind-Tech] Local composer dependencies
Dear Demian
We recently had the demand for custom composer dependencies that are not in the composer.json file of VuFind core. Our first approach was to simply add it to the composer.json file in the project root directory.
It worked well but we ran into merge conflicts with the composer.json and composer.lock file after VuFind core changed its dependencies as well. We could solve these conflicts each time but we do not think that is the best approach.
To avoid future conflicts and to separate VuFind dependencies from our own dependencies we developed a second approach.
We added a second composer.json file to the folder "local". This gives the following folder structure:
local/composer.json
local/vendor/autoload.php
local/vendor/[custom vendor folders]
In order to make the autoloading work just a few lines need to be added to the index.php file.
If you are interested in including this feature to the core I would be very pleased to create a pull request.
If you or someone else of the vufind-tech list knows a better solution we would be pleased to hear it as well.
Kind regards
Markus
------------------------------------------------------------------------------
_______________________________________________
Vufind-tech mailing list
Vufind-tech@...<mailto:Vufind-tech@...>
https://lists.sourceforge.net/lists/listinfo/vufind-tech

Dear Demian
We discussed the issue this week. We prefer removing the vendor folder and go with only one composer.json file. Since it is a cleaner and a wider spread approach from a developers point of view. I guess it would still be possible to provide downloads of “all in one” packages that include the dependencies.
However since we need a solution for our dependencies now we will go for the approach with a second vendor folder.
We will share any experiences, may it be good or bad ones.
Kind regards
Markus
> On 24 Jul 2015, at 13:11, Demian Katz <demian.katz@...> wrote:
>
> Good points! A couple more things suggested by this:
>
> 1.) The problem with relying on composer.lock is that, in my experience, Composer doesn't always respect composer.lock files across versions, and it seems to change fairly rapidly. Having to constantly assist users getting a mysterious "you have a lock file from an old version of Composer" messages is not desirable. However, the idea of bundling a composer.phar file could counteract this potential problem, so that's definitely a good idea!
>
> 2.) The other challenge with removing the vendor folder is that developers relying on Git will have to remember to update the dependencies after pulling, just in case something has changed. This creates another source of human error which could waste time and cause confusion. Perhaps this can be offset with some kind of Git hook that automatically runs the composer update after a pull, but I don't have any experience with Git hooks, so I'm not sure how feasible this is, or whether it's possible to make it work properly cross-platform.
>
> Like you, I have not yet concluded which way I prefer -- but honestly I think you've made both options sound more attractive, even though neither is clearly superior in all ways.
>
> - Demian
> From: Markus Mächler [markus.maechler@...]
> Sent: Friday, July 24, 2015 3:26 AM
> To: vufind-tech@...
> Subject: Re: [VuFind-Tech] Local composer dependencies
>
> I have not yet concluded which way I would prefer but I can add some points to the discussion.
>
> Make a second vendor folder
> -I see your point on Composer’s job to load the most appropriate version of all components. However if there are compatibility issues it is also possible that Composer can not resolve them at all and throws an error. We can not completely avoid that.
>
> - If we use the approach with a second, local composer.json we do not run into merge conflicts with the composer.json and the composer.lock file.
>
> Remove vendor folder from repository
> - If we would add our dependencies to the same composer.json as VuFind then the vendor folder definitely needed to be removed from the repository. Otherwise merge conflicts within the vendor folder might occur that can not be resolved.
>
> - As long as the composer.lock is still in the repository we can be sure that the downloaded dependencies work with the current core implementation.
>
> - For less-technical users we could include a composer.phar and provide a shell script that needs to be called that does the entire installation (or it could even be part of a click installer).
>
> Looking forward to hearing some more thoughts on this.
>
>
>> On 22 Jul 2015, at 19:24, Demian Katz <demian.katz@... <mailto:demian.katz@...>> wrote:
>>
>> Markus,
>>
>> As you may already be aware, VuFind's use of Composer remains something that I'm a bit conflicted about. On the one hand, the current approach, with dependencies committed to the repository, makes VuFind deployment very simple -- users just check out the repo and go; no need to install or understand Composer. On the other hand, this is certainly not best/common practice -- most projects expect their users to retrieve their own dependencies.
>>
>> I'm still debating whether VuFind should change to match the more common best practice or whether we should continue on the current course for the sake of our less-technical users.
>>
>> That issue aside, the solution you propose is an interesting workaround for the current architecture. The problem is that I suspect that it will only work under certain circumstances. Part of Composer's job is to look at the whole dependency tree and load the most appropriate versions of all of the components. I could envision a scenario where a core VuFind dependency and a local dependency both depend on the same third-party component, but each run of composer resolves to a different version of the shared dependency, leading to possible unexpected/broken behavior. This may or may not be likely -- but it's at least possible.
>>
>> Bottom line: I'm not sure whether it's better to implement this solution (which is a bit complicated and potentially error-prone) or to more strongly consider the possibility of changing VuFind's overall Composer strategy (also a little bit complicated and potentially error-prone, but at least in a more conventional way).
>>
>> I'm definitely interested to hear your (and others') thoughts on this.
>>
>> - Demian
>>
>> -----Original Message-----
>> From: markus.maechler@... <mailto:markus.maechler@...> [mailto:markus.maechler@... <mailto:markus.maechler@...>]
>> Sent: Wednesday, July 22, 2015 10:49 AM
>> To: vufind-tech@... <mailto:vufind-tech@...>
>> Subject: [VuFind-Tech] Local composer dependencies
>>
>> Dear Demian
>>
>> We recently had the demand for custom composer dependencies that are not in the composer.json file of VuFind core. Our first approach was to simply add it to the composer.json file in the project root directory.
>> It worked well but we ran into merge conflicts with the composer.json and composer.lock file after VuFind core changed its dependencies as well. We could solve these conflicts each time but we do not think that is the best approach.
>>
>> To avoid future conflicts and to separate VuFind dependencies from our own dependencies we developed a second approach.
>> We added a second composer.json file to the folder "local". This gives the following folder structure:
>>
>> local/composer.json
>> local/vendor/autoload.php
>> local/vendor/[custom vendor folders]
>>
>> In order to make the autoloading work just a few lines need to be added to the index.php file.
>>
>> If you are interested in including this feature to the core I would be very pleased to create a pull request.
>> If you or someone else of the vufind-tech list knows a better solution we would be pleased to hear it as well.
>>
>> Kind regards
>> Markus
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Vufind-tech mailing list
>> Vufind-tech@... <mailto:Vufind-tech@...>
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech

Thanks Demian. That did the trick. I realized that I also had to make one
pattern map per variable. So the fixed code is:
pub_source_txt = 500a, (pattern_map.pubsource)
pattern_map.pubsource.pattern_0 =Source note\\:\\ (.*)=>$1
pub_type_txtF = 500a, (pattern_map.pubtype)
pattern_map.pubtype.pattern_0 =Publication type\\:\\ (.*)=>$1
-Leila
*From:* Demian Katz [mailto:demian.katz@...]
*Sent:* Thursday, July 30, 2015 11:31 AM
*To:* Leila Gonzales; vufind-tech@...
*Subject:* RE: [VuFind-Tech] Pattern map for text string with colon
At least part of the issue is that, when you use $1, you need to put part
of your regular expression in parentheses to “capture” the value of $1.
Note the existing OCLC number patterns:
pattern_map.oclc_num.pattern_0 =
\\([Oo][Cc][Oo][Ll][Cc]\\)[^0-9]*[0]*([0-9]+)=>$1
<file:///\\([Oo][Cc][Oo][Ll][Cc]\)%5b%5e0-9%5d*%5b0%5d*(%5b0-9%5d+)=%3e$1&gt;
pattern_map.oclc_num.pattern_1 = ocm[0]*([0-9]+)[ ]*[0-9]*=>$1
pattern_map.oclc_num.pattern_2 = ocn[0]*([0-9]+).*=>$1
pattern_map.oclc_num.pattern_3 = on[0]*([0-9]+).*=>$1
See how each of these has parentheses around the [0-9]+ part? That’s how
we’re pulling the numeric portion out of the overall string.
If you add parentheses to the appropriate portions of your patterns, that
may solve the problem… and if it doesn’t, it may just indicate there’s
another minor syntax error to fix. I’m a bit suspicious that you may not
want the backslash in front of the second [ ].* unless you really do want
to match the literal bracket instead of whitespace. It’s possible that
changing both instances of “[ ]” to “\\s <file:///\\s&gt;” might be helpful
too.
- Demian
*From:* Leila Gonzales [mailto:lmg@... <lmg@...>]
*Sent:* Thursday, July 30, 2015 2:14 PM
*To:* vufind-tech@...
*Subject:* [VuFind-Tech] Pattern map for text string with colon
Hi all,
I have three pieces of information stored consecutively in field 500a:
notes, source info, and pub type. The source info and pub type always have
prefix text attached to their fields.
I’m using a pattern map in my marc_local.properties file, but the
pub_source_txt and pub_type_txtF fields are not loading into the solr
database. I think the issue is with my pattern map, but am not sure how to
match and remove the strings (including the trailing space) “Source note: “
and “Publication type: “ as I index those fields.
Here’s the excerpt from my marc_local.properties file:
pub_notes_txt = 500a, first
pub_source_txt = 500a, (pattern_map.pubsource)
pub_type_txtF = 500a, (pattern_map.pubsource)
pattern_map.pubsource.pattern_0 =Source[ ]+note\\:\\[ ].*=>$1
pattern_map.pubsource.pattern_1 =Publication[ ]+type\\:\\[ ].*=>$1
Thanks for your help!
Leila

At least part of the issue is that, when you use $1, you need to put part of your regular expression in parentheses to “capture” the value of $1. Note the existing OCLC number patterns:
pattern_map.oclc_num.pattern_0 = \\([Oo][Cc][Oo][Ll][Cc]\\)[^0-9]*[0]*([0-9]+)=>$1
pattern_map.oclc_num.pattern_1 = ocm[0]*([0-9]+)[ ]*[0-9]*=>$1
pattern_map.oclc_num.pattern_2 = ocn[0]*([0-9]+).*=>$1
pattern_map.oclc_num.pattern_3 = on[0]*([0-9]+).*=>$1
See how each of these has parentheses around the [0-9]+ part? That’s how we’re pulling the numeric portion out of the overall string.
If you add parentheses to the appropriate portions of your patterns, that may solve the problem… and if it doesn’t, it may just indicate there’s another minor syntax error to fix. I’m a bit suspicious that you may not want the backslash in front of the second [ ].* unless you really do want to match the literal bracket instead of whitespace. It’s possible that changing both instances of “[ ]” to “\\s” might be helpful too.
- Demian
From: Leila Gonzales [mailto:lmg@...]
Sent: Thursday, July 30, 2015 2:14 PM
To: vufind-tech@...
Subject: [VuFind-Tech] Pattern map for text string with colon
Hi all,
I have three pieces of information stored consecutively in field 500a: notes, source info, and pub type. The source info and pub type always have prefix text attached to their fields.
I’m using a pattern map in my marc_local.properties file, but the pub_source_txt and pub_type_txtF fields are not loading into the solr database. I think the issue is with my pattern map, but am not sure how to match and remove the strings (including the trailing space) “Source note: “ and “Publication type: “ as I index those fields.
Here’s the excerpt from my marc_local.properties file:
pub_notes_txt = 500a, first
pub_source_txt = 500a, (pattern_map.pubsource)
pub_type_txtF = 500a, (pattern_map.pubsource)
pattern_map.pubsource.pattern_0 =Source[ ]+note\\:\\[ ].*=>$1
pattern_map.pubsource.pattern_1 =Publication[ ]+type\\:\\[ ].*=>$1
Thanks for your help!
Leila

Hi all,
I have three pieces of information stored consecutively in field 500a:
notes, source info, and pub type. The source info and pub type always have
prefix text attached to their fields.
I’m using a pattern map in my marc_local.properties file, but the
pub_source_txt and pub_type_txtF fields are not loading into the solr
database. I think the issue is with my pattern map, but am not sure how to
match and remove the strings (including the trailing space) “Source note: “
and “Publication type: “ as I index those fields.
Here’s the excerpt from my marc_local.properties file:
pub_notes_txt = 500a, first
pub_source_txt = 500a, (pattern_map.pubsource)
pub_type_txtF = 500a, (pattern_map.pubsource)
pattern_map.pubsource.pattern_0 =Source[ ]+note\\:\\[ ].*=>$1
pattern_map.pubsource.pattern_1 =Publication[ ]+type\\:\\[ ].*=>$1
Thanks for your help!
Leila

Hi André,
thanks for your help and suggestions.
Regarding using the new driver:
> Please pay attention to the fact that the DAIA driver needs to be
> initialized in the Factory now as the DateConverter is passed to the
> constructor now.
> This means you would have to copy the complete DAIA driver from my repo
> and alter your current VuFind's
> module/VuFind/src/VuFind/ILS/Driver/Factory.php and
> module/VuFind/config/module.config.php accordingly.
> If you need any assistance, please let me know - I am happy to give you
> a hand with this.
I downloaded the driver and added DAIA to the Factory.php and the
'factories' block in module.config.php#L366. I commented out DAIA under
invokables and it works.
1) Holdings tab is shown although hideHoldingsTabWhenEmpty = true
I investigated further and there are multiple cases that need to be
considered as I am using a local shard and the GBV shards.
- For the local shard: It seems that either in the conversion process
from PICA to MARC or the import process leading zeros are being dropped
from the ppn and letters are transformed to lower case. I need to
investigate this on our end. So basically the DAIA server does not know
the item and returns a brief XML construct with an error message. I
wonder if this return results in an empty holdings tab (happens with the
new driver as well).
- For the GBV shards: As I am using an ISIL to in my request to the DAIA
server, it is obvious why there are holdings for most items. Still it
seems to be a similar issue that a brief XML construct with an error
message is returned.
I guess only using the local shard, after fixing the import issue, or
the GBV shard with a filter set to only show our Institution would
result in having no empty holdings tabs. However, I think that it might
be good cover such an error condition, just in case it occurs, either by
hiding the tab or providing some form of message that the availability
cannot be checked for this item.
Example would be: http://daia.gbv.de/isil/DE-84/?id=ppn:50142590x&format=xml
(capitalising the X at the end of the ppn solves the problem)
I see that a printout to the log is happening directly from the init
funtion while other logs are passed through logMessages which do not
seem to appear in my log.
parseDaiaArray contains an if statement to pass on message outputs to
logMessages, hower parseDaiaArray is not called because parseDaiaDoc is
not being as there is no document tag/node in the Daia return. So it
would be good to move a statement like this into the extractDaiaDoc
function and put it after "if (count($docs)) {". Tried to do that, but I
can only get it put all content of the array into the log or nothing.
Seems I am handling the array incorrectly. Without taking multiQuery
into consideration this should work, but it does not:
if (array_key_exists("message", $docs)) {
$this->logMessages($docs, "document");
}
(I will look into the empty tab problem tomorrow and see if there is
something passed on to VuFind/RecordTab/Factory.php (l. 147-154) that
explains the issue. Maybe introducing another condition there would do
the trick to avoid empty tabs.
2) Discrepancies between results list and holdings tab
> This is actually a theme/template issue: the standard VuFind-behavior is
> to show ILS-availability only if OpenURL/URLs are not present/active for
> the current record. So this applies to every ILS, but you can change
> this by altering the template:
> https://github.com/vufind-org/vufind/blob/master/themes/bootstrap3/templates/RecordDriver/SolrDefault/result-list.phtml#L139
Thanks, I removed part of the conditions in result-list.phtml and this
has been fixed.
3) Error message "Trying to get property of non-object"
>
> Yes this should be resolved with the latest DAIA driver as well. This is
> again an issue of some legacy XML-parsing which got completely removed
> in the above mentioned driver.
The error message has disappeared. Great!
However I noticed that now a lot of records show "Unknown" as location
instead of the location that was shown before, see attached file with
examples. Looking at the DAIA XML return I can see what happened. The
old version of the driver also used the department tag for location.
I guess the question is whether the department tag is a good substitute
if the storage tag is not available. For my purposes I added it as an
elseif for now.
Another question: What does the multiquery setting do? (It seems to be
new compared to the previous DAIA settings and driver?!)
All the best
Kristof
Am 29.07.2015 um 14:57 schrieb André Lahmann:
> Hi Kristof,
>
> the DAIA driver along with a PAIA driver is under active development by
> Jochen Lienhard, Till Kinstler and me in this github branch :
>
> https://github.com/lahmann/vufind/tree/paia-driver
>
> Since VuFind's latest official release it has undergone some significant
> changes and I suggest to try this driver instead (as it also reflects
> some of the latest changes in the DAIA specification -
> http://gbv.github.io/daiaspec/daia.html).
> Please pay attention to the fact that the DAIA driver needs to be
> initialized in the Factory now as the DateConverter is passed to the
> constructor now.
> This means you would have to copy the complete DAIA driver from my repo
> and alter your current VuFind's
> module/VuFind/src/VuFind/ILS/Driver/Factory.php and
> module/VuFind/config/module.config.php accordingly.
> If you need any assistance, please let me know - I am happy to give you
> a hand with this.
>
> Am 29.07.2015 um 13:21 schrieb Kristof Kessler:
>> Dear all,
>>
>> I have been experimenting with DAIA and have some things I wanted to
>> discuss. If you need more information about how certain parameters are
>> configured, let me know.
>>
>> 1) Holdings tab is shown although hideHoldingsTabWhenEmpty = true
>> Example: http://vufind.allegro-c.de:81/vufind241/Record/018649963
>
> I can confirm this behavior although I wonder if it's actually a DAIA
> issue. The setting-checking code in VuFind/RecordTab/Factory.php (l.
> 147-154) looks a bit odd, but I have to admit I haven't looked that deep
> into this HoldingsTab-hiding functionality.
> Maybe Demian can share some insight how this is supposed to work.
>
>> 2) Discrepancies between results list and holdings tab (I wonder whether
>> this an issue with my configuration or the DAIA server?!)
>> ---------
>> 2.1) No availability status shown in result list, but availability shown
>> in holdings tab
>
> This is actually a theme/template issue: the standard VuFind-behavior is
> to show ILS-availability only if OpenURL/URLs are not present/active for
> the current record. So this applies to every ILS, but you can change
> this by altering the template:
> https://github.com/vufind-org/vufind/blob/master/themes/bootstrap3/templates/RecordDriver/SolrDefault/result-list.phtml#L139
>
>> 2.2) Shown as unavailable in results list, but as available in holdings tab
>
> This is definitely odd, by I guess it is related to the different
> handling of getStatus and getStatuses in the DAIA ILS-driver as a result
> to legacy support. Please try the above referred DAIA ILS-driver and let
> me know if this behaves the same.
>
>
>> 3) Error message "Trying to get property of non-object"
>
> Yes this should be resolved with the latest DAIA driver as well. This is
> again an issue of some legacy XML-parsing which got completely removed
> in the above mentioned driver.
>
>> 4) Distinction between presentation, loan and interloan
>> ---------
>> Taking the same example as under 3, when checking the DAIA server and
>> OPAC, then it becomes clear that these copies are onlz for presentation.
>> I suppose I can make some changes to the holdingsils.phtml to make such
>> distinctions, correct?
>
> This is one possibility, the more accurate (imo) would be to create a
> custom DAIA ILS-driver (based on the above referred DAIA driver) and
> overwrite the getItemStatus() method applying the mapping for
> availability etc. as you need it.
>
>> One other question in this respect: I have not
>> seen any reference to holdings in result-list.phtml, so how is the
>> availabilty status being called in the result list?
>
> The availability status in the result list is being called via AJAX. So
> for your example 2.2 the status for the three records is called after
> the result list is loaded:
> http://vufind.allegro-c.de:81/vufind241/AJAX/JSON?method=getItemStatuses&id%5B%5D=520686810&id%5B%5D=24806973x&id%5B%5D=326376429
>
> I plan to create a pull request for the DAIA driver from the above
> referred paia-driver branch by the end of this week. So I would be very
> happy if you could test the driver and report your results.
>
> Let me know if you need help.
>
> Best,
> André Lahmann
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VuFind-General mailing list
> VuFind-General@...
> https://lists.sourceforge.net/lists/listinfo/vufind-general
>
--
Mit besten Grüßen
Kristof Keßler
Universitätsbibliothek Braunschweig
-Fachinformationsdienst Pharmazie-
Pockelsstr. 13
38106 Braunschweig
Tel.: +49 531 391 5027

You should be able to log fatal exceptions like this using the [Logging] section of config.ini:
https://github.com/vufind-org/vufind/blob/master/config/vufind/config.ini#L894
I believe these will be treated as an “error” level, so something like:
[Logging]
file=/var/log/vufind.log:alert,error
should do the job.
Also, if you need to troubleshoot this sort of problem in-browser, it is helpful to uncomment the “development mode” line in local/httpd-vufind.conf and restart Apache in order to see full exception dumps and backtraces.
Regarding the problem with import-marc.sh after the upgrade, I can’t think of an obvious reason for that off the top of my head. Perhaps it would be helpful to create a wrapper script for use by your cron job… something like:
#!/bin/sh
export PATH=/bin:/usr/bin
export VUFIND_HOME=/usr/local/vufind2
export VUFIND_LOCAL_DIR=$VUFIND_HOME/local
cd $VUFIND_HOME
./import-marc.sh etc., etc. > /var/log/import-log 2>&1
This way you can have full control over the environment variables and can see a log file for troubleshooting purposes.
- Demian
From: Melis özmen [mailto:melisozmenn@...]
Sent: Thursday, July 30, 2015 8:54 AM
To: Demian Katz
Cc: vufind-tech@...
Subject: Re: [VuFind-Tech] /vufind/Author/Home error
Hello Demian,
Thank you. Thank you. Thank You..
I comment the line below from config.ini.. And everything works well...
authors = Wikipedia
It would be excellent if I see these kind of errors from some log file..
----------
Can I ask you another question?
I upgraded vufind 2 weeks ago.
Not sure about versions but from 2.x to latest
After all, my import-marc cronjob (and maybe alpha browse) does not work anymore. I changed cronjob like this.
Before:
cd /usr/local/vufind2 && ./import-marc.sh -p /usr/local/vufind2/local/import/import.properties /usr/local/vufind2/koha.mrc
After:
/usr/lib/jvm/java-7-openjdk-amd64//bin/java -Xms512m -Xmx512m -DentityExpansionLimit=0 -Duser.timezone=UTC -Dsolr.core.name<http://Dsolr.core.name>=biblio -jar /usr/local/vufind2/import/SolrMarc.jar /usr/local/vufind2/koha.mrc
import-marc.sh 775 file permission, and root owner. and root runs cronjob though..
On Thu, Jul 30, 2015 at 3:34 PM, Demian Katz <demian.katz@...<mailto:demian.katz@...>> wrote:
Do you have Wikipedia authors turned on? If so, it is possible that the problem has to do with your VuFind instance missing configuration for SSL certificates – when the HTTP client attempts to retrieve data from Wikipedia, it will fail if it is unable to validate the SSL certificate. You can solve this either by turning off Wikipedia or by configuring the [Http] section of config.ini. Some notes on recommended configurations can be found here:
https://github.com/vufind-org/vufind/blob/master/config/vufind/config.ini#L832
Please let me know if you still need further assistance!
- Demian
From: Melis özmen [mailto:melisozmenn@...<mailto:melisozmenn@...>]
Sent: Thursday, July 30, 2015 6:26 AM
To: vufind-tech@...<mailto:vufind-tech@...>
Subject: [VuFind-Tech] /vufind/Author/Home error
Hello,
I got "An error occured" message when I click book's author link.
.../vufind/Author/Home?author=Barba%2C+Eugenio.
When I turn the debug mode on, there is nothing seems look like an error.. (I guess)
2015-07-30T12:56:13+03:00 DEBUG: VuFindSearch\Backend\Solr\Connector: Query fl=%2A%2Cscore&spellcheck=false&facet=true&facet.limit=30&facet.field=topic_facet&facet.sort=count&facet.mincount=1&sort=score+desc&hl=true&hl.fl=%2A&hl.simple.pre=%7B%7B%7B%7BSTART_HILITE%7D%7D%7D%7D&hl.simple.post=%7B%7B%7B%7BEND_HILITE%7D%7D%7D%7D&wt=json&json.nl<http://json.nl>=arrarr&rows=20&start=0&qf=author%5E100+author_fuller%5E50+author2+author_additional&qt=dismax&q=%22Barba%2C+Eugenio.%22
2015-07-30T12:56:13+03:00 DEBUG: VuFindSearch\Backend\Solr\Connector: => GET http://localhost:8080/solr/biblio/select?fl=%2A%2Cscore&spellcheck=false&facet=true&facet.limit=30&facet.field=topic_facet&facet.sort=count&facet.mincount=1&sort=score+desc&hl=true&hl.fl=%2A&hl.simple.pre=%7B%7B%7B%7BSTART_HILITE%7D%7D%7D%7D&hl.simple.post=%7B%7B%7B%7BEND_HILITE%7D%7D%7D%7D&wt=json&json.nl=arrarr&rows=20&start=0&qf=author%5E100+author_fuller%5E50+author2+author_additional&qt=dismax&q=%22Barba%2C+Eugenio.%22
2015-07-30T12:56:13+03:00 DEBUG: VuFindSearch\Backend\Solr\Connector: <= 200 OK
2015-07-30T12:56:13+03:00 DEBUG: Deserialized SOLR response
Meanwhile, there is no problem when I browse authors.
This was working well yesterday, but this morning I re-indexed all records again with
./import-marc.sh and run ./index-alphabetic-browse.sh
I removed the files below before indexing process
/usr/local/vufind2/solr/biblio/index
/usr/local/vufind2/solr/biblio/spell*
/usr/local/vufind2/solr/alphabetical_browse/*
Thanks in advance,
Melis