Paul, Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) > modifying frameworks never gave "instant gratification" due to memcached, > so I use netcat: > > echo -e "flush_all\nquit\n" | nc localhost 11211 > > (and even have a temp 1 min cron job if I need more than a very simple > change.) >
If the only thing using memcached is Koha, you might find it easier to simply have a cron job that runs `service memcached restart` every hour. However, I've just come across bug 7432, and while 10 minutes might be a > bit painful, I would appreciate advice for updating in a production > environment (I normally work on the principle that "if it ain't broke, > don't fix it", but...) > > Is it better for me to attempt to modify our existing biblio.pm (4 > minuses, five plusses as far as I can see) or find a more recent biblio.pm, > in which case "which one and where"? (maybe from a complete tar of 3.6.5?) > How do I find release details at component level? How do I check for side > effects? (None are apparently visible from the bug page.) > Do not mix and match files from different versions. My recommendation would be to upgrade to a recent version of 3.6.x. If you feel you must have this patch, and are not willing to update, apply the patch against your current version, but you must be prepared for unexpected problems that no one else will be able to troubleshoot. There is a reason we release bugfix versions regularly- so that people can get their bugfixes without needing a deep understanding of exactly how the patches work, and how they depend on each other. As far as I can tell based on a quick look at the patch, there shouldn't be any side effects, and the patch probably won't cause any breakage, but I wouldn't make this change -- or any other -- in production. I'd reclaim the testing server for 3.6.1, apply the patch, test thoroughly, then apply the patch to the production server. Or, better, if you're planning to upgrade soon anyway, don't rock the boat, and wait until, in the fullness of time, you upgrade to a recent version of Koha. By the way, I've found a possible "oddity"; making a subfield mandatory so > that the "manadatoryness" is not just functional but also appears in the > fourth column of marctagstructure.pl, I have to use both: > marctagstructure.pl?op=add_**form <http://marctagstructure.pl?op=add_form>AND > marc_subfields_structure.pl?**op=add_form<http://marc_subfields_structure.pl?op=add_form> > -- am I doing something wrong? > I am not sure why you are marking both the tag and the subfield mandatory. As far as I know marking a subfield mandatory also makes the tag mandatory at the moment. (WARNING: the following is irrelevant to your question) I would argue this is a bug (reported it as one, in fact), but that's the way it is, so -- for the moment -- no need to mark both the tag and subfield mandatory. Based on the way the MARC standard is written, marking a subfield mandatory should make it so that if any subfield in that tag is populated, that subfield must be populated, but not require that the tag be populated at all. However, that's not the way it works, so it's kind of a moot point. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) [email protected] (web) http://www.cpbibliography.com/
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
