You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(5) |
Sep
(39) |
Oct
(18) |
Nov
(16) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(15) |
Feb
(90) |
Mar
(41) |
Apr
(129) |
May
(69) |
Jun
(112) |
Jul
(153) |
Aug
(82) |
Sep
(95) |
Oct
(111) |
Nov
(39) |
Dec
(50) |
2009 |
Jan
(11) |
Feb
(63) |
Mar
(51) |
Apr
(45) |
May
(68) |
Jun
(84) |
Jul
(114) |
Aug
(149) |
Sep
(259) |
Oct
(179) |
Nov
(132) |
Dec
(87) |
2010 |
Jan
(59) |
Feb
(88) |
Mar
(145) |
Apr
(130) |
May
(24) |
Jun
(36) |
Jul
(143) |
Aug
(94) |
Sep
(125) |
Oct
(142) |
Nov
(100) |
Dec
(103) |
2011 |
Jan
(76) |
Feb
(105) |
Mar
(145) |
Apr
(112) |
May
(74) |
Jun
(157) |
Jul
(95) |
Aug
(191) |
Sep
(75) |
Oct
(91) |
Nov
(100) |
Dec
(102) |
2012 |
Jan
(100) |
Feb
(126) |
Mar
(97) |
Apr
(74) |
May
(161) |
Jun
(135) |
Jul
(161) |
Aug
(132) |
Sep
(266) |
Oct
(212) |
Nov
(114) |
Dec
(87) |
2013 |
Jan
(101) |
Feb
(254) |
Mar
(236) |
Apr
(244) |
May
(144) |
Jun
(156) |
Jul
(203) |
Aug
(242) |
Sep
(118) |
Oct
(206) |
Nov
(140) |
Dec
(108) |
2014 |
Jan
(141) |
Feb
(88) |
Mar
(167) |
Apr
(61) |
May
(109) |
Jun
(105) |
Jul
(218) |
Aug
(125) |
Sep
(152) |
Oct
(217) |
Nov
(129) |
Dec
(63) |
2015 |
Jan
(121) |
Feb
(78) |
Mar
(156) |
Apr
(92) |
May
(91) |
Jun
(118) |
Jul
(114) |
Aug
(236) |
Sep
(75) |
Oct
(112) |
Nov
(106) |
Dec
(74) |
2016 |
Jan
(121) |
Feb
(165) |
Mar
(127) |
Apr
(145) |
May
(142) |
Jun
(113) |
Jul
(66) |
Aug
(61) |
Sep
(46) |
Oct
(120) |
Nov
(59) |
Dec
(49) |
2017 |
Jan
(67) |
Feb
(55) |
Mar
(79) |
Apr
(28) |
May
(49) |
Jun
(50) |
Jul
(119) |
Aug
(72) |
Sep
(40) |
Oct
(45) |
Nov
(66) |
Dec
(60) |
2018 |
Jan
(63) |
Feb
(52) |
Mar
(48) |
Apr
(52) |
May
(60) |
Jun
(41) |
Jul
(78) |
Aug
(63) |
Sep
(46) |
Oct
(48) |
Nov
(17) |
Dec
(21) |
2019 |
Jan
(74) |
Feb
(78) |
Mar
(46) |
Apr
(42) |
May
(49) |
Jun
(15) |
Jul
(50) |
Aug
(16) |
Sep
(49) |
Oct
(63) |
Nov
(14) |
Dec
(11) |
2020 |
Jan
(36) |
Feb
(31) |
Mar
(36) |
Apr
(9) |
May
(92) |
Jun
(42) |
Jul
(29) |
Aug
(29) |
Sep
(66) |
Oct
(13) |
Nov
(29) |
Dec
(14) |
2021 |
Jan
(8) |
Feb
(34) |
Mar
(30) |
Apr
(14) |
May
(17) |
Jun
(28) |
Jul
(23) |
Aug
(25) |
Sep
(28) |
Oct
(32) |
Nov
(50) |
Dec
(19) |
2022 |
Jan
(25) |
Feb
(54) |
Mar
(44) |
Apr
(19) |
May
(11) |
Jun
(9) |
Jul
(17) |
Aug
(27) |
Sep
(33) |
Oct
(24) |
Nov
(37) |
Dec
(17) |
2023 |
Jan
(15) |
Feb
(21) |
Mar
(40) |
Apr
(16) |
May
(20) |
Jun
(117) |
Jul
(59) |
Aug
(18) |
Sep
(28) |
Oct
(13) |
Nov
(54) |
Dec
(20) |
2024 |
Jan
(24) |
Feb
(39) |
Mar
(26) |
Apr
(26) |
May
(33) |
Jun
(39) |
Jul
(16) |
Aug
(31) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
From: Sean C P. <sea...@ug...> - 2010-12-03 20:59:58
|
Update: I added the following field type and then changed the 'title_sort' field from "string" to this new type, "stringTitleSort". The strange thing is that the field appears to be doing exactly what it's supposed to be doing (stripping all punctuation) while running tests in Solr field Analysis, but when I look at live records in the Solr index, the title_sort field still has all punctuation present. And of course, when I sort by title in VuFind, it's not ignoring punctuation. <fieldType name="stringTitleSort" class="solr.StrField" sortMissingLast="true" omitNorms="true"> <analyzer> <tokenizer class="solr.KeywordTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.TrimFilterFactory"/> <!-- strip all punctuation --> <filter class="solr.PatternReplaceFilterFactory" pattern="[^\p{L}\p{N} ]" replacement="" replace="all" /> </analyzer> </fieldType> From: Sean C Purcell [mailto:sea...@ug...] Sent: Friday, December 03, 2010 12:17 PM To: vuf...@li... Subject: [VuFind-Tech] Is there a way to ignore punctuation in title sort? Hi All, Is there a way to have Solr ignore punctuation when sorting by title? The way things are currently set, "Food Webs at the landscape level" sorts before "Food, agriculture, and development...". See the following example: http://vufind.org/demo/Search/Results?lookfor=food&type=Title&sort=title&page=36 We've had a few librarians ask if this can be changed. I've done some research and it looks like Solr 1.5 offers a filter that allows for this: solr.CollationKeyFilterFactory, but this isn't available in version 1.4. Any ideas? Thanks, Sean |
From: Demian K. <dem...@vi...> - 2010-12-03 20:59:13
|
Title sorting is based on the title_sort field in Solr. Although it would be better to solve the problem from the Solr side of things, if you need a brute force solution, you can always manipulate the title_sort values - since they're used for sorting only, not display, you can do whatever you like with them. Right now, the field is populated using SolrMarc's custom getSortableTitle method. You could replace this with a BeanShell script that strips punctuation in addition to dealing with the MARC character skip indicator. Let me know if you need BeanShell assistance! - Demian From: Sean C Purcell [mailto:sea...@ug...] Sent: Friday, December 03, 2010 12:17 PM To: vuf...@li... Subject: [VuFind-Tech] Is there a way to ignore punctuation in title sort? Hi All, Is there a way to have Solr ignore punctuation when sorting by title? The way things are currently set, "Food Webs at the landscape level" sorts before "Food, agriculture, and development...". See the following example: http://vufind.org/demo/Search/Results?lookfor=food&type=Title&sort=title&page=36 We've had a few librarians ask if this can be changed. I've done some research and it looks like Solr 1.5 offers a filter that allows for this: solr.CollationKeyFilterFactory, but this isn't available in version 1.4. Any ideas? Thanks, Sean |
From: Demian K. <dem...@vi...> - 2010-12-03 18:10:14
|
I've been using the @link tag to link to related Wiki pages when appropriate. In cases where there is no obvious link, feel free to omit it. Eventually it would be nice to either resolve this warning for all files or disable to rule that triggers it... but for the moment, it's a drop in the bucket compared to all the other warnings, so we can safely ignore it while addressing bigger concerns. I'm also not too worried about the line length -- I think that the 85-character line length is a good guideline for keeping code simple and understandable in addition to just making it fit on the screen... but in cases (like long text strings or comments) where it's hard to meet the limit without making the code uglier, I don't mind bending the rule sometimes. Since the checkstyle plug-in treats this as "normal" rather than "high" priority, it's easy enough to ignore. - Demian > -----Original Message----- > From: Franck Borel [mailto:fra...@gb...] > Sent: Friday, December 03, 2010 12:06 PM > To: vuf...@li... > Subject: [VuFind-Tech] Hudson - Checkstyle - missing link and Line > exceeds > > Hi, > > I really appreciate Hudson and the checkstyle plug in. Can someone > explain, how I can resolve the warning "Missing @link tag in file > comment"? Is it really necessary? > > Is there something that speaks against to extend the line exceed from > 85 to say 100? Even on my notebook (13'') it is possible to read and > write code of 120 characters per line. > > Have a nice day! > > -- Franck > ----------------------------------------------------------------------- > ------- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for > grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Sean C P. <sea...@ug...> - 2010-12-03 17:17:30
|
Hi All, Is there a way to have Solr ignore punctuation when sorting by title? The way things are currently set, "Food Webs at the landscape level" sorts before "Food, agriculture, and development...". See the following example: http://vufind.org/demo/Search/Results?lookfor=food&type=Title&sort=title&page=36 We've had a few librarians ask if this can be changed. I've done some research and it looks like Solr 1.5 offers a filter that allows for this: solr.CollationKeyFilterFactory, but this isn't available in version 1.4. Any ideas? Thanks, Sean |
From: Franck B. <fra...@gb...> - 2010-12-03 17:06:50
|
Hi, I really appreciate Hudson and the checkstyle plug in. Can someone explain, how I can resolve the warning "Missing @link tag in file comment"? Is it really necessary? Is there something that speaks against to extend the line exceed from 85 to say 100? Even on my notebook (13'') it is possible to read and write code of 120 characters per line. Have a nice day! -- Franck |
From: Andrews, M. J. <man...@cr...> - 2010-12-03 15:45:53
|
Sorry if this is off-topic. If I should post elsewhere just tell me where. Looking away ahead, I have permission to attend the ALA Annual in 2011. The reasoning I used is that "it's easier to follow many open-source projects if I meet-up with folks at the ONE meeting most people go to." I thought I'd check in with the VuFind folks (and our sisters & brothers working on & with Evergreen, Koha, DSpace and the like who lurk here) and see what plans there were or are, if any. If there are no plans, should we make some? Mark Andrews, Creighton University |
From: Demian K. <dem...@vi...> - 2010-12-02 17:14:20
|
The vast majority of VuFind pages do not take advantage of the Smarty caching mechanism. As far as I know, the only page which uses caching is web/services/Search/Home.php (the caching is designed to prevent excessive load on the Solr server caused by the facets displayed in the default theme). You can disable this page's caching by commenting out the "$interface->caching = 1;" line. Assuming that the strings you are modifying appear on pages other than the Search homepage, you may not need to disable caching at all -- you can just perform your tests on a different page and then clear the cache once everything is fixed to your liking. - Demian > -----Original Message----- > From: Zeno Tajoli [mailto:ta...@ci...] > Sent: Thursday, December 02, 2010 12:04 PM > To: vuf...@li... > Subject: [VuFind-Tech] To use VuFind without cache and compile > > Hi to all, > > in a standard install Vufind does pages cache in the dir > ../web/interface/cache and ../web/interface/compile. > > How can I disable this caching option ? > > I want to do this operation because I'm checking an italian translation > of the interface. > In fact I want to correct the file ../web/lang/it.ini and see > immediatly > the result of correct phrases. > > Now I need to stop vufind, delete dirs inside ../cache and ../compile > and restart vufind. > > Bye > Zeno Tajoli > > > > ----------------------------------------------------------------------- > ------- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for > grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Zeno T. <ta...@ci...> - 2010-12-02 17:01:02
|
Hi to all, in a standard install Vufind does pages cache in the dir ../web/interface/cache and ../web/interface/compile. How can I disable this caching option ? I want to do this operation because I'm checking an italian translation of the interface. In fact I want to correct the file ../web/lang/it.ini and see immediatly the result of correct phrases. Now I need to stop vufind, delete dirs inside ../cache and ../compile and restart vufind. Bye Zeno Tajoli |
From: Demian K. <dem...@vi...> - 2010-12-02 16:07:41
|
One additional bit of advice - if you have any modifications that could be shared as generic enhancements to VuFind, consider sharing them. If you make your local enhancements stand alone, they should be relatively easy to share, and if they get incorporated into the trunk, it becomes one less difference that you have to worry about maintaining yourself in the future! - Demian From: Sean C Purcell [mailto:sea...@ug...] Sent: Thursday, December 02, 2010 10:35 AM To: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions Hi Daniel, We recently went through the process of merging our changes with the latest VuFind release. Our production version is based on RC1, and we have made lots of local modifications. We tried both upgrade methods Demian describes on the wiki. Option A ultimately failed, producing way way too many conflicts. But option B worked out great, although it was very labor intensive. We now maintain 2 separate branches: 1) Our soon-to-be production trunk, which is the code that resulted from the aforementioned merge. 2) A bleeding-edge branch, which started out the same as our trunk, but now we periodically merge it with the current VuFind trunk and our local changes (weekly). Keeping up to date now takes about an hour a week, unless a vendor drop breaks something that is difficult to track down. My three bits of advice: - If you pursue option B, add in your local mods feature by feature if possible (see step 5), and then commit each change only after testing in a test site to confirm nothing has broken. - As you add in your mods, refactor your code to try and separate it as much as is feasible from the base VuFind code to help prevent future merge conflicts. - Also be sure to have a test site running the bleeding edge code so you can test it after every vendor drop. You've probably already found this, but here's another description of Vendor Branching: http://svnbook.red-bean.com/en/1.1/ch07s05.html Sean From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 4:07 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions Thanks, Demian. It is a bit confusing. :-P From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:57 PM To: Lovins, Daniel; mikan.d.dspace listmail Cc: vuf...@li... Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions The idea here is that, in order to perform vendor branching, you want to copy data from VuFind's public SVN repository into your own local repository. Thus, you need to create a working directory from YOUR repository, and then populate it with data from the public VuFind repository. That's why you need to use "export" instead of "checkout" - if you checked out a copy, the SVN metadata from the public repository would conflict with the SVN metadata from your local repository. Does that make any sense? I've just slightly tweaked the wording in the wiki in an effort to make this more comprehensible... but it's inherently a bit confusing! - Demian From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 3:52 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li...; Lovins, Daniel Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions Hi Demian. Doesn't using the 'svn export' (vs. checkout) command prevent the new directory from being a working copy? In which case, the command "svn copy vendor trunk" (in a subsequent step) generates the error message: "svn: '.' is not a working copy" ? Or am I missing something? Thanks. Daniel From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:25 PM To: mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I've added some commands showing how to set up Option A in a clean repository here: http://vufind.org/wiki/subversion#option_arely_on_subversion In a complex, real-world situation, the "svn merge" command at the end may blow up with too many conflicts and problems to practically resolve... but if your changes are simple enough, this is an easy solution. If you can't get option A to work, option B should work with similar SVN commands... just in a slightly different order. Either way, once you have things set up, running a merge periodically should keep you up to date... and if you run into a weird merge problem, feel free to post on this list to get help. Let me know if this helps or if you still have questions! - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...] Sent: Tuesday, November 30, 2010 8:47 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I tried the vendor branching method described in VuFind wiki, but didnt quite manage to accomplish on my task. :) I pretty much know the basic use of svn (add, commit, checkout and update), but somehow I manage to mess things up with branching and copy. I usually end up in a situation where I get strange errors like "this is not a working copy" or "cannot copy ." etc. Could you add a command-line examples to your wiki-page, to show exactly how you branch your distributions? thanks, Mika 2010/11/17 Demian Katz <dem...@vi...<mailto:dem...@vi...>> Since this question comes up from time to time, I have added some notes to the wiki: http://vufind.org/wiki/subversion#upgrading_an_old_custom_vufind_version_using_subversion Please take a look and let me know if you have questions. Also be aware that we're hoping to gradually make it easier to extend the VuFind code without introducing lots of merge conflicts. Stay tuned on this list (and, if timing permits, the developers call - http://vufind.org/wiki/developers_call) for further discussion of this in the coming months. - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...<mailto:mik...@gm...>] Sent: Wednesday, November 17, 2010 7:40 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [VuFind-Tech] Migrating changes between Vufind versions Hi, What would be the best option to migrate the changes and customizations done locally, to a new Vufind codebase downloaded from SVN? Thanks, Mika |
From: Lovins, D. <dan...@ya...> - 2010-12-02 15:53:11
|
Hi Sean. Thanks so much for sharing your experience and workflow steps. Definitely helpful. And I'll be interested to see how things develop with UGA's Vufind. Daniel From: Sean C Purcell [mailto:sea...@ug...] Sent: Thursday, December 02, 2010 10:35 AM To: vuf...@li... Cc: Lovins, Daniel Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions Hi Daniel, We recently went through the process of merging our changes with the latest VuFind release. Our production version is based on RC1, and we have made lots of local modifications. We tried both upgrade methods Demian describes on the wiki. Option A ultimately failed, producing way way too many conflicts. But option B worked out great, although it was very labor intensive. We now maintain 2 separate branches: 1) Our soon-to-be production trunk, which is the code that resulted from the aforementioned merge. 2) A bleeding-edge branch, which started out the same as our trunk, but now we periodically merge it with the current VuFind trunk and our local changes (weekly). Keeping up to date now takes about an hour a week, unless a vendor drop breaks something that is difficult to track down. My three bits of advice: - If you pursue option B, add in your local mods feature by feature if possible (see step 5), and then commit each change only after testing in a test site to confirm nothing has broken. - As you add in your mods, refactor your code to try and separate it as much as is feasible from the base VuFind code to help prevent future merge conflicts. - Also be sure to have a test site running the bleeding edge code so you can test it after every vendor drop. You've probably already found this, but here's another description of Vendor Branching: http://svnbook.red-bean.com/en/1.1/ch07s05.html Sean From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 4:07 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions Thanks, Demian. It is a bit confusing. :-P From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:57 PM To: Lovins, Daniel; mikan.d.dspace listmail Cc: vuf...@li... Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions The idea here is that, in order to perform vendor branching, you want to copy data from VuFind's public SVN repository into your own local repository. Thus, you need to create a working directory from YOUR repository, and then populate it with data from the public VuFind repository. That's why you need to use "export" instead of "checkout" - if you checked out a copy, the SVN metadata from the public repository would conflict with the SVN metadata from your local repository. Does that make any sense? I've just slightly tweaked the wording in the wiki in an effort to make this more comprehensible... but it's inherently a bit confusing! - Demian From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 3:52 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li...; Lovins, Daniel Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions Hi Demian. Doesn't using the 'svn export' (vs. checkout) command prevent the new directory from being a working copy? In which case, the command "svn copy vendor trunk" (in a subsequent step) generates the error message: "svn: '.' is not a working copy" ? Or am I missing something? Thanks. Daniel From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:25 PM To: mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I've added some commands showing how to set up Option A in a clean repository here: http://vufind.org/wiki/subversion#option_arely_on_subversion In a complex, real-world situation, the "svn merge" command at the end may blow up with too many conflicts and problems to practically resolve... but if your changes are simple enough, this is an easy solution. If you can't get option A to work, option B should work with similar SVN commands... just in a slightly different order. Either way, once you have things set up, running a merge periodically should keep you up to date... and if you run into a weird merge problem, feel free to post on this list to get help. Let me know if this helps or if you still have questions! - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...] Sent: Tuesday, November 30, 2010 8:47 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I tried the vendor branching method described in VuFind wiki, but didnt quite manage to accomplish on my task. :) I pretty much know the basic use of svn (add, commit, checkout and update), but somehow I manage to mess things up with branching and copy. I usually end up in a situation where I get strange errors like "this is not a working copy" or "cannot copy ." etc. Could you add a command-line examples to your wiki-page, to show exactly how you branch your distributions? thanks, Mika 2010/11/17 Demian Katz <dem...@vi...<mailto:dem...@vi...>> Since this question comes up from time to time, I have added some notes to the wiki: http://vufind.org/wiki/subversion#upgrading_an_old_custom_vufind_version_using_subversion Please take a look and let me know if you have questions. Also be aware that we're hoping to gradually make it easier to extend the VuFind code without introducing lots of merge conflicts. Stay tuned on this list (and, if timing permits, the developers call - http://vufind.org/wiki/developers_call) for further discussion of this in the coming months. - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...<mailto:mik...@gm...>] Sent: Wednesday, November 17, 2010 7:40 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [VuFind-Tech] Migrating changes between Vufind versions Hi, What would be the best option to migrate the changes and customizations done locally, to a new Vufind codebase downloaded from SVN? Thanks, Mika |
From: Sean C P. <sea...@ug...> - 2010-12-02 15:50:09
|
Hi Daniel, We recently went through the process of merging our changes with the latest VuFind release. Our production version is based on RC1, and we have made lots of local modifications. We tried both upgrade methods Demian describes on the wiki. Option A ultimately failed, producing way way too many conflicts. But option B worked out great, although it was very labor intensive. We now maintain 2 separate branches: 1) Our soon-to-be production trunk, which is the code that resulted from the aforementioned merge. 2) A bleeding-edge branch, which started out the same as our trunk, but now we periodically merge it with the current VuFind trunk and our local changes (weekly). Keeping up to date now takes about an hour a week, unless a vendor drop breaks something that is difficult to track down. My three bits of advice: - If you pursue option B, add in your local mods feature by feature if possible (see step 5), and then commit each change only after testing in a test site to confirm nothing has broken. - As you add in your mods, refactor your code to try and separate it as much as is feasible from the base VuFind code to help prevent future merge conflicts. - Also be sure to have a test site running the bleeding edge code so you can test it after every vendor drop. You've probably already found this, but here's another description of Vendor Branching: http://svnbook.red-bean.com/en/1.1/ch07s05.html Sean From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 4:07 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions Thanks, Demian. It is a bit confusing. :-P From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:57 PM To: Lovins, Daniel; mikan.d.dspace listmail Cc: vuf...@li... Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions The idea here is that, in order to perform vendor branching, you want to copy data from VuFind's public SVN repository into your own local repository. Thus, you need to create a working directory from YOUR repository, and then populate it with data from the public VuFind repository. That's why you need to use "export" instead of "checkout" - if you checked out a copy, the SVN metadata from the public repository would conflict with the SVN metadata from your local repository. Does that make any sense? I've just slightly tweaked the wording in the wiki in an effort to make this more comprehensible... but it's inherently a bit confusing! - Demian From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 3:52 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li...; Lovins, Daniel Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions Hi Demian. Doesn't using the 'svn export' (vs. checkout) command prevent the new directory from being a working copy? In which case, the command "svn copy vendor trunk" (in a subsequent step) generates the error message: "svn: '.' is not a working copy" ? Or am I missing something? Thanks. Daniel From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:25 PM To: mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I've added some commands showing how to set up Option A in a clean repository here: http://vufind.org/wiki/subversion#option_arely_on_subversion In a complex, real-world situation, the "svn merge" command at the end may blow up with too many conflicts and problems to practically resolve... but if your changes are simple enough, this is an easy solution. If you can't get option A to work, option B should work with similar SVN commands... just in a slightly different order. Either way, once you have things set up, running a merge periodically should keep you up to date... and if you run into a weird merge problem, feel free to post on this list to get help. Let me know if this helps or if you still have questions! - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...] Sent: Tuesday, November 30, 2010 8:47 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I tried the vendor branching method described in VuFind wiki, but didnt quite manage to accomplish on my task. :) I pretty much know the basic use of svn (add, commit, checkout and update), but somehow I manage to mess things up with branching and copy. I usually end up in a situation where I get strange errors like "this is not a working copy" or "cannot copy ." etc. Could you add a command-line examples to your wiki-page, to show exactly how you branch your distributions? thanks, Mika 2010/11/17 Demian Katz <dem...@vi...<mailto:dem...@vi...>> Since this question comes up from time to time, I have added some notes to the wiki: http://vufind.org/wiki/subversion#upgrading_an_old_custom_vufind_version_using_subversion Please take a look and let me know if you have questions. Also be aware that we're hoping to gradually make it easier to extend the VuFind code without introducing lots of merge conflicts. Stay tuned on this list (and, if timing permits, the developers call - http://vufind.org/wiki/developers_call) for further discussion of this in the coming months. - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...<mailto:mik...@gm...>] Sent: Wednesday, November 17, 2010 7:40 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [VuFind-Tech] Migrating changes between Vufind versions Hi, What would be the best option to migrate the changes and customizations done locally, to a new Vufind codebase downloaded from SVN? Thanks, Mika |
From: Mark T. <mt...@nl...> - 2010-12-01 20:32:00
|
Hi Luke, I remember last time you were seeing things like this in your access log?: 137.44.48.94 - - [30/Sep/2010:14:44:35 +0100] "eep-Alive" 200 12781 "-" "-" 137.44.48.94 - - [30/Sep/2010:14:41:22 +0100] "nnection: Keep-Alive" 400 332 "-" "-" This all sounds a lot like requests are being corrupted either somewhere before Apache, or within Apache itself. From my non-scientific Googling, just about everyone seeing these sort of problems is using mod_ssl... here's a couple of interesting bugs: https://bugzilla.redhat.com/show_bug.cgi?id=624609 https://bugzilla.redhat.com/show_bug.cgi?id=640959 I tried the 'openssl s_client' trick from the second one with the sample request you provided, but didn't have any luck reproducing the problem. But as you say, it's intermittent... Maybe it would be worth upgrading Apache to the latest version just to rule this out? (Often easier said than done, I know :) Osullivan L. <L.O...@sw...> writes: > Hi Folks, > > Please fine below a Live Requests summary of what occurs when we have > problems with Apache processing truncated keep-alive header > requests. As far as I can tell, the browser is sending valid data so > something on our server side must be truncating the headers. As it is > frequently the “Keep-Alive: 115 Connection: keep-alive” headers which > display in the error logs, does this suggest the problem is before > these lines? > > If you can provide any insights, I would be most grateful. > > Cheers, > > Luke > > Browser displays: > > Bad Request > Your browser sent a request that this server could not understand. > Request header field is missing ':' separator. > Alive -- Mark Triggs <mt...@nl...> |
From: Demian K. <dem...@vi...> - 2010-12-01 16:55:49
|
At the time you are forced to restart the server, are any processes obviously standing out as resource hogs? From: Osullivan L. [mailto:L.O...@sw...] Sent: Wednesday, December 01, 2010 11:52 AM To: Demian Katz; vuf...@li... Cc: Johnson J.P.; Brown A.T. Subject: RE: bad request error Hi Demian, Thanks for that - I'll look into it. I'm not 100% convinced it is Apache as the error can usually be resolved only by restarting the whole server and not just apache. Thanks, Luke From: Demian Katz [mailto:dem...@vi...] Sent: 01 December 2010 15:22 To: Osullivan L.; vuf...@li... Cc: Johnson J.P.; Brown A.T. Subject: RE: bad request error Have you tried some of the debugging ideas here? http://prefetch.net/articles/debuggingapache.html In particular, mod_dumpio looks like it might be a good way to get more insight into what is happening on the server side - perhaps you can figure out a pattern to the corrupted requests. Also, if Keep-Alive is somehow involved, could it be that one of these settings needs to be adjusted? http://httpd.apache.org/docs/current/mod/core.html#keepalive - Demian From: Osullivan L. [mailto:L.O...@sw...] Sent: Wednesday, December 01, 2010 8:53 AM To: vuf...@li... Cc: Johnson J.P.; Brown A.T. Subject: [VuFind-Tech] FW: bad request error Hi Folks, Please fine below a Live Requests summary of what occurs when we have problems with Apache processing truncated keep-alive header requests. As far as I can tell, the browser is sending valid data so something on our server side must be truncating the headers. As it is frequently the "Keep-Alive: 115 Connection: keep-alive" headers which display in the error logs, does this suggest the problem is before these lines? If you can provide any insights, I would be most grateful. Cheers, Luke Browser displays: Bad Request Your browser sent a request that this server could not understand. Request header field is missing ':' separator. Alive ________________________________ Apache/2.2.14 (Ubuntu) Server at ifind.swwhep.ac.uk Port 443 LiveHTTPheaders captures... https://ifind.swwhep.ac.uk/discover/Search/Results?lookfor=dog&type=AllFields&submit=Find&orFilter%5B%5D=institution%3ASU GET /discover/Search/Results?lookfor=dog&type=AllFields&submit=Find&orFilter%5B%5D=institution%3ASU HTTP/1.1 Host: ifind.swwhep.ac.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: https://ifind.swwhep.ac.uk/discover/ Cookie: _csoot=1266858617947; _csuid=4b28f26741240d99; __utma=171573752.938782962.1282722594.1291040088.1291049037.133; __utmz=171573752.1289474120.105.10.utmcsr=www|utmccn=(referral)|utmcmd=referral|utmcct=/lis/; __utma=237134978.1833992570.1282803365.1282803365.1282803365.1; __utmz=237134978.1282804285.1.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=cache:9QvvGSQmhfsJ:www.swwhep.ac.uk/en/projects/libraryservices/announcements/headline,47450,en.php%20swwhep%20ifind%20research; PHPSESSID=tlpm4pf3dku612cc8dpm46nnm3; __utmc=171573752; __utmb=171573752.8.10.1291049037 HTTP/1.1 400 Bad Request Connection: close Content-Length: 382 Date: Mon, 29 Nov 2010 16:49:49 GMT Content-Type: text/html; charset=iso-8859-1 Server: Apache/2.2.14 (Ubuntu) Vary: Accept-Encoding ---------------------------------------------------------- |
From: Osullivan L. <L.O...@sw...> - 2010-12-01 16:53:36
|
Hi Demian, Thanks for that - I'll look into it. I'm not 100% convinced it is Apache as the error can usually be resolved only by restarting the whole server and not just apache. Thanks, Luke From: Demian Katz [mailto:dem...@vi...] Sent: 01 December 2010 15:22 To: Osullivan L.; vuf...@li... Cc: Johnson J.P.; Brown A.T. Subject: RE: bad request error Have you tried some of the debugging ideas here? http://prefetch.net/articles/debuggingapache.html In particular, mod_dumpio looks like it might be a good way to get more insight into what is happening on the server side - perhaps you can figure out a pattern to the corrupted requests. Also, if Keep-Alive is somehow involved, could it be that one of these settings needs to be adjusted? http://httpd.apache.org/docs/current/mod/core.html#keepalive - Demian From: Osullivan L. [mailto:L.O...@sw...] Sent: Wednesday, December 01, 2010 8:53 AM To: vuf...@li... Cc: Johnson J.P.; Brown A.T. Subject: [VuFind-Tech] FW: bad request error Hi Folks, Please fine below a Live Requests summary of what occurs when we have problems with Apache processing truncated keep-alive header requests. As far as I can tell, the browser is sending valid data so something on our server side must be truncating the headers. As it is frequently the "Keep-Alive: 115 Connection: keep-alive" headers which display in the error logs, does this suggest the problem is before these lines? If you can provide any insights, I would be most grateful. Cheers, Luke Browser displays: Bad Request Your browser sent a request that this server could not understand. Request header field is missing ':' separator. Alive ________________________________ Apache/2.2.14 (Ubuntu) Server at ifind.swwhep.ac.uk Port 443 LiveHTTPheaders captures... https://ifind.swwhep.ac.uk/discover/Search/Results?lookfor=dog&type=AllF ields&submit=Find&orFilter%5B%5D=institution%3ASU GET /discover/Search/Results?lookfor=dog&type=AllFields&submit=Find&orFilter %5B%5D=institution%3ASU HTTP/1.1 Host: ifind.swwhep.ac.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: https://ifind.swwhep.ac.uk/discover/ Cookie: _csoot=1266858617947; _csuid=4b28f26741240d99; __utma=171573752.938782962.1282722594.1291040088.1291049037.133; __utmz=171573752.1289474120.105.10.utmcsr=www|utmccn=(referral)|utmcmd=r eferral|utmcct=/lis/; __utma=237134978.1833992570.1282803365.1282803365.1282803365.1; __utmz=237134978.1282804285.1.2.utmcsr=google|utmccn=(organic)|utmcmd=or ganic|utmctr=cache:9QvvGSQmhfsJ:www.swwhep.ac.uk/en/projects/libraryserv ices/announcements/headline,47450,en.php%20swwhep%20ifind%20research; PHPSESSID=tlpm4pf3dku612cc8dpm46nnm3; __utmc=171573752; __utmb=171573752.8.10.1291049037 HTTP/1.1 400 Bad Request Connection: close Content-Length: 382 Date: Mon, 29 Nov 2010 16:49:49 GMT Content-Type: text/html; charset=iso-8859-1 Server: Apache/2.2.14 (Ubuntu) Vary: Accept-Encoding ---------------------------------------------------------- |
From: Demian K. <dem...@vi...> - 2010-12-01 16:42:37
|
Looks great... but a few more ideas: 1.) Would it make more sense to put the content type handling into the dieWithFailImage function? This way, you could provide an ISBN and a content type on the same URL, and if the ISBN doesn't find anything, the content type could serve as a failover. Obviously, you would have to change the code that handles missing content type images a little bit... but that shouldn't be very hard. 2.) You should url-encode the value of the contenttype parameter in the templates just in case they contain any URL-illegal characters. You can use the |escape:"url" Smarty modifier to achieve this. 3.) Do you really need the special case to exclude the content type of Book? Would it be better to pass all content types through and then give users the option of not bothering to define a Book graphic? 4.) Assuming you follow suggestions 1-3 above, you could probably condense your templates slightly -- changing the first {if} to something like: {if $record.ISBN.0 || $record.ContentType.0} <img src="{$path}/bookcover.php?size=small{if $record.ISBN.0}&isn={$record.ISBN.0|@formatISBN}{/if}{if $record.ContentType.0}&contenttype={$record.ContentType.0|escape:"url"}{/if}" class="alignleft" alt="Cover Image"/> {elseif...} 5.) For better cross-theme configurability, how about putting the content type graphics in the individual theme folders and then parsing out the theme settings in bookcover.php? Something like: $themes = explode(',', $configArray['Site']['theme']); for ($x = count($themes) - 1; $x <= 0; $x--) { $localFile = dirname(__FILE__) . '/interface/themes/' . $themes[$x] . '/images/' . $contenttype . '.png'; ... (That's untested code... but I think you get the idea). Anyway, thanks again for your help with this. If you like any of my ideas but don't have time to implement them, just let me know and I can take a few minutes to put finishing touches on the patch. - Demian > -----Original Message----- > From: Seaman, Graham [mailto:Gra...@rh...] > Sent: Wednesday, December 01, 2010 11:10 AM > To: Demian Katz; Greg Pendlebury > Cc: vuf...@li... > Subject: RE: [VuFind-Tech] feeding back? > > I've uploaded a new patch which handles the additional content type > graphics. If the icons aren't there, it degrades naturally to the 'no > book cover' image. > > There are various sources for free icons (ie PD or CC0 etc), like > http://iconlibrary.sourceforge.net (I'm using that one in my testing) > and http://openclipart.org. It would take someone with a better eye > than > me to pick a consistent set that go well with any vufind theme, though. > I think it should be possible to find icons for most (all?) content > types which are obvious without using words. > > Graham > > -----Original Message----- > From: Demian Katz [mailto:dem...@vi...] > Sent: 01 December 2010 13:28 > To: Seaman, Graham; Greg Pendlebury > Cc: vuf...@li... > Subject: RE: [VuFind-Tech] feeding back? > > Sounds good -- I'll keep an eye out for an update to the ticket! > > Regarding VUFIND-280, I definitely have no problem with the addition of > an extra Summon-specific parameter to bookcover.php, as long as it is > reasonably clearly named. As you say, the hard part is coming up with > the graphics in the first place (and, if they happen to contain text, > dealing with internationalization... though this is already an unsolved > problem for the "unavailable" graphic). Do you have any ideas on a > source for graphics? If not, perhaps one avenue would be to contact > Serials Solutions through Andrew and see if we can get permission to > use > any of the existing Summon graphics for this purpose. > > One other thought, which might simplify graphics generation and > internationalization -- we have talked in the past about using the GD > library to generate graphics on the fly. The only drawback is that not > every PHP installation includes GD, so it may be necessary to include > some kind of fallback behavior if the library is missing. > > - Demian > > > -----Original Message----- > > From: Seaman, Graham [mailto:Gra...@rh...] > > Sent: Wednesday, December 01, 2010 7:46 AM > > To: Demian Katz; Greg Pendlebury > > Cc: vuf...@li... > > Subject: RE: [VuFind-Tech] feeding back? > > > > > > Both points sound fine, will do, thanks. > > > > Re ticket 280 - looks easy to do by picking up the Summon record > value > > record.ContentType.0 (eg 'Journal Article', 'Video recording' etc.) > > Just > > need the graphics! But rather than adding extra cases to the > template, > > I > > would prefer to see the logic in bookcover.php. Would you have a > > problem > > with summon-specific logic (in particular, a parameter other than the > > isbn) being added to bookcover.php if it could be done without > > affecting > > existing functionality? > > > > Graham > > > > -----Original Message----- > > From: Demian Katz [mailto:dem...@vi...] > > Sent: 30 November 2010 17:14 > > To: Seaman, Graham; Greg Pendlebury > > Cc: vuf...@li... > > Subject: RE: [VuFind-Tech] feeding back? > > > > Thanks for sharing this. A couple of thoughts: > > > > 1.) VuFind now includes a library for ISBN conversion; I recently > > updated bookcover.php to take advantage of this (probably after you > > developed your changes). This can probably significantly simplify > your > > changes there. > > 2.) It's probably worth checking for an ISBN in the templates before > > passing off to bookcover.php, since many Summon records do not > include > > ISBNs. It is also probably worth including an else clause that > checks > > for a thumbnail in the Summon results in case Summon eventually > > includes > > the ability to provide thumbnails for non-ISBN-based resources. This > > will also help when we eventually implement better default thumbnails > > for Summon (see http://vufind.org/jira/browse/VUFIND-280 -- and feel > > free to offer ideas on this if you find it interesting). > > |
From: Seaman, G. <Gra...@rh...> - 2010-12-01 16:10:23
|
I've uploaded a new patch which handles the additional content type graphics. If the icons aren't there, it degrades naturally to the 'no book cover' image. There are various sources for free icons (ie PD or CC0 etc), like http://iconlibrary.sourceforge.net (I'm using that one in my testing) and http://openclipart.org. It would take someone with a better eye than me to pick a consistent set that go well with any vufind theme, though. I think it should be possible to find icons for most (all?) content types which are obvious without using words. Graham -----Original Message----- From: Demian Katz [mailto:dem...@vi...] Sent: 01 December 2010 13:28 To: Seaman, Graham; Greg Pendlebury Cc: vuf...@li... Subject: RE: [VuFind-Tech] feeding back? Sounds good -- I'll keep an eye out for an update to the ticket! Regarding VUFIND-280, I definitely have no problem with the addition of an extra Summon-specific parameter to bookcover.php, as long as it is reasonably clearly named. As you say, the hard part is coming up with the graphics in the first place (and, if they happen to contain text, dealing with internationalization... though this is already an unsolved problem for the "unavailable" graphic). Do you have any ideas on a source for graphics? If not, perhaps one avenue would be to contact Serials Solutions through Andrew and see if we can get permission to use any of the existing Summon graphics for this purpose. One other thought, which might simplify graphics generation and internationalization -- we have talked in the past about using the GD library to generate graphics on the fly. The only drawback is that not every PHP installation includes GD, so it may be necessary to include some kind of fallback behavior if the library is missing. - Demian > -----Original Message----- > From: Seaman, Graham [mailto:Gra...@rh...] > Sent: Wednesday, December 01, 2010 7:46 AM > To: Demian Katz; Greg Pendlebury > Cc: vuf...@li... > Subject: RE: [VuFind-Tech] feeding back? > > > Both points sound fine, will do, thanks. > > Re ticket 280 - looks easy to do by picking up the Summon record value > record.ContentType.0 (eg 'Journal Article', 'Video recording' etc.) > Just > need the graphics! But rather than adding extra cases to the template, > I > would prefer to see the logic in bookcover.php. Would you have a > problem > with summon-specific logic (in particular, a parameter other than the > isbn) being added to bookcover.php if it could be done without > affecting > existing functionality? > > Graham > > -----Original Message----- > From: Demian Katz [mailto:dem...@vi...] > Sent: 30 November 2010 17:14 > To: Seaman, Graham; Greg Pendlebury > Cc: vuf...@li... > Subject: RE: [VuFind-Tech] feeding back? > > Thanks for sharing this. A couple of thoughts: > > 1.) VuFind now includes a library for ISBN conversion; I recently > updated bookcover.php to take advantage of this (probably after you > developed your changes). This can probably significantly simplify your > changes there. > 2.) It's probably worth checking for an ISBN in the templates before > passing off to bookcover.php, since many Summon records do not include > ISBNs. It is also probably worth including an else clause that checks > for a thumbnail in the Summon results in case Summon eventually > includes > the ability to provide thumbnails for non-ISBN-based resources. This > will also help when we eventually implement better default thumbnails > for Summon (see http://vufind.org/jira/browse/VUFIND-280 -- and feel > free to offer ideas on this if you find it interesting). > |
From: Demian K. <dem...@vi...> - 2010-12-01 15:28:30
|
Have you tried some of the debugging ideas here? http://prefetch.net/articles/debuggingapache.html In particular, mod_dumpio looks like it might be a good way to get more insight into what is happening on the server side - perhaps you can figure out a pattern to the corrupted requests. Also, if Keep-Alive is somehow involved, could it be that one of these settings needs to be adjusted? http://httpd.apache.org/docs/current/mod/core.html#keepalive - Demian From: Osullivan L. [mailto:L.O...@sw...] Sent: Wednesday, December 01, 2010 8:53 AM To: vuf...@li... Cc: Johnson J.P.; Brown A.T. Subject: [VuFind-Tech] FW: bad request error Hi Folks, Please fine below a Live Requests summary of what occurs when we have problems with Apache processing truncated keep-alive header requests. As far as I can tell, the browser is sending valid data so something on our server side must be truncating the headers. As it is frequently the "Keep-Alive: 115 Connection: keep-alive" headers which display in the error logs, does this suggest the problem is before these lines? If you can provide any insights, I would be most grateful. Cheers, Luke Browser displays: Bad Request Your browser sent a request that this server could not understand. Request header field is missing ':' separator. Alive ________________________________ Apache/2.2.14 (Ubuntu) Server at ifind.swwhep.ac.uk Port 443 LiveHTTPheaders captures... https://ifind.swwhep.ac.uk/discover/Search/Results?lookfor=dog&type=AllFields&submit=Find&orFilter%5B%5D=institution%3ASU GET /discover/Search/Results?lookfor=dog&type=AllFields&submit=Find&orFilter%5B%5D=institution%3ASU HTTP/1.1 Host: ifind.swwhep.ac.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: https://ifind.swwhep.ac.uk/discover/ Cookie: _csoot=1266858617947; _csuid=4b28f26741240d99; __utma=171573752.938782962.1282722594.1291040088.1291049037.133; __utmz=171573752.1289474120.105.10.utmcsr=www|utmccn=(referral)|utmcmd=referral|utmcct=/lis/; __utma=237134978.1833992570.1282803365.1282803365.1282803365.1; __utmz=237134978.1282804285.1.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=cache:9QvvGSQmhfsJ:www.swwhep.ac.uk/en/projects/libraryservices/announcements/headline,47450,en.php%20swwhep%20ifind%20research; PHPSESSID=tlpm4pf3dku612cc8dpm46nnm3; __utmc=171573752; __utmb=171573752.8.10.1291049037 HTTP/1.1 400 Bad Request Connection: close Content-Length: 382 Date: Mon, 29 Nov 2010 16:49:49 GMT Content-Type: text/html; charset=iso-8859-1 Server: Apache/2.2.14 (Ubuntu) Vary: Accept-Encoding ---------------------------------------------------------- |
From: Demian K. <dem...@vi...> - 2010-12-01 15:08:57
|
I don't think there's an especially simple solution, but the approach Luke O'Sullivan has taken for SWWHEP seems reasonable: 1.) Build a MARC merge script that generates a single MARC record for each item containing details on holdings (including original bib numbers from each institution) in 9xx fields. 2.) Use the holdings information in the 9xx fields to populate location facets at index time so that it is possible to facet by location. 3.) Modify the ILS driver so that it can parse out the necessary details to contact the appropriate ILS(es) for each record to get real-time status information. Much of Luke's code is available in a branch in the regular VuFind SVN repository, so you can take a look at what he has done fairly easily. If you have specific questions, he can probably provide more details (though he may not be available for a couple of days - I hear he has the flu at the moment). This is definitely not the only solution out there, though it is the one I am most familiar with. Whatever happens, though, I think you're going to have to do some MARC merging (perhaps based on OCLC number or ISBN) if you really want just one record for each distinct item. - Demian From: Tulie Amichal [mailto:tu...@ma...] Sent: Wednesday, December 01, 2010 4:46 AM To: vuf...@li... Subject: [VuFind-Tech] Union View Hi All We have a union catalog holding multiple records for each item, one for each library that has it in its holdings. I wanted to try as part of the migration to vufind to create a union view, allowing me to show one record per each item and show the institution names under holdings. I saw some consortia did this but is there a preferred approach? Thanks Tulie -- Tulie Amichal Information Systems Analyst MALMAD Office: 03-6460554 tu...@ma... |
From: Osullivan L. <L.O...@sw...> - 2010-12-01 13:53:03
|
Hi Folks, Please fine below a Live Requests summary of what occurs when we have problems with Apache processing truncated keep-alive header requests. As far as I can tell, the browser is sending valid data so something on our server side must be truncating the headers. As it is frequently the "Keep-Alive: 115 Connection: keep-alive" headers which display in the error logs, does this suggest the problem is before these lines? If you can provide any insights, I would be most grateful. Cheers, Luke Browser displays: Bad Request Your browser sent a request that this server could not understand. Request header field is missing ':' separator. Alive ________________________________ Apache/2.2.14 (Ubuntu) Server at ifind.swwhep.ac.uk Port 443 LiveHTTPheaders captures... https://ifind.swwhep.ac.uk/discover/Search/Results?lookfor=dog&type=AllF ields&submit=Find&orFilter%5B%5D=institution%3ASU GET /discover/Search/Results?lookfor=dog&type=AllFields&submit=Find&orFilter %5B%5D=institution%3ASU HTTP/1.1 Host: ifind.swwhep.ac.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: https://ifind.swwhep.ac.uk/discover/ Cookie: _csoot=1266858617947; _csuid=4b28f26741240d99; __utma=171573752.938782962.1282722594.1291040088.1291049037.133; __utmz=171573752.1289474120.105.10.utmcsr=www|utmccn=(referral)|utmcmd=r eferral|utmcct=/lis/; __utma=237134978.1833992570.1282803365.1282803365.1282803365.1; __utmz=237134978.1282804285.1.2.utmcsr=google|utmccn=(organic)|utmcmd=or ganic|utmctr=cache:9QvvGSQmhfsJ:www.swwhep.ac.uk/en/projects/libraryserv ices/announcements/headline,47450,en.php%20swwhep%20ifind%20research; PHPSESSID=tlpm4pf3dku612cc8dpm46nnm3; __utmc=171573752; __utmb=171573752.8.10.1291049037 HTTP/1.1 400 Bad Request Connection: close Content-Length: 382 Date: Mon, 29 Nov 2010 16:49:49 GMT Content-Type: text/html; charset=iso-8859-1 Server: Apache/2.2.14 (Ubuntu) Vary: Accept-Encoding ---------------------------------------------------------- |
From: Demian K. <dem...@vi...> - 2010-12-01 13:27:50
|
Sounds good -- I'll keep an eye out for an update to the ticket! Regarding VUFIND-280, I definitely have no problem with the addition of an extra Summon-specific parameter to bookcover.php, as long as it is reasonably clearly named. As you say, the hard part is coming up with the graphics in the first place (and, if they happen to contain text, dealing with internationalization... though this is already an unsolved problem for the "unavailable" graphic). Do you have any ideas on a source for graphics? If not, perhaps one avenue would be to contact Serials Solutions through Andrew and see if we can get permission to use any of the existing Summon graphics for this purpose. One other thought, which might simplify graphics generation and internationalization -- we have talked in the past about using the GD library to generate graphics on the fly. The only drawback is that not every PHP installation includes GD, so it may be necessary to include some kind of fallback behavior if the library is missing. - Demian > -----Original Message----- > From: Seaman, Graham [mailto:Gra...@rh...] > Sent: Wednesday, December 01, 2010 7:46 AM > To: Demian Katz; Greg Pendlebury > Cc: vuf...@li... > Subject: RE: [VuFind-Tech] feeding back? > > > Both points sound fine, will do, thanks. > > Re ticket 280 - looks easy to do by picking up the Summon record value > record.ContentType.0 (eg 'Journal Article', 'Video recording' etc.) > Just > need the graphics! But rather than adding extra cases to the template, > I > would prefer to see the logic in bookcover.php. Would you have a > problem > with summon-specific logic (in particular, a parameter other than the > isbn) being added to bookcover.php if it could be done without > affecting > existing functionality? > > Graham > > -----Original Message----- > From: Demian Katz [mailto:dem...@vi...] > Sent: 30 November 2010 17:14 > To: Seaman, Graham; Greg Pendlebury > Cc: vuf...@li... > Subject: RE: [VuFind-Tech] feeding back? > > Thanks for sharing this. A couple of thoughts: > > 1.) VuFind now includes a library for ISBN conversion; I recently > updated bookcover.php to take advantage of this (probably after you > developed your changes). This can probably significantly simplify your > changes there. > 2.) It's probably worth checking for an ISBN in the templates before > passing off to bookcover.php, since many Summon records do not include > ISBNs. It is also probably worth including an else clause that checks > for a thumbnail in the Summon results in case Summon eventually > includes > the ability to provide thumbnails for non-ISBN-based resources. This > will also help when we eventually implement better default thumbnails > for Summon (see http://vufind.org/jira/browse/VUFIND-280 -- and feel > free to offer ideas on this if you find it interesting). > |
From: Seaman, G. <Gra...@rh...> - 2010-12-01 12:45:57
|
Both points sound fine, will do, thanks. Re ticket 280 - looks easy to do by picking up the Summon record value record.ContentType.0 (eg 'Journal Article', 'Video recording' etc.) Just need the graphics! But rather than adding extra cases to the template, I would prefer to see the logic in bookcover.php. Would you have a problem with summon-specific logic (in particular, a parameter other than the isbn) being added to bookcover.php if it could be done without affecting existing functionality? Graham -----Original Message----- From: Demian Katz [mailto:dem...@vi...] Sent: 30 November 2010 17:14 To: Seaman, Graham; Greg Pendlebury Cc: vuf...@li... Subject: RE: [VuFind-Tech] feeding back? Thanks for sharing this. A couple of thoughts: 1.) VuFind now includes a library for ISBN conversion; I recently updated bookcover.php to take advantage of this (probably after you developed your changes). This can probably significantly simplify your changes there. 2.) It's probably worth checking for an ISBN in the templates before passing off to bookcover.php, since many Summon records do not include ISBNs. It is also probably worth including an else clause that checks for a thumbnail in the Summon results in case Summon eventually includes the ability to provide thumbnails for non-ISBN-based resources. This will also help when we eventually implement better default thumbnails for Summon (see http://vufind.org/jira/browse/VUFIND-280 -- and feel free to offer ideas on this if you find it interesting). |
From: Tulie A. <tu...@ma...> - 2010-12-01 09:36:40
|
Hi All We have a union catalog holding multiple records for each item, one for each library that has it in its holdings. I wanted to try as part of the migration to vufind to create a union view, allowing me to show one record per each item and show the institution names under holdings. I saw some consortia did this but is there a preferred approach? Thanks Tulie -- Tulie Amichal Information Systems Analyst MALMAD Office: 03-6460554 tu...@ma... |
From: Lovins, D. <dan...@ya...> - 2010-11-30 21:06:57
|
Thanks, Demian. It is a bit confusing. :-P From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:57 PM To: Lovins, Daniel; mikan.d.dspace listmail Cc: vuf...@li... Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions The idea here is that, in order to perform vendor branching, you want to copy data from VuFind's public SVN repository into your own local repository. Thus, you need to create a working directory from YOUR repository, and then populate it with data from the public VuFind repository. That's why you need to use "export" instead of "checkout" - if you checked out a copy, the SVN metadata from the public repository would conflict with the SVN metadata from your local repository. Does that make any sense? I've just slightly tweaked the wording in the wiki in an effort to make this more comprehensible... but it's inherently a bit confusing! - Demian From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 3:52 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li...; Lovins, Daniel Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions Hi Demian. Doesn't using the 'svn export' (vs. checkout) command prevent the new directory from being a working copy? In which case, the command "svn copy vendor trunk" (in a subsequent step) generates the error message: "svn: '.' is not a working copy" ? Or am I missing something? Thanks. Daniel From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:25 PM To: mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I've added some commands showing how to set up Option A in a clean repository here: http://vufind.org/wiki/subversion#option_arely_on_subversion In a complex, real-world situation, the "svn merge" command at the end may blow up with too many conflicts and problems to practically resolve... but if your changes are simple enough, this is an easy solution. If you can't get option A to work, option B should work with similar SVN commands... just in a slightly different order. Either way, once you have things set up, running a merge periodically should keep you up to date... and if you run into a weird merge problem, feel free to post on this list to get help. Let me know if this helps or if you still have questions! - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...] Sent: Tuesday, November 30, 2010 8:47 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I tried the vendor branching method described in VuFind wiki, but didnt quite manage to accomplish on my task. :) I pretty much know the basic use of svn (add, commit, checkout and update), but somehow I manage to mess things up with branching and copy. I usually end up in a situation where I get strange errors like "this is not a working copy" or "cannot copy ." etc. Could you add a command-line examples to your wiki-page, to show exactly how you branch your distributions? thanks, Mika 2010/11/17 Demian Katz <dem...@vi...<mailto:dem...@vi...>> Since this question comes up from time to time, I have added some notes to the wiki: http://vufind.org/wiki/subversion#upgrading_an_old_custom_vufind_version_using_subversion Please take a look and let me know if you have questions. Also be aware that we're hoping to gradually make it easier to extend the VuFind code without introducing lots of merge conflicts. Stay tuned on this list (and, if timing permits, the developers call - http://vufind.org/wiki/developers_call) for further discussion of this in the coming months. - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...<mailto:mik...@gm...>] Sent: Wednesday, November 17, 2010 7:40 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [VuFind-Tech] Migrating changes between Vufind versions Hi, What would be the best option to migrate the changes and customizations done locally, to a new Vufind codebase downloaded from SVN? Thanks, Mika |
From: Demian K. <dem...@vi...> - 2010-11-30 20:58:49
|
The idea here is that, in order to perform vendor branching, you want to copy data from VuFind's public SVN repository into your own local repository. Thus, you need to create a working directory from YOUR repository, and then populate it with data from the public VuFind repository. That's why you need to use "export" instead of "checkout" - if you checked out a copy, the SVN metadata from the public repository would conflict with the SVN metadata from your local repository. Does that make any sense? I've just slightly tweaked the wording in the wiki in an effort to make this more comprehensible... but it's inherently a bit confusing! - Demian From: Lovins, Daniel [mailto:dan...@ya...] Sent: Tuesday, November 30, 2010 3:52 PM To: Demian Katz; mikan.d.dspace listmail Cc: vuf...@li...; Lovins, Daniel Subject: RE: [VuFind-Tech] Migrating changes between Vufind versions Hi Demian. Doesn't using the 'svn export' (vs. checkout) command prevent the new directory from being a working copy? In which case, the command "svn copy vendor trunk" (in a subsequent step) generates the error message: "svn: '.' is not a working copy" ? Or am I missing something? Thanks. Daniel From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:25 PM To: mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I've added some commands showing how to set up Option A in a clean repository here: http://vufind.org/wiki/subversion#option_arely_on_subversion In a complex, real-world situation, the "svn merge" command at the end may blow up with too many conflicts and problems to practically resolve... but if your changes are simple enough, this is an easy solution. If you can't get option A to work, option B should work with similar SVN commands... just in a slightly different order. Either way, once you have things set up, running a merge periodically should keep you up to date... and if you run into a weird merge problem, feel free to post on this list to get help. Let me know if this helps or if you still have questions! - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...] Sent: Tuesday, November 30, 2010 8:47 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I tried the vendor branching method described in VuFind wiki, but didnt quite manage to accomplish on my task. :) I pretty much know the basic use of svn (add, commit, checkout and update), but somehow I manage to mess things up with branching and copy. I usually end up in a situation where I get strange errors like "this is not a working copy" or "cannot copy ." etc. Could you add a command-line examples to your wiki-page, to show exactly how you branch your distributions? thanks, Mika 2010/11/17 Demian Katz <dem...@vi...<mailto:dem...@vi...>> Since this question comes up from time to time, I have added some notes to the wiki: http://vufind.org/wiki/subversion#upgrading_an_old_custom_vufind_version_using_subversion Please take a look and let me know if you have questions. Also be aware that we're hoping to gradually make it easier to extend the VuFind code without introducing lots of merge conflicts. Stay tuned on this list (and, if timing permits, the developers call - http://vufind.org/wiki/developers_call) for further discussion of this in the coming months. - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...<mailto:mik...@gm...>] Sent: Wednesday, November 17, 2010 7:40 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [VuFind-Tech] Migrating changes between Vufind versions Hi, What would be the best option to migrate the changes and customizations done locally, to a new Vufind codebase downloaded from SVN? Thanks, Mika |
From: Lovins, D. <dan...@ya...> - 2010-11-30 20:52:02
|
Hi Demian. Doesn't using the 'svn export' (vs. checkout) command prevent the new directory from being a working copy? In which case, the command "svn copy vendor trunk" (in a subsequent step) generates the error message: "svn: '.' is not a working copy" ? Or am I missing something? Thanks. Daniel From: Demian Katz [mailto:dem...@vi...] Sent: Tuesday, November 30, 2010 3:25 PM To: mikan.d.dspace listmail Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I've added some commands showing how to set up Option A in a clean repository here: http://vufind.org/wiki/subversion#option_arely_on_subversion In a complex, real-world situation, the "svn merge" command at the end may blow up with too many conflicts and problems to practically resolve... but if your changes are simple enough, this is an easy solution. If you can't get option A to work, option B should work with similar SVN commands... just in a slightly different order. Either way, once you have things set up, running a merge periodically should keep you up to date... and if you run into a weird merge problem, feel free to post on this list to get help. Let me know if this helps or if you still have questions! - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...] Sent: Tuesday, November 30, 2010 8:47 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] Migrating changes between Vufind versions I tried the vendor branching method described in VuFind wiki, but didnt quite manage to accomplish on my task. :) I pretty much know the basic use of svn (add, commit, checkout and update), but somehow I manage to mess things up with branching and copy. I usually end up in a situation where I get strange errors like "this is not a working copy" or "cannot copy ." etc. Could you add a command-line examples to your wiki-page, to show exactly how you branch your distributions? thanks, Mika 2010/11/17 Demian Katz <dem...@vi...<mailto:dem...@vi...>> Since this question comes up from time to time, I have added some notes to the wiki: http://vufind.org/wiki/subversion#upgrading_an_old_custom_vufind_version_using_subversion Please take a look and let me know if you have questions. Also be aware that we're hoping to gradually make it easier to extend the VuFind code without introducing lots of merge conflicts. Stay tuned on this list (and, if timing permits, the developers call - http://vufind.org/wiki/developers_call) for further discussion of this in the coming months. - Demian From: mikan.d.dspace listmail [mailto:mik...@gm...<mailto:mik...@gm...>] Sent: Wednesday, November 17, 2010 7:40 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [VuFind-Tech] Migrating changes between Vufind versions Hi, What would be the best option to migrate the changes and customizations done locally, to a new Vufind codebase downloaded from SVN? Thanks, Mika |