Re: [VuFind-General] V3.1.2 the use of an europeana.key

[Demian K. <dem...@vi...>]

> some remarks to the docu:
> if I put a line like this:
> EuropeanaResults:["europeana.eu/api/v2/opensearch.rss"]:["searchTerms"]:["5"]
>                ~~~
> we'll get white screen!
>
> this here seams to work:
> EuropeanaResults = ["europeana.eu/api/v2/opensearch.rss"]:["searchTerms"]:["5"]

I think that this is a problem related to unclear documentation. The brackets are not needed in the configuration string -- they are just there to separate parameters in the syntax guidelines. The brackets are probably causing parse errors in the .ini file, since PHP is fairly strict about this. I think the more correct configuration would be:

EuropeanaResults = "europeana.eu/api/v2/opensearch.rss:searchTerms:5"

Please try that and let me know if it works.

As you say, including more examples in the documentation would make these things easier to understand.

> 2nd notice:
> there are too many possibilities: to view on a log.
> a. we have in apache vufind.conf one line
>  SetEnvIf Request_URI "^/zfl" VUFIND_ENV=development
>
> b. we have apache_error.log (it nothing to do with a.)
>
> c. and we have screen: http(s)://myserver.de/zfl to viewsomething or nothing.
>
> excuse me sir, too much possibilities (my opinion)
>
> ooooh. I forgot:
> d. vufind.log  . more a solar error_log I think....

I apologize for the inconvenience here -- essentially we are dealing with two layers of errors. There are fatal PHP errors, which the VuFind code cannot control, because they cause PHP to terminate (these end up in the Apache error log, though you can make them appear on screen by changing your php.ini and/or Apache settings). Then there is everything else, which VuFind can handle itself -- these are all piped into the same logging mechanism, but that logger can be configured to send the messages to any number of different places, and to filter them in a variety of different ways, depending on preferences. The main obstacle is that, by default, VuFind is configured to hide most error information because, for security reasons, we don't want to accidentally leak any important internal information to end users as part of an error message. (It is safer to turn off verbose messages by default than to trust administrators to remember to turn them off manually). So it takes a bit of work to see all of the important messages. This is something else that should probably be better-documented, though it's largely a question of where to put the notes so that people will actually see them when they need them.

> what is it? a "submit a pull request"?
> in git?

Yes, we use pull requests on GitHub for most of our collaborative development of VuFind. It's a very useful way to share code -- the GitHub tools make it quite easy to discuss and refine changes prior to merging them into the main codebase. If you have not done any work with GitHub before, I would encourage you to look around and read some tutorials -- it is a very powerful tool (and in my opinion, fun to use too!). Of course, if you have questions about anything, I am happy to help... and also, I'm not trying to make more work for you. As I said, I can try to find time to work on some of these things myself... but if you plan on contributing to the project in the future, learning about pull requests will be very useful and will allow your work and suggestions to be incorporated into the project more quickly.

> a view in the doc: (searches.ini)
> it seems, the nomenclatura isn't right:
>
> OpenLibrarySubjects:[GET parameter]:[limit]:[date filter]:[Subject types] it must be written like > this:
> OpenLibrarySubjects = [GET parameter]:[limit]:[date filter]:[Subject types]
>
> best idea: please work WITH ONE example

I don't think the existing line is incorrect -- just unclear. When configuring a recommendation module, the left side of the equation is the type of search that should show the recommendation. The right side is the name of the module, with a colon-delimited set of parameters associated with it. Recommendations can be turned on in two places -- the default section, used when no search-type-specific overrides are defined:

https://github.com/vufind-org/vufind/blob/master/config/vufind/searches.ini#L49

And then the more specific section, where you can override the defaults for specific types of searches (like Title or Author):

https://github.com/vufind-org/vufind/blob/master/config/vufind/searches.ini#L396

Does that make any more sense?

Anyway, I still agree that we should be documenting this more clearly -- perhaps if you now have a better understanding of how it should work, that will help you suggest ways of improving the documentation further.

> and I'm not born with php
> I'm born with (ms)dos 3.3 ;-)
> some personal offtopick, I know ;-)

Ha! If it's any consolation, I also come from DOS land -- though I probably started with 5.0 rather than 3.3. ;-) Web development is specially designed to drive programmers insane, but it has its benefits too. ;-)

> excuse me: but why I'm : the nobody, I'm able to find those all problems. why has no other 
> people found it?

My guess is that you're running into trouble simply because you've found one of the more complicated and less-used features of the software. Most of the more common features already have working examples in the configurations, and thus make it a bit easier to make adjustments.

- Demian