[GUI Plugin] FanFicFare

[bigwoof]

Originally Posted by JimmXinu

New Test Version Posted

2024-01-10
- Swap out SuperFastHash implementation #1026

Figured out the issue with the chapter and BrowserCache. I even opened an issue(#1026) to record it.

bigwoof, let me know if this fixes it for you.

This has fixed the issue for me! Thanks! :-)

I also thought it was some caching flag in the header but could not find anything obvious.

A bug in the hashing function.. wow!! that's so rare...

I wonder if this will also fix the error I have with the browser cache on chrome where if the cache has been around for a while (say a few days), FanFicFare will just throw a "not in cache" error on new books even after you load them up in the cache (which is quite annoying after you spend the time to load up all the new chapters in the cache).

I work around this now by just clearing the cache before any big sync.. will monitor..

[JimmXinu]

Originally Posted by bigwoof

I wonder if this will also fix the error I have with the browser cache on chrome where if the cache has been around for a while (say a few days), FanFicFare will just throw a "not in cache" error on new books even after you load them up in the cache (which is quite annoying after you spend the time to load up all the new chapters in the cache).

Probably not?

Looking at the FFF debug output, Chrome doesn't update the 'creation' timestamp in the cache when clicking back and forth between chapters, on plain reload (ctrl-r), but it does on forced reload (ctrl-shft-r).

When clicking back and forth between chapters, Chrome's F12 networking debug shows a 200 OK (successful download) instead of a 304 Not Modified, which I see for plain reload (ctrl-r).

So I don't know what's going on there. Nor do I see any additional info in the cache I could use to better refine it.

What I can offer for that issue is: you can change FFF's browser_cache_age_limit setting. It's a float value of hours, -1 will use any found cache entry, regardless of age.

[bigwoof]

Originally Posted by JimmXinu

Looking at the FFF debug output, Chrome doesn't update the 'creation' timestamp in the cache when clicking back and forth between chapters, on plain reload (ctrl-r), but it does on forced reload (ctrl-shft-r).

When clicking back and forth between chapters, Chrome's F12 networking debug shows a 200 OK (successful download) instead of a 304 Not Modified, which I see for plain reload (ctrl-r).

Thanks for the explanation! :-)

Originally Posted by JimmXinu

What I can offer for that issue is: you can change FFF's browser_cache_age_limit setting. It's a float value of hours, -1 will use any found cache entry, regardless of age.

yeah, I'm already using that and it helps somewhat. some of the quirks I see are

1. the cache just stops working after a few days and FFF outputs a "file not in cache" error (forgot the actual error name) -- solution: clear the cache frequently before accessing the new pages you want FFF to download

2. some epubs (especially new single chapter epubs) *always* get reloaded by FFF even if you have a fresh cache and have access that epub and force-reload etc. -- solution: live with it. it just makes the whole download process a little longer and causes chrome windows to appear in the middle of your work :-)

[JimmXinu]

New Test Version Posted

2024-01-14
- Fix estimatedWords site metadata for SB/SV - thanks mx-sylveon!

[applegaa]

How hard would it be to allow image pages from Literotica? They just have a "/i/" in place of the "/s/" in the URL. Otherwise, they seem to be identical in page design.

I ask because I have a couple of fantasy stories where the author has included a world map that I would like to include in an anthology with the story.

- Andrew

[JimmXinu]

New Test Version Posted

2024-01-15
- Allow image/comic (/i/) and poems (/p/) on literotica

Originally Posted by applegaa

How hard would it be to allow image pages from Literotica? They just have a "/i/" in place of the "/s/" in the URL. Otherwise, they seem to be identical in page design.

It's not quite that simple, but it also doesn't seem to be much more complex.

Literotica site is kind of a pain to support and I don't read it, so I don't have many examples to test with. No promises this change will stay if it breaks normal stories.

[applegaa]

Originally Posted by JimmXinu

New Test Version Posted

2024-01-15
- Allow image/comic (/i/) and poems (/p/) on literotica

Thanks!

So far it's performing perfectly, although I haven't tried any poems.

- Andrew

[ownedbycats]

If no series is provided by the adapter (either because the site has no series, or because it's empty), will the Calibre metadata series be overwritten by a blank?

[JimmXinu]

No. You can manually add a series and it will be retained.

[JimmXinu]

New Test Version Posted

2024-01-17
- Fix for site change, adapter_deviantartcom. #1030

[JimmXinu]

FYI, I got (another) notice from Google today that Google Workspace accounts (eg, accounts with your own domain vs gmail.com addresses) won't allow IMAP without OAUTH2 later this year.

I've researched it (again), and what I said in Jun 2022 still applies:

Originally Posted by JimmXinu

Google seems to be on a path towards requiring more security for GMail, with an apparent end point of requiring all apps accessing it:

1. To be 'verified', a process apparently very heavily tilted towards web services, not things like FFF, see link;
2. Use their RESTful APIs (instead of standard email IMAP4), preferably with their python libraries--which are some 30Mbytes vs FFF's current 1.8Mbytes; and
3. Authenticate through OAuth2, which requires a manual user interaction with Google in a browser, whether that's an instance started in FFF, or the user opening a URL in separate browser, and copying codes back and forth. No idea how often.

Gmail appears to be trying to pull into a more walled-garden kind of place in the name of security.

Which is kind of good--Email is really old and it's original security was non-existent. OTOH, it's also hilarious--you've already given all your data to Google, the largest data mining/advertising company to have ever existed.

I added Email fetching because it uses standard interfaces and was relatively easy. I have always included the warning:
It's safest if you create a separate email account that you use only for your story update notices. FanFicFare and calibre cannot guarantee that malicious code cannot get your email password once you've entered it.
Use this feature at your own risk.

For the time being, I think my official answer for GMail is going to be the "Sign in with App Passwords" feature. Bonus: It works with accounts set to two factor authentication.

If they do take away App Passwords too, GMail will probably become unsupported in FanFicFare and the answer will be 'use a different email provider for your separate fanfic notices account'.

I've changed my own notifications account (a Google Workspace account) to be 2FA and use an App Password for FFF IMAP access. So that still works as of now.

[MerlinMama]

I am taking a shot in the dark on this one.

When adding new fics, is there a way to give the stylesheet a particular name? I name them per year (example, now I rename it to 2024style.css) this way I know later if the fic has the latest stylings or not. I have my stylesheet done up in my .ini, but it would be perfect if, after adding a new fanfic, it could have the up-to-date name already.

No problems at all if it can't be done. I make lots of changes all the time, so I might even have to name them year and month at this rate LOL!

[JimmXinu]

Originally Posted by MerlinMama

When adding new fics, is there a way to give the stylesheet a particular name?

FFF hard codes stylesheet.css. I'd suggest putting the date in a comment in your CSS.

You might also look at the _filelist feature for frequent CSS changes.

[culytera]

Is it possible to dynamically change a value in output_css depending on the value of an entry? For example, I want to change the background-color according to the rating of a work.

I thought it would work if I add an extra entry ao3_bg, include the rating values to it, then change its value to certain hex color codes without the hash character then do

replace_metadata:
 ao3_bg=>General=>527200
 ao3_bg=>Teen And Up=>A69905
 ao3_bg=>Mature=>AD5600
 ao3_bg=>Explicit=>980101
 ao3_bg=>Not Rated=>1B1B1B

background_color: ao3_bg
add_to_output_css:
 body.fff_titlepage {
  background-color: #%(background_color)s;
 }

but of course that didn't work due to... parsing? Wrong syntax? Just not possible?

[JimmXinu]

The %(var)s substitution is a built-in feature of the INI file parser. It doesn't know anything about FFF metadata entries. (Honestly, I'd rather it didn't--we have to escape % to %% far more often than it's useful.)

I was all set to tell you it's not possible, when I realized, holy crap, it is! An ugly way I'm mildly ashamed of, but a way.

Way back when, I stuck output_css into the story metadata as a convenient (if cheesy) way to pass it to the writer code. And it's been that way ever since.

Which means output_css can be edited by replace_metadata.

Here's the basic version that works for me. Needed to add "Audiences" to use == matching.

[archiveofourown.org]

## fff_titlepage_color_replace can be something else, but it should 
## be unique within output_css and  ideally not conflict with regex
## The final FFFFFF line is just to make it a real color if nothing else matches.  

add_to_replace_metadata:
 output_css=>fff_titlepage_color_replace=>527200&&rating==General Audiences
 output_css=>fff_titlepage_color_replace=>A69905&&rating==Teen And Up Audiences
 output_css=>fff_titlepage_color_replace=>AD5600&&rating==Mature
 output_css=>fff_titlepage_color_replace=>980101&&rating==Explicit
 output_css=>fff_titlepage_color_replace=>1B1B1B&&rating==Not Rated
 output_css=>fff_titlepage_color_replace=>FFFFFF

add_to_output_css:
 body.fff_titlepage { background-color: #fff_titlepage_color_replace; }