Bug 9247 - Add two more usage examples to the manpage for koha-mysql

It might not be immediately obvious that it is possible to send
SQL queries "directly" to the koha-mysql command, or that files
from mysqldump can be loaded with it. This patch adds these as
"example usage" to the man page for koha-mysql.

To test:

Run these commands and look at the formatted man page:
$ xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl/manpages/docbook.xsl \
  debian/docs/koha-mysql.xml
$ man -l koha-mysql.8

Make sure this test passes:
$ prove -v xt/verify-debian-docbook.t

This patch also corrects a couple places where "Koha" was written as "koha".

Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Test plan, all tests and QA script pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10593: make AuthoritiesLog default to yes

This trivial patch set the default to 'yes' for this system preference.
To test,
On a clean install
- Navigate Home > Administration > Global System preferences > Logs
- AuthoritiesLog is set to "Don't log"
Apply the patch, install koha on a new DB.
- Navigate Home > Administration > Global System preferences > Logs
- AuthoritiesLog should be set to "Log"

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
One line patch, changing the default for new installations only.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10587: fix HTML errors on authority detail page in OPAC

A validator check of the OPAC's authority detail returns a few minor
errors. This patch corrects the errors.

To test, apply the patch and run an OPAC authority detail page through
an HTML validator. There should be no errors which are specific to the
authorities detail template (as opposed to header and footer includes).

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Also checked using the W3C validator and testing the
authority detail page in the OPAC is still correctly
displayed.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 6594: Schema.org structured data for OPAC display

To support schema.org processors, such as Google, Bing, and Yandex,
structure our data so that it has machine-readable attributes. This pass
declares the CreativeWork sub-types as well as Product for the main
bibliographic record details, and uses the Offer type for holdings
information per the W3C Schema Bib Extend community group discussions.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Comments on final patch.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 6594: Move subject keywords schema.org markup into <span> element

Google's rich snippets tool gets confused by the <a property="keywords">
approach, so stuff another span inside the <a> element to remove
confusion with the href attribute.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 6594: Correct schema.org context for item status

We were inserting the <link> element inside an open <td> element, which
HTML parsers, even the most forgiving, do not like very much.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 6594: Schema.org span nesting improvements

So, it turns out that the <a href> was causing a new "chain" to be
invoked, thus nesting the <span> elements for properties within the <a
href> actually caused the properties to be attached to that new chain
rather than the containing object. Therefore, wrap the <span> elements
around the <a href> elements where applicable.

Thanks to Manu Sporny in #rdfa for helping me to sort this out.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
I tested by validating against the Google rich snippet tool,
validator.nu, and linter.structured-data.org. All were satisfied
with the microdata markup, and the properties that are set make
sense.

These patches are only for MARC21 XSLT view, but I think it is worth
pushing them even without the NORMARC and UNIMARC markup, so that
people can start to test out schema.org microdata in Koha, and
refine the implementation.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

FWIW I agree with Jared, it is essentially a no-op in terms of what
the user sees, so is safe.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10130: widen input fields for library configuration

Most input fields in the library entry form (admin/branches.pl) have no
explicit width, so they display with a browser-default width. This patch
gives explicit widths to those fields, giving more room for entry.

Other fields have been given an explicit width and/or maxwidth according
to the database table structure.

To test, add or edit a library in Administration -> Libraries and
Groups. Form fields should be more comfortable for entry, and add/edit
actions should complete correctly.

Signed-off-by: Campbell Reid-Tait <campbellreidtait@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Template changes only, works nicely.
Tested editing and adding libraries in administration.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>