All local asset urls broken

[sebszocinski]

Trying to demo this on Valet and i've defined my APP_URL as well as the ADMIN_APP_URL and I finally managed to log in but none of the styles/js assets are loading because they are referencing localhost:8080 and not twill.test like i've defined...

Looks like a promising product but the docs and setup process could be well improved.

[mrdoinel]

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.

[sebszocinski]

I've checked and there is no hot folder in public

[sebszocinski]

is going to https://manage.twill.test (assuming you set it up at that url) meant to load a login page?

This as well as twill.test is just showing me a Laravel welcome screen:

It'd be nice for there to be a demo front-end with some demo dummy data for testing.

[renanBritz]

I setup twill in my homestead box last night and had similar problems...

• twill.local displayed a laravel welcome screen
• admin.twill.local also displayed a laravel welcome screen
• admin.twill.local/login Displayed the following error: Could not find mix-manifest.json

I followed all installation and configuration instructions in the website. Updated my npm version to 6.1.0 before running npm run cms-build. There were no build errors.

Oh, btw... looking forward to test twill. Looks like a very promising product / platform. Good job!

[23d1]

Hmm. Having similar issues. All *.twill.test leads to the Laravel welcome screen. Any twill.test/* leads to massive set of errors in multiple frames, which I assume is just 404 not being configured(?)...

Did these steps;

1. Install laravel app (create folder and laravel base install)
2. Configured the .env with correct database info and so forth.
3. Installed twill with composer and npm and all that stuff.
4. Nothing changed besides having a debug bar at the bottom of the welcome page.

Edit;
Going to admin.twill.test/users got me to the login prompt and then the users panel... Strange that admin.twill.test goes nowhere... Right?...

[ifox]

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.

[23d1]

Excellent. So things like the file manager not working is to be expected? Would be great to have an example setup to play around with, just super basic where content blocks and so forth is already set up, together with navigation in the admin and so forth. Much easier than digging into Laravel from scratch. A reference build, if you will. I don't know if the A17 FE Boilerplate is something like this, as it's impossible to register/log in from that link referenced at the end of the docs.

[renanBritz]

Hey there @ifox

That's great news! From what I could understand, Twill can provide a solid backend foundation for any project.

I have a question which I couldn't figure out from the docs and unfortunately didn't have the time to test yet:

• What is "CRUD Modules"? Is it some sort of modular architecture, similar to what is provided by nWidart/laravel-modules or caffeinated/modules?
• Does Twill offer multi-tenancy support?

Best Regards!

[ifox]

Now back to the actual technical issues you guys encountered!

@sebszocinski Twill is using Laravel Mix behind the scene to compile the CMS assets.

Laravel Mix is a wrapper around Webpack, which offers hot module reloading. When you are a contributor of Twill or are working on custom blocks for your CMS, you might want to have this feature enabled so that any change you make to your code is almost immediately available to your browser. This is different from something like Browersync in the sense that it does not simply trigger a page reload, but rather inject your JS/CSS updates directly into the page.

To make this work, Laravel Mix is spawning a Webpack development server on localhost:8080 and creates a hot file in your public folder. Then, an helper is provided by Laravel, mix(). If the hot file is present, it will use localhost:8080 to retrieve assets from Webpack. If not, it will use the regular relative path you're used to.

So the only way your Twill installation would try to load assets from localhost would be that you ran npm run cms-dev at some point and the command failed or wasn't killed properly, which could have left the hot file in your public folder. Can you confirm you don't have a hot file sitting in your public folder?

[ifox]

@23d1 the file manager should work if you provide the application with AWS S3 credentials in your .env and have an S3 bucket correctly setup to authorize uploads from your domain as documented here. If you do not want to use S3, you can also set it up to store uploads locally by using the following .env variables:

MEDIA_LIBRARY_ENDPOINT_TYPE=local
MEDIA_LIBRARY_LOCAL_PATH=uploads/

[23d1]

@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. ;)

[ifox]

@renanBritz Exactly, it is really about providing a foundation to any project that needs a dedicated admin console. Most people tend to manually put those together using Bootstrap templates and end up dealing with tons of HTML markup and repeated backend code, which become very difficult to maintain in the long run.

CRUD modules are actually enhanced Laravel resources. The default CRUD operations are not enough to support all the other features Twill offers on top of regular Laravel models: things like featuring, reordering, publishing and so on. Twill comes with an Artisan command to generate those modules. This is definitely different than the packages you mention which are more using the term module from a file architecture standpoint.

As for multi-tenancy, definitely. You can serve multiple websites from a single Twill instance, using Laravel's subdomain routing. Correct me if that's not what you meant by multi-tenancy here!

[ifox]

@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!

[renanBritz]

Hi @ifox

I'm a bit confused. There are many predefined routes and they're naming suggest that there are some basic pages set up.

• I tried accessing admin.twill.local/login and got the following error: "The Mix manifest does not exist."
• Tried accessing admin.twill.local/templates and got the following error: "View [templates.index] not found."

Followed all install instructions. Also tried the vendor:publish command but nothing changed.

I don't know where to get started.

Regards!

[ifox]

Hi @renanBritz!

There are definitely some CMS pages set up depending on the enabled features. By default, the login, password reset and user management section as well as the media library should be available to you after installing. However, there are no CMS "homepage" until you enable the dashboard (for which more documentation is coming asap) or set up a redirect from "/" to a section you added yourself in the admin.php routes file.

In your case, the login screen is failing because of an issue with the CMS assets build. Twill uses Laravel Mix behind the scene to build. DId the npm run cms-build command ran correctly for you? Do you see a public directory created in vendor/area17/twill? This is where the build is happening before being copied to your app public's folder. This should contain a mix-manifest.json file.

As for the templates url, this is a simple automated routing of Blade templates that we use internally for FE developers to start working on non integrated templates until a backend developer actually integrate with Laravel models. Any Blade file added to resources/views/templates is going to be rendered automatically at admin.twill.local/templates/your-blade-file-name. You can also have those available at twill.local/templates/your-blade-file-name by setting the templates_on_frontend_domain config variable to true in your twill.php configuration file. This should not be seen as the actual templating system for Twill but more simply at a quick way to render Blade views during development. Twill is completely agnostic to your actual frontend.

Hope that helps!

[noxify]

I got the same error message ( manifest not found... ), based on this issue, i started some researching...

The "problem" is, that the command:

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

copies the files into <webroot>/public/public instead of <webroot>/public.

Changing it to the following solves the problem:

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

[ifox]

Hi @noxify, interesting! Which OS are you running the NPM script on? I'm thinking it could be a different cp behavior, in that case we might want to look into an OS agnostic way of copying those files at the end of the build. On Mac OS and Ubuntu 16.04 the original scripts works fine.

[noxify]

Hi @ifox,

my host system is OSX but i have tested it via homestead.

Homestead: 7.3.0
Vagrant: 2.1.2
VirtualBox: 5.2.12
Laravel. 5.6
PHP: 7.2
MYSQL: 5.7

Maybe I should update my homestead?! 🤔

[ifox]

Ha! I don't think updating Homestead would help as it's a pretty recent one that you have there already.

I will run some more tests as this should really be working everywhere, it's just about copying the content of vendor/area17/twill/public into your own app's public folder.

If you don't mind, can you try from your OSX host?

[noxify]

@ifox sure - i have to check my local env (php version etc.)

Btw. here my STRs from my latest test: https://gist.github.com/noxify/66f9b915bcca0ea62f8edb097eb81e3f

Maybe it helps to reproduce it.

I was also able to reproduce #14

[noxify]

Another question:
What is the reason to keep the assets in the vendor package and not as copy in the resources or in the public directory?

[ifox]

@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.

[noxify]

@ifox - thanks for this explaination. Yes it makes sense ;)

Btw. I tried it on my local maschine with PHP 7.1.2, here I ended with the following error (should be the same as #12 ).

As database, i used my vagrant maschine (changed the mysql port (now: 33060) + database name (now: twill_local) in my .env)

➜  twill_local php artisan twill:setup
Copied File [/vendor/area17/twill/migrations/create_tags_tables.php] To [/database/migrations/2018_07_16_215010_create_tags_tables.php]
Copied File [/vendor/area17/twill/migrations/create_blocks_table.php] To [/database/migrations/2018_07_16_215010_create_blocks_table.php]
Copied File [/vendor/area17/twill/migrations/create_users_tables.php] To [/database/migrations/2018_07_16_215010_create_users_tables.php]
Copied File [/vendor/area17/twill/migrations/create_files_tables.php] To [/database/migrations/2018_07_16_215010_create_files_tables.php]
Copied File [/vendor/area17/twill/migrations/create_medias_tables.php] To [/database/migrations/2018_07_16_215010_create_medias_tables.php]
Publishing complete.
Copied File [/vendor/spatie/laravel-activitylog/migrations/create_activity_log_table.php.stub] To [/database/migrations/2018_07_16_215010_create_activity_log_table.php]
Publishing complete.
Migration table created successfully.

   Symfony\Component\Debug\Exception\FatalErrorException  : Cannot declare class CreateActivityLogTable, because the name is already in use

  at /www/sites/twill_local/database/migrations/2018_07_16_214908_create_activity_log_table.php:35
    31|     public function down()
    32|     {
    33|         Schema::drop(config('activitylog.table_name'));
    34|     }
  > 35| }
    36| 


   Whoops\Exception\ErrorException  : Cannot declare class CreateActivityLogTable, because the name is already in use

  at /www/sites/twill_local/database/migrations/2018_07_16_214908_create_activity_log_table.php:35
    31|     public function down()
    32|     {
    33|         Schema::drop(config('activitylog.table_name'));
    34|     }
  > 35| }
    36| 

---

The npm version on my vagrant maschine is 5.7.1. I will upgrade it and check it again.

[ifox]

@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]

@ifox - I have updated npm to 6.2.0 in my vagrant box and also on my host.

Test with vagrant:

• After running npm run cms-build the result was the same
  • new public folder inside <webroot>/public.

Test with OSX:

• After running npm run cms-build the result was different
  • there is no new public directory inside <webroot>/public.
  • everything is as expected (<webroot>/public/assets/ and <webroot>/public/mix-manifest.json are available )

---

I tested the cp command directly, with the following, it works inside vagrant and osx.

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

Hope that helps :)

---

EDIT: that the error occours is ok for me - It was just a test (for me).
I solved this kind of problem in the past with a date/time prefix instead of a dynamic filename in the migration.

[hineios]

@ifox I believe it should be stated in the requirements the minimum version of npm needed for usage with Twill.
I was using v5.6.0 and always got an error.
Updated to v6.3.0 and was able to run the command.

However, I'm experiencing the duplicate public problem described here.
The built files are being copied into {app}\public\public\ instead of the necessary {app}\public\.

I know you are looking into this, and I'll keep manually copying the files over if necessary, but do you have a quickfix I can apply for the time being?

Oh, I'm running Laradock v7.0 on Docker over Hyper-V in Windows.

[ifox]

@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.

[ifox]

Hi everyone,

Thank you so much for your feedback here. Twill 1.2 is now released with tons of updates to our documentation as well as to the installation process to make it easier for everyone to troubleshoot.

[karneaud]

+1

Running into a similar problem with both the failing migration scripts to the missing assets due to the hot. I removed the hot files from all public directory but still encountering the issue. Can I resort back to the regular mix npm run dev .....I use yarn by the way so idk if that helps anything?