#D8CX: I pledge that FillPDF will have a full Drupal 8 release on the day that Drupal 8 is released.

I went way farther on this than anticipated. Anyway, I'm opening a GitHub repository shortly so I can work openly on this. The GitHub repository is temporary; if you just want to use the stable Drupal 7 version of the module, you should download it from Drupal.org.

Repository: https://github.com/wizonesolutions/fillpdf

Just an update several months later; still working on this, and it's not as blocked by #2359209 as I thought. I'll be continuing to work on this gradually and might even have an almost-release by the time D8 comes out...but that's far from a promise. My main purpose doing the port is to learn D8. But that doesn't mean the code won't be usable.

Changing title to join #d8cx.

Moving module tasks from my to-do app to the issue summary.

Yay, token replacement is working with real tokens and the new entity-based FillPDF Link format. Not everything's perfect, but it works the same way as Drupal 7 (including how it doesn't always handle multiple tokens from different sources in the same fill pattern well yet).

Access checking done! Next: saving to file.

Strategy to port saving to file, etc.:

- Add configuration for fillpdf.scheme to FillPdfAdminForm
- Add configuration for saved-file scheme to FillPdfFormField/FillPdfFormForm
- Port file scheme support for uploading PDF form (save path for the template)
- Enforce that file is subdirectory fillpdf/ prefix in saved file paths
- Port file saving from Drupal 7 (the latest 7.x-1.x code) — including private file support
- Port redirecting

Brain freeze on porting file saving, so writing out my thoughts:

Drupal 7 implementation:

- Determine $action: 'default' by default, which uses the PDF form settings to determine what to do. This is already ported to Drupal 8.
- Actually save the file. To do this, we pass the PDF metadata, a filename, and whether to redirect/redirect to the file/override the destination directory.
- We process those arguments, particularly destination path — we run that through token_replace.
- We ensure the destination directory exists. We error out if it doesn't, or well — do nothing and log it.
- If we're all good, then we save the file and add usage data (including the generation context). We return the file.

Drupal 8 implementation ideas:
- Determine $action in the same way.
- Create a standalone FillPdfGenerationContext class that will play the role of D7's $fillpdf_object (stdClass in D8 is icky)
- Instantiate one, and pass the other arguments as they are now. $destination_path_override might not be needed, since a third-party caller could just mess with the FillPdfGenerationContext.
- Still process tokens in the destination path and ensure it exists
- Save the file, add file usage in the same way
-- Challenge: Currently, I use a $fillpdf_context (the passed-in $context) to determine which entities the PDF references and check access accordingly. I store that in a database table and the use the ID of the record in the file usage entry. This is no problem in D8, but I'm not sure if it should be a ContentEntity or not. It seems excessive to use a ContentEntity since it has no UI, but I want to ask around first.
- Return the file, and in the parent function return the appropriate RedirectResponse.

Also, considering a FillPdfActions standalone class. Main initial function would just be to provide a standard way to save to file. I think a service would be overkill because there isn't that much to inject. Well, I do log an error if the path doesn't exist...so I guess it would be a service. Anyway, yeah. Should be reusable. But not to the point of being a plugin or anything...yet. That's actually a future idea, since it would let people do stuff with PDF results that I haven't thought about. But they have other ways to do that for now.

Decided to implement action plugins now. Bite-size chunks are easier for me to wrap my head around.

Alright, finally got action plugins wired up! Now I can finish porting file saving, and the length of HandlePdfController::handlePopulatedPdf() won't drive me crazy anymore. Need to make a service that actually handles saving the PDF (so that other modules can do it independently). I might move some of the logic for doing stuff to PDFs generally into that service; the controller shouldn't be the owner of so much functionality. Well, one thing at a time. I also want to turn most of the options arrays into objects, but I'm not going to get held up on that.

Realized I've named a lot of things redundantly, so added that to the roadmap. Also, I figured out an easy solution to fixing token replacement (which I should backport to D7): http://drupal.stackexchange.com/questions/177891/most-efficient-way-to-r... (replacing them in reverse order, progressively).

Made some decent progress this weekend. There's much re-architecting going on, and this slows things down, but there's no way around it. Most of the hard-hitting features are in or ready to be added pretty easily, though. Some major remaining parts are import/export of mappings (actually, I'd like to upgrade this to import/export of entire FillPdfForm records + FillPdfFormField mappings, substitutions (transformations), updating the PDF, and redirecting to the PDF.

Also...tests.

Finally using file fields instead of entity references for files. While I'm in this mode, I'm going to go through and write proper entity access classes for the entity types I define and make the forms use these.

PDF generation, due to its nature (being a link not clearly-connected to any form or route), will still use FillPdfAccessController::checkLink()...at least, I think it will. I have to separate the access-checking functionality out into a service that takes a $context and tells me if access is granted. I need that for FillPdfFileContextAccessControlHandler::checkAccess(), which basically does the exact same thing, just with FillPdfLinkManipulator::parseLink()(instead of ::parseRequest(), and it uses the fillpdf_file_context.context field.

File saving and handling of private files is DONE! There are general tweaks to be made that will affect this, but the functionality itself is working.

I also updated the issue summary. i haven't written it there, but I've written up a timeline in my own notes, and I think I can get this done during DrupalCamp Oslo (Nov 14 or 15). If so, I'll release an rc1. So if you are watching this issue, keep an eye out for that! (I'll tweet and such.)

Adding a real FillPdfLinkContext object to roadmap.

Huh, switching to file fields broke my fillpdf_forms view. Need to look into this and see if I can format it as a file URI again somehow. Maybe there's some other widget I can use somehow in contrib.

Updating remaining action items. Getting there!

If you didn't notice, there's an alpha out now. See the project page if you want to try it out. I'll be continuing to work on it and move towards making it feature-complete according to the must-port features in the issue summary.

Hi, I'm at a Drupal 8 release party in Trondheim. During the party, I finished the module. Time to release!

Symbolically changing to Needs Work because I need to open follow-up issues.

#D8CX promise: FULFILLED.

Abandoning Coder fixing until I figure out #2624076: Support namespace aliases in /** @var */ definitions or it's resolved.

Follow-ups created. See you there!