twill: All local asset urls broken

@23d1 Definitely! We are actually working on a sandbox environment that we are hoping to share as soon as possible. Same for docs, we can definitely see how they are really targeted at pure Laravel developers right now, but we are eager to improve them in order for Twill to become more accessible to any developer!

@hineios yup, we are working on the docs updates. Just cleaning things up a bit and I’m going to open source them next week so it’ll be easier to improve them as a community.

For the duplicate public problem, we found out that the cp command specified in our npm scripts is not environment agnostic. You can replace the following in your project’s package.json:

"cms-build": "npm run cms-copy-blocks && cd vendor/area17/twill && npm ci && npm run prod && cp -R public/ ${INIT_CWD}/public"

by:

"cms-build": "npm run cms-copy-blocks && cd vendor/area17/twill && npm ci && npm run prod && cp -R public/* ${INIT_CWD}/public",

Notice the subtle difference, you need to add a * behind the first public:

cp -R public/ ${INIT_CWD}/public vs cp -R public/* ${INIT_CWD}/public

It also applies to the cms-dev scripts.

@noxify That one is actually #12 😦. The setup command is failing right now if you run it multiple times because migrations get published again, we’re working on improvements there! I’m so sorry you’re being stopped but all those, stay tuned.

@noxify thanks, really helpful!

You should only make sure to have NPM > 5.7.8 locally to test the npm run cms-build command on your host, no need to run the app locally.

What do you mean by assets? The uncompiled Vue.js components in Twill’s frontend folder?

I don’t think we want to publish those into host apps as this would mean that developers would have to re-publish after each Twill update before recompiling (because your own custom blocks actually end up compiled into the admin build). Also we think that extendability and flexibility is provided as the PHP level. If all the frontend components are published into host apps, developers will tend to modify them, which will make future updates more difficult to them. We’re currently looking into ways for developers to extend our Vue components though!

So the idea right now is that everything is happening from the vendor folder and the compiled assets are being copied over to your app public folder. You can choose to put those in version control or not. If not, you should have your deploy script run the NPM build command (our recommendation to avoid large repositories as the build is quite large and changes quite often).

Hope that makes sense! Eager to hear what you think about it.

@ifox Great, thanks. I think some references to these various setups would be great for us new to Laravel in general to have in the docs. Perhaps a “tutorials” or “examples” section where a very basic backend is built, and then how these hook into the templates for rendering. Unless the idea is to cater more to pure Laravel developers, in which case I totally get it. Anyway, an example setup of a basic CMS and templates would be great… At least for us reverse-engineer learners out here. 😉

Hi everyone! First, thanks for trying out Twill 👍

To clear up any misconceptions, Twill is not a theme based CMS like Wordpress for example. This is a package for Laravel developers to rapidly create a custom admin console.

It doesn’t make any frontend assumptions and as such doesn’t setup anything particular for the frontend part of the application you are building. It’s on you to set this up like you would in any other Laravel application.

That’s why going to twill.test is still showing the Laravel welcome screen. A Twill application is a Laravel application and you are free to set it up as a headed Laravel app (server rendered Blade templates through the Laravel router) or as headless by defining API routes on top of your Laravel models.

This is where Twill comes in. It can help you setting up your models and create an admin console on top of those (by helping you with database migrations, controllers, views, configuration and so on). Flexibility comes with responsibility though. You have to setup the CMS navigation yourself, you have to specify where logged in users should be redirected (unless you enable the dashboard screen which is setup at the root url by default), and so on.

There are no default models provided, no posts, no pages, only technical models that are used internally by Twill features and that you are going to relate to your own models using Twill’s provided traits. For example, if you need to attach files to a model you created, the HasFiles trait is going to add the relationship to Twill’s File model and automatically manage your model updates from the CMS UI.

Our documentation can definitely be improved to better convey those concepts and we are excited to read everyone’s feedback here in order to do so.

This issue is probably happening because you have the hot file in your public folder (located here public/hot). Can you please see if it is there and remove it ?

This file is created when running npm run cms-dev to enable hot reloading. We need to make sure this file is removed when running the cms-prod command. And also we must add a hook to destroy this file when exiting the cms-dev script.