mirror of
https://github.com/InvoiceShelf/InvoiceShelf.git
synced 2026-08-05 23:52:14 +00:00
feat(pdf): let payment receipts and reports be overridden too (#731)
Only invoices and estimates could be customised. Payment receipts and all five
reports were hardcoded to app.pdf.*, so changing them meant editing files inside
the image -- and losing the edit on the next upgrade.
Those documents have no template picker and no design to choose between, so
overriding one is not a selection: it is a same-named file in
storage/app/templates/pdf/{type}/ winning over the built-in. PdfTemplateUtils::
resolveView() is that rule, and it needs no setting, no column and no UI.
resolveView asks View::exists rather than checking the storage disk. The disk and
the view namespace are registered separately and could disagree about where
custom templates live; asking the thing that will actually render removes that
possibility.
make:template covers the new types. Their names are not free, since an override
replaces one specific document, so it validates against the real list -- 'payment'
for payments, and the five report names -- and reports what is available when the
name is wrong. Neither type gets a preview image written, having no picker to
show one in.
The payment preview route also went through the built-in view directly rather
than the service, so ?preview ignored an override and rendered with none of the
shared data. It goes through the service now, like invoices and estimates.
Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF
This commit is contained in:
committed by
GitHub
parent
8ab860a1ae
commit
05e8acc3b1
@@ -4,6 +4,7 @@ namespace App\Support\Pdf;
|
||||
|
||||
use Illuminate\Support\Facades\File;
|
||||
use Illuminate\Support\Facades\Storage;
|
||||
use Illuminate\Support\Facades\View;
|
||||
use Illuminate\Support\Str;
|
||||
|
||||
class PdfTemplateUtils
|
||||
@@ -106,6 +107,28 @@ class PdfTemplateUtils
|
||||
return array_values($formatted);
|
||||
}
|
||||
|
||||
/**
|
||||
* The view to render for a document, preferring a custom override.
|
||||
*
|
||||
* Invoices and estimates let you pick between several designs, so their
|
||||
* template is chosen per document. Payment receipts and reports have no
|
||||
* chooser and no design to pick, so overriding one means dropping a
|
||||
* same-named file into storage/app/templates/pdf/{type}/ and having it win.
|
||||
* That keeps the whole feature to "the file exists, so use it" and needs no
|
||||
* setting, column or picker.
|
||||
*/
|
||||
public static function resolveView(string $templateType, string $templateName): string
|
||||
{
|
||||
$custom = sprintf('pdf_templates::%s.%s', $templateType, $templateName);
|
||||
|
||||
// View::exists rather than a disk check: the namespace is what actually
|
||||
// renders, so asking it directly means the two cannot disagree about
|
||||
// where custom templates live.
|
||||
return View::exists($custom)
|
||||
? $custom
|
||||
: sprintf('app.pdf.%s.%s', $templateType, $templateName);
|
||||
}
|
||||
|
||||
/**
|
||||
* Returns custom template path
|
||||
*
|
||||
|
||||
Reference in New Issue
Block a user