I think you can render the page via the tpl::load function (more info). That way you wouldnât need to do the hassle with setting up a âhackâ-content representation, but could render the page into a variable inside the controller.
Only grabbing the <main> contents, would be possible with a regex on the returned string from the tpl::load function I think.
so i ended up testing both options only today and:
the tpl:: approach spits back an error saying that Call to a member function title() on null from the code i have in my header.php snippet
the $kirby->render approach keeps saying it is rendering a null object, no matter which page or url i tried to load
the only reason i went back to this is that i was using file_get_contents() to call another page and render it through mPDF. But on the production server with SSL, this gives me an error (could be because is php 5.6 â iâm not the sysadmin in this case and canât upgrade the server software stack).
it would be great if i did not have to work with ssl certificates and php, and just being able to fetch the html of this page to feed into the mPDF function
The problem with using the tpl::load() method is that you have to pass all data first down to the template in the $data variable and then again down to the snippets.
What about the $kirby->render() mode? Why is it throwing an error?
Also, I canât find any documentation about it.
Yes, I can probably use AJAX for this as well (which I never used before tbh), just was trying to avoid extra overheads and keep it as basic as possible. I have the feeling AJAX might throw some CORS problem or some SSL-related hiccups.
does it change the fact that i am calling $kirby->render() on a controller?
OK, working perfectly on a template, the dumb error is that in a controller there is no $kirby variable â and feeding that into the mPDF plugin directly was hiding the kirby error.
so the kirby()->render() works perfectly in certain pages, and not in others. i debugged a bit, changing bits here and there and see if it was making a difference, but it seems it doesnât and i have no clear idea of why it is like this.
The error message means that you donât have a page object but a boolean here, so obviously this bit
page('shop/' . str::slug($item[0]))
doesnât give you a page. Since I donât know what the $o_desc array or each $item contains, I canât tell. But I canât repeat it often enough:
NEVER call an objectâs method without making sure you really have an object! Then at least you donât get an error message (even if it means you donât get the expected result either).