Problems with Kirby 2.5.6
Closed this issue · 15 comments
At least as of Kirby 2.5.6 ( Kirby 2.5.0 is OK), it would appear that staticbuilder no longer sets the
'staticbuilder.baseurl' => 'https://www.domain.net/'
correctly?
With php like:
<?=css('file.css')?>
<?=js('scripts.js') ?>
there are others e.g. it is the same with images using things like $page->images()->first()->url().
They all have the local domain URL rather than the 'staticbuilder.baseurl'
so 'http:/local.dev/' rather than the desired 'https://www.domain.net/'
Other base URL's seem to be OK.
Any ideas?
Does the asset() function still work (with e.g. asset('css/file.css'))?
Not sure what might have gone wrong, except if the implementation for these functions changed.
@lukasbestle I see that you worked on the URL class in the latest toolkit, could this be related?
For the record, the way StaticBuilder applies the staticbuilder.baseurl option is a bit hackish:
https://github.com/fvsch/kirby-staticbuilder/blob/master/src/Builder.php#L130-L145
A workaround might be to change your overall Kirby config to use c::set('url', 'https://www.domain.net/'); and then run a static build. Not sure it'll let you load the /staticbuilder/ page on a local domain if you do that though, unless you change your /etc/hosts to pretend that www.domain.net is your local machine and change your VirtualHost accordingly. :P
Also I don't want to dissuade anyone from using StaticBuilder because I think it's decent code and serves a purpose, but it does require some fiddling around to bypass some of Kirby's limits. I think you've seen that before. ;)
Frankly I'm tempted to stop this project altogether for Kirby 3, and perhaps work on something a bit different that doesn't rely on Kirby's PHP stack but "just" parses the content folder. Like metalsmith or Jekyll but for Kirby content, partly inspired by Kirby's API.
Note that there already is a project like this: https://enoki.site/
Though I tend to disagree with the scope (I don't see a need to reinvent Kirby's Panel and, respectfully, I am not a fan of that approach from a moral standpoint either).
Hmmm do your mean like <?php echo asset('css/styles.css')?>, which throws an error, 'Call to undefined function asset()' ?
It seems to work OK in 2.5.2 as well, so I will revert, shame though, I really liked this plugin - pretty much Kirby front end, bit of processing to static and straight to Netlify, all from the Kirby panel ;-)
I did have have a look at enoki, obviously not as developed as Kirby, but I guess following very similar ideas, but with Javascript rather than PHP. I'll have to wait to the weekend to try and have a proper look.
Why is it they always choose the .txt extension when all Markdown editors now uses ,md as default?
Let me know if you get anywhere with Lukas.
My bad, no asset() function in Kirby, I mixed it up with Symfony and a few others.
So the right test would be with the url() function. What does this output when building with StaticBuilder (please check you have the latest version) and Kirby 2.5.6?
<pre>
css: <?= css('file.css') ?>
js: <?= js('scripts.js') ?>
url: <?= url('assets/css/file.css') ?>
</pre>
I though you might have been confusing asset() ;-)
Toolkit version: 2.5.6
Kirby version: 2.5.6
Panel version: 2.5.6
As for
<pre>
css: <?= css('file.css') ?>
js: <?= js('scripts.js') ?>
url: <?= url('assets/css/file.css') ?>
</pre>sadly they all point to the local domain rather than the specified one.
For the record, the way StaticBuilder applies the staticbuilder.baseurl option is a bit hackish:
https://github.com/fvsch/kirby-staticbuilder/blob/master/src/Builder.php#L130-L145
Have you tried setting the URL with $kirby->url($url)?
Frankly I'm tempted to stop this project altogether for Kirby 3, and perhaps work on something a bit different that doesn't rely on Kirby's PHP stack but "just" parses the content folder. Like metalsmith or Jekyll but for Kirby content, partly inspired by Kirby's API.
Kirby 3 will be a lot more flexible and extensible. The different parts aren't as intertwined as they are at the moment. So it will probably be a lot easier. :)
I'll have to try.
For the record, https://github.com/kaliop/frontend-style-guide uses Kirby 2.5.6 and StaticBuilder 2.1.0 and I'm not sure I'm seeing the same issue.
Config: https://github.com/kaliop/frontend-style-guide
Template: https://github.com/kaliop/frontend-style-guide/blob/master/site/snippets/layout.twig
I'm using href="<?= $site->url() ?>/assets/foo.css" to link to static assets though.
Florens/Lukas, thanks for your efforts.
Florens Try <?=css('assets/file.css') ?>.
Obviously something has changed between Kirby 2.5.2->2.5.6, when reverting to the earlier version of Kirby, it all works as it should.
Lukas, not sure what you mean by
Have you tried setting the URL with $kirby->url($url)?
Our Kirby StaticBuilder Plugin is 2.1.0.
Okay, I can reproduce the problem.
@lukasbestle The breaking change was probably this commit:
getkirby/kirby@9cc028c#diff-c421f7e7f129fbd578909e641f1c9546
In StaticBuilder I'm calling kirby()->configure() after changing c::set('url', ...) to override Kirby's config while building the HTML for pages. This commit disallows it.
Instead I could use new Kirby() to override the current instance, but I'm not sure I want to open this can of worms. 👅
Since I'm "only" overriding URLs, I'm probably going to manually override every single occurrence of the base URL in the toolkit objects and Kirby instance. Dirty stuff, but hey.
Have you tried what I proposed above? Because that would be the proper way to do it.
Yes, not doing much in my tests -- $kirby-urls()->foo() gets fixed but that does not impact page urls and it does not impact the js and css helper functions in my tests.
Oh, I see. It looks like you need to do this:
$kirby->url($url);
url::$home = $kirby->urls()->index();Also a bit of a hack, but at least not quite that invasive.
@lukasbestle I made the following changes: #36
@shoesforindustry Can you get the url-override-fix branch and confirm if it works for you with Kirby 2.5.6?
Awesome work Florens/Lukas, I just copied the new src/Builder.php over my local one and it all seems to work as expected, all domains are the ones specified, thank you both!
The fix is now in release 2.1.1, which can be installed with Composer or Kirby’s CLI.