Replace offering to email MOBI with EPub

[dunxd]

Amazon are soon to stop accepting MOBI files for conversion and sending to Kindle in favour of ePub.

This may not be the best way to enable sending ePub's, especially for people that want to send MOBI somewhere other than Amazon. However, I couldn't figure out how to enable ePub's at all if MOBI files already exist. Is there a way of allowing sending all formats?

[mikespub]

The array in this function basically ranks the available formats from least to most preferred. So if MOBI is at the end of the array and is available, the book data corresponding to that format will be selected and returned here.

I haven't played with the email functionality yet, and there doesn't seem to be much security around it either, so in principle you could send any book format to anyone...

If you're sure that the preferred order for Kindle is now EPUB, PDF, AZW3 and never MOBI anymore, I could merge this into the code, or make it another config variable if things are likely to change later on...

[dunxd]

$bestFormatForKindle = ['PDF', 'AZW3', 'MOBI', 'EPUB'];

would be better then.

I'm still learning github. I'm not sure how to update this pull request to reflect the above. Any pointers?

[mikespub]

Right now you submitted this pull request from your main branch to upstream (*) main branch, as you can see right under the title:

[dunxd] wants to merge 2 commits into [mikespub-org:main] from [dunxd:main]

From now on, any further commits you make to your main branch will then auto-magically appear as extra commits in this pull request - at least until it's closed by you or upstream maintainer.

So in short term for the Kindle MOBI issue, you can update your main branch and it will become part of this pull request too.

For future changes (about other things), you would typically follow this sequence:

1. merge any upstream changes from upstream main branch to your main branch first
2. create a new "feature" (or bug) branch from your main branch, and adapt/fix things there
3. create a pull request from your "feature" branch to upstream main branch -> this will become a new pull request to upstream
4. merge your "feature" branch to your main branch if you want to continue working

At some point after that, upstream may or may not merge that pull request as is, but in the meantime you can still change things in the "feature" branch while keeping the main branch clean.

Assuming the pull request is merged (mostly) as is into upstream main branch, the next time you do step 1 above to update your main branch, it will merge with any tweaks upstream may have added, and you can delete your "feature" branch.

There are other ways of cooperating between git repos, but that's probably the most common approach for "simple" open source projects. For upstream projects with several branches e.g. per development cycle, you may replace main above with whichever branch(es) they recommend you work from.

(*) upstream = my repo or mikespub-org/seblucas-cops in this case

[dunxd]

Thanks so much. I hadn't been able to find that described in the github docs (probably I was looking in the wrong place). I made the change and it is indeed right here above! I understand what you mean about branching. I'll make branches in my fork from now on, and use those to submit pull requests.

[mikespub]

Perfect, thanks