Files
InvoiceShelf/tests/Unit/GotenbergCompanionViewTest.php
Darko Gjorgjijoski 713e0bc2e8 feat(pdf): repeating page headers and footers, and page numbers (#729)
Takes over #690 by csoscd. The companion-view idea is theirs; this reworks it
onto the shared page setup and fills in the gaps that stopped it landing.

A `{template}_header` or `{template}_footer` view next to a template is rendered
alongside it and repeated by Chromium on every page. The suffix resolves through
the pdf_templates:: namespace too, so custom templates get it with no extra
wiring.

Two things had to change for that to be useful.

Companion views are now hidden from the template picker. getFormattedTemplates()
lists every .blade.php it finds, so an invoice1_footer would otherwise appear as
a separately selectable template with no preview image -- the feature would have
introduced that the moment anyone used it.

And it does something out of the box. #690 shipped no companion views, so both
of its margin settings were visible no-ops until someone hand-wrote a Blade file.
Instead there is a pdf_page_numbers setting, off by default, that supplies a
footer when a template has none. A template's own companion still wins, so
turning page numbers on cannot overwrite a designed footer.

The setting sits under Gotenberg because only Chromium can repeat a footer;
dompdf has no equivalent. Its value is still carried by the dompdf form so
saving from there cannot clear the choice -- the field is absent from that
payload, and the controller only writes it when present.

Margins come from the page setup rather than #690's separate header_margin and
footer_margin. Chromium draws header and footer inside the page margin, so the
existing margins are the space they occupy; two more settings for the same
distance would have been a second way to say the same thing.

Verified against a live gotenberg:8 on a two-page document: off produces no
footer, on produces "1/2" and "2/2" on the respective pages, and a companion
footer replaces both.

#690's own test is not carried over. It asserted nothing: a bare
View::shouldReceive('exists') is an allowance rather than an expectation,
andReturn(false) never entered the companion branch, and the call sat inside
try { } catch (Throwable) { }, so it passed with the feature deleted.

Claude-Session: https://claude.ai/code/session_01QmECndmNZwzN65Zz9P87dF
2026-08-01 12:52:47 +02:00

98 lines
3.2 KiB
PHP

<?php
use App\Support\Pdf\GotenbergPdfDriver;
use Illuminate\Support\Facades\File;
use Illuminate\Support\Facades\View;
/**
* Chromium repeats a header/footer template on every page. A `{template}_header`
* or `{template}_footer` view alongside the document opts into that, and page
* numbers are the built-in footer for templates that supply none.
*
* Assertions are on the multipart request rather than a rendered PDF, so no
* Gotenberg service is needed. The rendered check against a live gotenberg:8 is
* in the PR description.
*
* Views are written to a temp namespace rather than resources/views so they stay
* out of the template picker and out of the render test's glob.
*/
beforeEach(function () {
config([
'pdf.connections.gotenberg.host' => 'http://gotenberg.example.com:3000',
'pdf.page.page_numbers' => false,
]);
$this->views = sys_get_temp_dir().'/is-companion-'.uniqid();
File::ensureDirectoryExists($this->views);
View::addNamespace('companion', $this->views);
$this->writeView = function (string $name, string $contents) {
File::put($this->views."/{$name}.blade.php", $contents);
};
($this->writeView)('doc', '<html><body>document body</body></html>');
});
afterEach(function () {
File::deleteDirectory($this->views);
});
function companionRequestBody(string $view = 'companion::doc'): string
{
return (string) (new GotenbergPdfDriver)->buildRequest($view)->getBody();
}
test('a template with no companions and no page numbers sends neither', function () {
$body = companionRequestBody();
expect($body)->not->toContain('header.html')
->and($body)->not->toContain('footer.html');
});
test('a companion header is sent alongside the document', function () {
($this->writeView)('doc_header', '<div>COMPANION HEADER</div>');
$body = companionRequestBody();
expect($body)->toContain('header.html')
->and($body)->toContain('COMPANION HEADER')
->and($body)->not->toContain('footer.html');
});
test('a companion footer is sent alongside the document', function () {
($this->writeView)('doc_footer', '<div>COMPANION FOOTER</div>');
$body = companionRequestBody();
expect($body)->toContain('footer.html')
->and($body)->toContain('COMPANION FOOTER');
});
test('page numbers supply a footer when the template has none', function () {
config(['pdf.page.page_numbers' => true]);
$body = companionRequestBody();
expect($body)->toContain('footer.html')
->and($body)->toContain('pageNumber')
->and($body)->toContain('totalPages');
});
/**
* A template that went to the trouble of defining a footer should keep it, so
* enabling page numbers must not overwrite it.
*/
test('a companion footer wins over the page-number default', function () {
config(['pdf.page.page_numbers' => true]);
($this->writeView)('doc_footer', '<div>COMPANION FOOTER</div>');
$body = companionRequestBody();
expect($body)->toContain('COMPANION FOOTER')
->and($body)->not->toContain('pageNumber');
});
test('page numbers stay off by default so existing documents are unchanged', function () {
expect(config('pdf.page.page_numbers'))->toBeFalsy();
});