PHP+Apache web server for calibre ...

[chaley]

Regarding searching: if a tag (or other value) has a leading or trailing blank, then an equality test will fail. The DB isn't supposed to have any of these, but I suppose it is possible that some sneaked in. I will fix this.

[ldolse]

Huh, it seems to be related to searching two different fields then. In my case I was searching for an author name (though not by tag in that case)

This search will reproduce it in your demo server:

Conrad and not Tags:=Classics

Should give 0 results, gives 1 instead.

To answer your other question, both 'Tags:=Nopub' and 'not Tags:=Nopub' yield the expected results by themselves.

[chaley]

Originally Posted by ldolse

This search will reproduce it in your demo server:

Conrad and not Tags:=Classics

Should give 0 results, gives 1 instead.

The bug here is that I didn't lower-case the field name. There is no field named 'Tags'. If you change it to 'tags:=classics', it works.

Could this bug explain your other problems?

I will fix this and make a release shortly. I will also look at giving an error if a field name doesn't exist.

[chaley]

Release 0.1.5 is out. I hope it fixes the search problems.

Change log:

Spoiler:

   34 charles <>	2010-11-06 {REL 0.1.5}
      Release

   33 charles <>	2010-11-06
      Give error message if unknown field names are used.

   32 charles <>	2010-11-06
      Add the current server code version to the footer

   31 charles <>	2010-11-06
      Fix case problem for search terms.

   30 charles <>	2010-11-06
      Fix the leading and trailing blanks problem in a more general fashion.

   29 charles <>	2010-11-06
      Add search term translation (e.g., tag: -> tags:).

   28 charles <>	2010-11-06
      Improve performance of case-insensitive path matching by caching results

   27 charles <>	2010-11-06
      Trim leading and trailing blanks from values before searching

   26 charles <>	2010-11-05 {REL 0.1.4}
      Release

[ldolse]

Thanks! Seems to be working now - just got a chance to change the server config now, was testing from my phone before.

I'll let you know if I run into any other difficulties, but seems pretty to be working quite well at this point.

Are the results OPDS compliant, or is this just a catalog browser? It's cool if it's not, if that's the case I'm thinking of using your PHP server as the master catalog browser, and then use Calibre2OPDS to generate Stanza/Aldiko catalogs for friends/family using the respective devices for those apps.

[chaley]

Originally Posted by ldolse

Thanks! Seems to be working now...

Good.

Are the results OPDS compliant, or is this just a catalog browser? It's cool if it's not, if that's the case I'm thinking of using your PHP server as the master catalog browser, and then use Calibre2OPDS to generate Stanza/Aldiko catalogs for friends/family using the respective devices for those apps.

No. However, the output is mobile browser friendly. There isn't any javascript. It works well with Opera Mobile, which is what I have on my phone.

Would have per-user restrictions be of any use? It wouldn't be hard to do.

[ldolse]

Per user restrictions would be nice, but not critical. I was planning on password protecting it and giving out user accounts at the server level with standard 401 auth. Would you just use that user ID, or were you thinking of creating accounts within your server?

[chaley]

Originally Posted by ldolse

Per user restrictions would be nice, but not critical.

They were easy to do, and are in the latest release V0.1.6.

I was planning on password protecting it and giving out user accounts at the server level with standard 401 auth. Would you just use that user ID, or were you thinking of creating accounts within your server?

I assume that all authentication is handled by the web server. Both IIS and Apache supply the current user ID, so no reason to reinvent that wheel.

[ldolse]

Thanks for that - it will be useful. Tested it out and seems to work well.

Finally got my library in a presentable state, which is why it's taken a bit to reply. Now that almost all my books have covers, I discovered one bug. It's showing up when viewing covers, though it may affect other requests, not sure. Basically if the title has a single quote - ' - anywhere in the title then the cover won't display. I'm guessing the single quote needs to be escaped somehow in cover.php, but not sure how to go about that.

[chaley]

Originally Posted by ldolse

Basically if the title has a single quote - ' - anywhere in the title then the cover won't display. I'm guessing the single quote needs to be escaped somehow in cover.php, but not sure how to go about that.

I can't repeat this.

The URLs passed for the cover are already escaped. (See book_base.php, line 31). For example, the URL I see for the book "1632' (I messed with the title) is
index.php?m=cover&c=Eric+Flint%2F_1632%27+%281262% 29%2Fcover.jpg

It could be that the file system your library is coming from does something with quotes. Check to see whether or not the quote is really there in the path, or whether it has been translated to something else.

I will be off-line for a while, so take your time. It will be the end of November before I can get back to it.

[ldolse]

Weird, it's quite reliable on my system - I've got dozens of books with single quotes in the title, and all are exhibiting this. I'm not seeing single quotes get escaped automatically though...

Here's an example:
Local filesystem:
/Users/userid/Documents/MyeBooks/Douglas Adams/Dirk Gently's Holistic Detective Agency (754)/cover.jpg

Actual URL on the Web Server (can be viewed here):
/ebooks/Douglas Adams/Dirk Gently's Holistic Detective Agency (754)/cover.jpg

URL passed from the PHP script (displays generic book cover):
/CalibrePHP/index.php?m=cover&c=Douglas+Adams%2FDirk+Gently%27 s+Holistic+Detective+Agency+(754)%2Fcover.jpg

No worries about the time, thanks for checking into it.

Edit - I now see that the single quote is escaped in the actual html generated by the PHP, but when the browser actually goes to it it converts it back to a single quote - pasting the URL into the browser location bar will illustrate it. Anyway either way the book cover isn't found.

[chaley]

Originally Posted by ldolse

Weird, it's quite reliable on my system - I've got dozens of books with single quotes in the title, and all are exhibiting this. I'm not seeing single quotes get escaped automatically though...

Random thought before I check out -- make sure that the PHP option magic_quotes_gpc is turned off. It could cause some difficulties.

[ldolse]

I was doing some research/testing on this - just posting it here for when you get back online, or in case there is another PHP expert out there with some input.

There are lots of discussions out there indicating PHP just doesn't behave well with single quotes in directories/filenames. Unfortunately the most frequent recommended solution is to not use them, which isn't really acceptable since these map to Calibre titles.

My first thought was to work around this using various unicode apostrophe alternatives. I was hoping Calibre would convert these to underscores like it does some other characters. Unfortunately Calibre was too smart for me and mapped these to ascii single quotes at the filesystem level.

I dug further into the PHP code to see what was going on. Single quotes are handled a bit oddly. While the encoded URL shows just only the single quote, when I actually print the $path variable it's showing up a bit oddly:

 Douglas Adams/Dirk Gently/'s Holistic Detective Agency (754)/cover.jpg

I tried doing a str_replace - converting "/'" to "'". The replacement itself seems to have worked, but the file still was not found at the new path.

Regarding magic_quotes_gpc, I haven't had much luck completely disabling that, following the directions for disabling it using .htaccess didn't seem to work, though magic_quotes_runtime is disabled - maybe that's all that's required. Nothing I've changed there has made a difference though.

[ldolse]

One other thing, had to add a few mimetypes to mimetypes.php - finfo is not supported in php 5.2:

		'rtf'   => 'application/rtf',
		'lit'   => 'application/x-ms-reader',
		'doc'   => 'application/msword',
		'zip'   => 'application/zip',

[chaley]

Originally Posted by ldolse

I was doing some research/testing on this - just posting it here for when you get back online, or in case there is another PHP expert out there with some input.

There are lots of discussions out there indicating PHP just doesn't behave well with single quotes in directories/filenames. Unfortunately the most frequent recommended solution is to not use them, which isn't really acceptable since these map to Calibre titles.

My first thought was to work around this using various unicode apostrophe alternatives. I was hoping Calibre would convert these to underscores like it does some other characters. Unfortunately Calibre was too smart for me and mapped these to ascii single quotes at the filesystem level.

I dug further into the PHP code to see what was going on. Single quotes are handled a bit oddly. While the encoded URL shows just only the single quote, when I actually print the $path variable it's showing up a bit oddly:

 Douglas Adams/Dirk Gently/'s Holistic Detective Agency (754)/cover.jpg

I tried doing a str_replace - converting "/'" to "'". The replacement itself seems to have worked, but the file still was not found at the new path.

Regarding magic_quotes_gpc, I haven't had much luck completely disabling that, following the directions for disabling it using .htaccess didn't seem to work, though magic_quotes_runtime is disabled - maybe that's all that's required. Nothing I've changed there has made a difference though.

I will change the server to use calibres ID, which is numeric. That costs an extra DB lookup, but it eliminates the problem. (brief because very slow wireless on phone)