fvsch / kirby-staticbuilder Goto Github PK

Accidentally closed this issue and couldn't open it again so I created a new one: #23

In https://github.com/fvsch/kirby-staticbuilder/blob/master/src/Builder.php#L402
catch exceptions (and possibly Error for PHP7) and add the error to the log instead of letting PHP throw a Fatal Error: Uncaught exception.

Tried that before and it didn't work but I think it was because I was trying to catch a PHP error in PHP 5.5-5.6, but didn't manage the Exception use case.

Possibly related: #23.

Hello, I cannot get this plugin to work.

I keep getting redirected to: http://localhost:8000/STATICBUILDER_URL_PREFIX/STATICBUILDER_URL_PREFIX every time I click on "build everything"

If I try to build a single page, I'm not redirected but an error is shown on the page:

Error: Cannot find page for "STATICBUILDER_URL_PREFIX/STATICBUILDER_URL_PREFIX"

It happens on both PHP 5.5 and 7.0

Already tried #17 but same result.

PS: the site is multilingual and I'm using the one-pager solution from Kirby's cookbook I'm not sure if that is related. (anyway, regarding this one-pager solution, I was already counting on merging the .html files after building, but I wonder if your plugin is capable of finding out that each page is being served as a section)

Thanks

Not sure we want to do something here. What use case would it serve?

Theoretical use case:

1. There is a staging server with the Panel and one or more users in the admin group (or other configurable group?).
2. Admin users verify the live content on staging and can rebuild the static content.
3. Admin users can push the static content to the live server (with a different plugin, that would be aware of StaticBuilder).

Maybe that’s a long shot.

Another use case is for security, in case people set the 'plugin.staticbuilder.enabled' config to true in the global config.

From: https://forum.getkirby.com/t/staticbuilder-kirby-as-a-static-site-generator/4084/2

A question I often see raised is: how can I mix static and dynamic content? Because not every site can be 100% static.
Going full static brings lots of constraints, a lot of convenient Kirby features can no longer be used. Displaying 3 random items? Easy with Kirby, but once it's exported to static pages it won't be random anymore. Search engine, lists with filters, there are way to do them, but it's a lot of work.
I wonder if there is a smart way to statify only some pages, while keeping others handled by Kirby.

I'm using the Kirbytext syntax (image: infographic.jpg link: infographic.jpg) to have an image open itself when clicked, but the URLs aren't being generated correctly. I have staticbuilder.baseurl set to '/2016/'. The URLs come out to be http://example.com/2016/http://example.com/2016/infographic.jpg.

I had to manually find and replace these instances across my static files to resolve this. Overall, this plugin worked out well for me. Thanks for making it available.

I have staticbuilder.baseurl set to '/2016/'. I had to add a trailing slash to get my URLs to come out right, though your docs suggest I don't need it.

Probably better to normalize the $baseurl to end with a trailing slash, whether it's in the user config or not.

Hi,

I am currently facing the following issue.
The logic shown below works perfectly fine on the development site, but shows a very strange behavior in the static version.

What it should do: Generate a sibling link or if the current page is the last page in the sibling set, start from the first sibling.

What it actually does: Every page genereates a link which points to the very first page, this page points then correctly to the second one, but the second page points back to the first page.

// Get the next visible project
if($page->hasNextVisible()) {
  $nextUrl = $page->nextVisible()->url();
}
// Start from the beginning
else {
  if($siblings = $page->siblings(false)->visible()) {
    $nextUrl = $siblings->first()->url();
  }
}

Am i missing something or is this actually a bug?
Thanks for your help!

Current doc:
https://github.com/fvsch/kirby-staticbuilder/blob/master/doc/options.md#html-pages-outside-of-a-web-site

I’m not really happy with how poorly it explains how to prepare for a fully static site that may not be served with HTTP or hosted at the root of a domain.

Anyway, document the other option, which is:

// config.localhost.php
c::set([
    'plugin.staticbuilder.enabled'  => true,
    'plugin.staticbuilder.baseurl'  => '',
    'plugin.staticbuilder.uglyurls' => true
]);

// snippets/header.php
<head>
<?php
  $base = './';
  $max = $page->isHomePage() ? 0 : $page->depth();
  for($i=1; $i < $max; $i++) { $base .= '../'; }
  echo "<base url=\"$base\">";
?>

Not sure if/how we can do that, but it’s worth exploring. Currently we’re catching fatal errors, but not HTTP error codes.

A broken page should not prevent from building other pages.
But we probably need to report it in the info log.

The builder used to work great but now it outputs the startpage content to all pages, except error.html which is as expected.

I tried updating to the latest version but still no luck.

I have a super simple site and i run with default options

My current idea is: there is an array of relative file or folder paths (from $kirby->roots()->index()), and we copy each one to the static folder. We provide a default config (mostly copy the full assets folder if it exists, perhaps the thumbs folder too?), but users can provide their own config as the 'plugin.staticbuilder.copy' config.

c::set('plugin.staticbuilder.copy', [
  // copy 'thumbs' to 'static/thumbs'
  'thumbs',
  // copy 'site/plugins/something/css/something.css'
  // to 'static/assets/css/something.css'
  'site/plugins/something/css/something.css' => 'assets/css/something.css'
]);

Priority is having a 1.0 / 1.x that works well for generating a static site when visiting a particular route. But an alternative command-line tool could be nice.

• Maybe with the option to enable the CLI or enable the HTTP action separately?
• Should it use a custom script, e.g. php site/plugins/staticbuilder/cli.php [params]?
• Or maybe extend the Kirby CLI if that becomes possible at some point?

Simpler option to avoid stale content when building is flushing and rebuilding.

This is alright IMO with Kirby because you should be running your site with PHP (and possibly Apache) when creating content and templates, and only generate the static export once you’re done. Worse case scenario is when debugging a problem in the export (e.g. your live version is alright but the static export is not), where you might need to export several times in a short time.

IMPORTANT: avoid erasing other files!

There was a previous effort by @noclat here: https://forum.getkirby.com/t/static-kirby-website-generator/21411 but the repo is gone, perhaps because it had nuked some pour soul’s system.

I’ll try to find a way to prevent that, e.g. enforcing that the output folder (which will be emptied when rebuilding the full site, I don’t intend to do incremental stuff and diffing) has a specific, unchangeable name (like static: you can configure the path to put it anywhere, but the folder itself must me named static).

In a feed.php controller:

header::type('application/atom+xml');

Response when building the full list of pages which does contain several feed.txt pages is HTTP 404 with Content-Type: application/atom+xml; charset=UTF-8 and no body.

Bug report: https://forum.getkirby.com/t/staticbuilder-kirby-as-a-static-site-generator/4084/26

So basically how the l::set and l::get system works in Kirby:

1. L::$data is an empty array.
2. On page load for multilang websites, Kirby identifies the current language from the URL (e.g. /fr/foo/bar) and loads the corresponding PHP file in site/languages/fr.php.
3. In this file, using the L class instead of the C class (c::set) is just convention. There's nothing special about it. It's a static class with an array and the get/set methods.

When rendering from /staticbuilder/, Kirby does not set the current language and does not load this language-specific config file. We then go to great lengths to set the page's language when rendering each version, but don't load those files either. Not sure what would be a decent solution. :/

Possible workaround, in e.g. site/snippets/header.php:

<?php
// make sure to load the translations for each page
$langfile = $kirby->roots()->languages() . '/' . $site->language()->code() . '.php';
if (file_exists($langfile)) {
  include $langfile;
}

My website utilizes subpages for each top-level page. Whenever I build my site, all my top-level pages take the URL http://localhost/section.html, while my subpages take the URL http://localhost/section/subpage.html. I want the section index pages to take the form http://localhost/section/index.html. Since this would appear to be a common issue and I don't see any documentation of it, I'm afraid I might be missing something. For now I am manually moving the generated pages to the proper folder and renaming them index.html. Any help is appreciated. Thanks.

Since I am not currently using this plugin for websites I’m actively working on, and don’t plan to do it in the foreseeable future, I now consider it to be in maintenance mode.

I’m going to close all feature requests, not because they’re bad ideas but because I don’t plan to work on them (or review, test and merge pull requests, and release new versions with new features).

I will try to work on blocking bugs and keep this plugin working for Kirby 2. I do not intend to port it to Kirby 3.

[Epic]

Challenges

• When a page links to another page, will that link work with what we output?
• When a page references an asset, does that reference work with what we output?
• When a page references a page file (e.g. from Kirbytext), does that reference work with what we output?
• Can a static build be deployed at the root of any domain or subdomain?
• Can a static build be deployed as a subfolder (at any level)?
• Can a static build be distributed without a HTTP server (e.g. documentation pages, open in browser with file:// protocol)?

Current situation

1. Domain name in URLs depends on Kirby config. By default it will output the domain name of the request. We probably want to force $kirby->urls()->index = ''; (limited but decent default), and optionally let users set the root URL to whatever they want.
2. Right now we're building pages with a suffix added to their URI, e.g. my/page/index.html or my/page.html. Depending on server config this might break URLs between pages. We should pick a default that works in most cases. I originally picked a /index.html suffix because my personnal site and main test project uses hardcoded relative references to files, e.g. <img src="illustration.jpg">. This might be an outlier case, and maybe .html is a better default suffix.
3. We copy over the assets and thumbs folder. This should be alright (and can be overridden if needed).
4. We copy over the content folder, so that file references from kirbytags or using $page->image('some-image.jpg')->url() keep working. That means we copy folders and source content for all pages, including some that might be marked as private or that was filtered by default or user-configured filter. Not awful but not great.

Possible improvements

For the content folder: perhaps parsing the generated HTML for every page, identifying references to files in content/…, replacing with a different URL, and adding old and new URL to a map of assets to copy. Or is that overkill? Note that if we’re already copying over the page’s files, so we could rewrite only those known URLs.

If we want to go with some rewriting of the HTML output, we could forcefully set something like $kirby->urls()->index = 'STATIC_URLS_INDEX' then rewrite all the STATIC_URLS_INDEX/… as needed. This would allow us to rewrite URLs generated by Kirby (for known pages, assets, thumbs etc.) and not other paths or path-like strings in the output, avoiding a lot of opportunities for false positives.

We could also add a generic rewriting config. If we do that, I favor using a callback: get a string (rendered page), do whatever you need, return a string. BUT the important part is that the default config and features of this plugin should make writing such a callback unnecessary for most users.

Fully relative paths

Last possible improvement answers the "distribute without a HTTP server" case. This means making all file references relative:

<!-- Example: current page is static/category2/sub-section/page-slug.html -->

<link rel="stylesheet" href="../../assets/css/styles.css">

<!-- Nav -->
<a href="../../index.html"> Home </a>
<a href="../../category1.html"> Category 1 </a>
<a href="../../category2.html"> Category 2 </a>

<!-- Breadcrumbs -->
<a href="../../index.html"> Home </a>
<a href="../../category2.html"> Category 2 </a
<a href="../sub-section.html"> Sub-section </a>

<img src="page-slug/cover.jpg" alt="Image for this page">

I think it’s doable but this one clearly requires rewriting most URLs and file references.

This probably should be an option. Maybe using a single config key?

• c::set('plugin.staticbuilder.urlbase', '/foo'); to set URLs starting with /foo/ (e.g. /foo/index.html for home, /foo/assets, etc.)
• c::set('plugin.staticbuilder.urlbase', 'https://somedomain.tld'); to set URLs starting with https://somedomain.tld/
• c::set('plugin.staticbuilder.urlbase', false); to use relative URLs instead.

On a test site with many pages using the same template and controller, it seems that the controller is only ran once, or its result is cached somehow.

For instance if posts.php returns ['content' => 'Page 1'] on “Page 1”, it will keep returning that (or that’s the value use by the template anyway) on “Page 2”, “Page 3” etc.

In my tests I have an archive page controller used on different "category" pages, and in the static build every category lists content from the first category.

Similarly to how the 'plugin.staticbuilder.assets' config allows listing files and folders to copy, we might have a 'plugin.staticbuilder.routes' array for routes that should be rendered.

Example implementation by @mogelbrod:
mogelbrod@bfe8605

Maybe worth mentioning in the docs?

That if you only use images via thumb/resize and that you pre-generate them with the Kirby ImageKit Plugin, you probably do not need to include the content folder in your static website output?

Got this problem on a 2.5.x install with StaticBuilder loaded with Composer:

<?php // config.php
c::set('staticbuilder', true);
// Enable routes for the StaticBuilder plugin
Kirby\StaticBuilder\Controller::register();

The register method checks kirby()->get('option', 'staticbuilder') which will not exist at this point, at least on 2.5. I think it used to work? Or maybe it never did and the doc needs to be fixed.

Workaround:

<?php // site/config/config.php
c::set('staticbuilder', true);

+

<?php // site/plugins/register.php
// Enable routes for the StaticBuilder plugin
Kirby\StaticBuilder\Controller::register();

Not sure if my config is wrong, but the assets folder is not copied to /static/assets/

I am using Kirby 2.4. Here is my config:

<?php
c::set([
	'staticbuilder'  => true,
]);

What am I doing wrong?

I have also tried a config like the following without success:

<?php
c::set([
	'staticbuilder'  => true,
	'staticbuilder.extension'  => '/index.html',
	'staticbuilder.withfiles'  => true,
	'staticbuilder.assets' => [
		'assets'
	]
]);

First of all THANKS for this great plugin!

Are there any know issues with prev/next navigations? I'm using the following code in my template …

<?php if ($page->hasPrevVisible()): ?>
    <a href="<?= $page->prevVisible()->url() ?>">Prev</a>
<?php endif; ?>

<?php if ($page->hasNextVisible()): ?>
    <a href="<?= $page->nextVisible()->url() ?>">Next</a>
<?php endif; ?>

… but it is ignored by the static build. I also tested $page->hasPrev() but this does not work either?! The prev/next navigation works great when the page is rendered dynamically.

I had a look at the issues here on Github, at the documentation and at this forum thread, but unfortunately without luck. Do you have any ideas? Or is there anything I've missed?

I'm using Kirby 2.5.10 and Static Builder 2.2.0.

Thanks in advance.

The url to the documentation for how to enable the plugin is broken: https://github.com/fvsch/kirby-staticbuilder/blob/master/doc/config.md

Is it possible to have some markup only executed on in the static build? In my case I need host the kirby version for admin purpose as well as the static version for production. I would like to have a tracking code only on the static enviroment. Is this somehow doable? I did see this mentioned on the best practises page but for me it seems that the constant 'STATIC_BUILD' does not exist.
Thanks.

Default value:

// Template prefix for module subpages (default results in "module.text")
c::set('modules.template.prefix', 'module.');

How about a little Dashboard widget which shows some meta-information and give the panel-user a link to the staticbuilder-page?

Need it asap for a project. 😁

Always nice to minimize code duplication :)
See mogelbrod/kirby-staticbuilder@f026234 for the required changes.

1. Copying assets copies over the thumbs folder (defaults)
2. Building pages generates images in the thumbs folder.

Result: static build is missing images.
Solution: change the order to build pages first, copy assets after.

Documentation:

• Update readme with basic info, install instructions
• Remove mentions of "experimental" or "early work"
• Document known issues in readme

Probably need two other doc pages:

• one for config (defaults, examples)
• some recommendations for compatible code (not everything you can do in Kirby or PHP will carry over nicely to a static build!)

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?