menu
announcement

Spectrum is now read-only. Learn more about the decision in our official announcement.

Twill

Rapidly create a custom admin console that content publishers will love. Twill is an open source CMS toolkit for Laravel, crafted by AREA 17.

Channels
Team

Twill 1.2.2 is available!

August 21, 2019 at 3:47pm

Twill 1.2.2 is available!

August 21, 2019 at 3:47pm (Edited 3 years ago)
Twill just surpassed 10k installs and today, version 1.2.2 is available with a significant amount of improvements and bug fixes thanks to the efforts of 21 contributors: Amr Noman, Antoine Doury, Antonin Caudron, Antonio Carlos Ribeiro, Bram Mittendorff, Daniel Ramos, Dmitrii Larionov, Fernando Petrelli, Franca Winter, Gilbert Moufflet, Jarred Bishop, Lorren Gordon, Nikhil Trivedi, Pablo Barrios, Quentin Renard, Rafael Milewski, Ray Tri, Riaan Laubscher, Stevan Pavlović, Yanhao Li, Žiga Pavlin.
Glide support for local image rendering
Glide is an open source image rendering service that integrates well with Twill and Laravel. It is a self-hosted option for local development and/or production websites and apps that have limited needs for image resizing and cropping. For image-heavy production websites and apps, we still recommend Imgix or a similar third party service, or at least setting up a CDN on top of your images.
The media and file libraries local endpoint type has also been completely reworked to work with Laravel default public storage location. Remember to run php artisan storage:link locally and as part of your deployment process if you are using local uploads rather than S3.
To try out Glide on a fresh Twill app, it is as simple as updating 2 environment variables:
MEDIA_LIBRARY_ENDPOINT_TYPE=local
MEDIA_LIBRARY_IMAGE_SERVICE=A17\Twill\Services\MediaLibrary\Glide
Of course, more configuration variables are available through the new glide key of Twill's configuration. See the default configuration here.
Making repeaters happy again
Repeaters had a couple of issues that are now fixed in this release:
  • repeaters in forms are now updating the initially created database record instead of needlessly creating a new record each time their parent model gets updated
  • repeaters in blocks are now restored correctly when restoring a past revision
  • medias and files fields support has been improved
Different images per language support
You can now globally enable the ability for your content editors to provide different images per language in the media form field using the media_library.translated_form_fields configuration key (defaults to false). The user experience is exactly the same as our other translatable field. When rendering in a template or API, you can fallback to the default language if no image has been selected for the current language.
Cleaning up internals
Lead by community member Stevan Pavlović, an effort to clean Twill internals begins with this release. Laravel helpers and facades are getting replaced by dependency injection or at least, for now, to avoid consequent breaking changes, by fully qualified imports.
HOW TO UPDATE
To update, you will need to run composer update in your project and then run the new Twill provided artisan command: twill:update. This will generates new database migrations and invite you to migrate your database. Those new migrations are safe to run as they check for the existence (or inexistence) of tables and columns in your database before doing anything. If you are upgrading from an earlier version than 1.2, you will need to update your composer.json file first: "area17/twill": "1.2.*".
NOTE ABOUT UPCOMING LARAVEL 6 AND SEMANTIC VERSIONING
Laravel 6 upcoming release was announced a few weeks ago at Laracon US! Twill will of course support it soon after the official release, which should happen at the end of August at Laracon EU 🤞.
Taylor Otwell also explained why v6 instead of v5.9 since the next release is not a paradigm shift for the framework: Laravel is adopting semantic versioning (major.minor.patch) and for simplicity, we will make that shift as well.
Right now, Laravel and Twill are following romantic versioning (paradigm.major.minor). This is why Twill 1.2.2 is not just about patches but new features and improvements too.
Moving forward, once Laravel 6 is released, a release with breaking changes will be considered major, which would mean Twill 2.0.0 right now. A release with new features would be 1.3.0, and patches would be 1.2.3.
You can start using Composer's caret version range (^1.2.2) now if you'd like to benefit from new features without fearing breaking changes on your next composer update! If you'd rather stick to a stricter way of requiring Twill versions (fair enough, we do that in Twill's npm dependencies for your own safety), you will have to update your composer.json file to get new features rather than patches only.

August 21, 2019 at 6:17pm
Updated a site I've been building and noticed few issues right away. biggest problem is when using ($block->children as $child) in a repeater block frontend file if you have 2 types of repeaters in the same page, foreach returns an item in the first array when you add a new item to the second array. for example I had slider repeater field and list repeater. When only added a slide it works. but When I add list repeater after slider and create list item it is added a item to slider array. (But not showing correctly since its not returning correct fields. so shows a blank slider spot.) Sorry about my English. Hope that makes sense. Has the way we render blocks in frontend file changed? We can no longer use ($block->children as $child) in repeater block parent files?
Hi I don't think that something changed around that. Can you provide a way to reproduce? Thank you
here is the gist from the files of my 2 blocks https://gist.github.com/pramithagayan/0e7fb13e544a6b30487274d874222043. its just 2 simple block repeaters. then you need to create slider and solutions block in same page. When you add 1 slider item and 2 solution items slider returns 3 array items. Note:- All this is working fine before the update.
Edited

August 22, 2019 at 6:12pm
sorry for the trouble. were you able to reproduce this error? ive done some trouble shooting and it seems like when you have two repeaters in the same block editor first one returns the full repeater object array not just the related item.

August 23, 2019 at 7:01pm
howdy . Got an issue with 1.2.2, hopefully there is an easy fix. Ran artisan twill:build on an existing project that contains multiple languages. It didn't create any new migrations. When attaching an image now to an article, it fails to validate. The laravel logs show this:
[2019-08-23 18:56:49] local.ERROR: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'locale' in 'field list' (SQL: insert into `mediables` (`created_at`, `crop`, `crop_h`, `crop_w`, `crop_x`, `crop_y`, `locale`, `media_id`, `mediable_id`, `mediable_type`, `metadatas`, `r atio`, `role`, `updated_at`) values (2019-08-23 18:56:49, default, 650, 1440, 0, 0, en, 23, 19, articles, {"caption":null,"altText":null,"video":null}, landscape, hero\_image, 2019-08-23 18:56:49)) {"userId":1,"exception":"[object] (Illuminate\Database\QueryException(code: 42
S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'locale' in 'field list' (SQL: insert into `mediables` (`created_at`, `crop`, `crop_h`, `crop_w`, `crop_x`, `crop_y`, `locale`, `media_id`, `mediable_id`, `mediable_type`, `metadatas`, `ratio`, `role`, `updated_at`)
values (2019-08-23 18:56:49, default, 650, 1440, 0, 0, en, 23, 19, articles, {\"caption\":null,\"altText\":null,\"video\":null}, landscape, hero\_image, 2019-08-23 18:56:49)) at /var/www/admin/vendor/laravel/framework/src/Illuminate/Database/Connection.php:664, Doctrine\DBAL\
Driver\PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'locale' in 'field list' at /var/www/admin/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:63, PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown c
olumn 'locale' in 'field list' at /var/www/admin/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:61)
I'm going to take a guess that the migration didn't get generated to add a locale field to mediables.
Edited
Hi you'd have to run php artisan twill:update to get a bunch of new migrations!
yep, I did. It didn't generate them.
looking through the source, looks like I just need to create a manual migration using the AddLocaleColumnToTwillMediables, ChangeLocaleColumnInTwillFileables migrations. Hopefully this will help others where twill:build failed to create them.
Oh, sorry about that, that's no good. I see that twill:update is not generating them as it should. But yes, exactly, in the meantime, you can create those migrations in your project.
like-fill
1

August 24, 2019 at 8:41am
update that

August 29, 2019 at 1:09pm
Hi! I had my own implementation of ImageService, but seems it is not working after the update. I double-checked the config files as well as source, but my service class is not being called.
~ UPDATE ~ Seems that before 1.2.2 the method called on the service, was getUrl. Now it calls `getCroppedUrl.
Just in case someone happens to be in same pitfall.
Edited

August 30, 2019 at 10:08am
Updated. Read here about the migrations and is ok. But problem is image uploading with glide. The final url in the media has 2 https and anyway it doesn't show up the image. Already done storage:link from inside the vagrant, added Glide in the .env file. This is my twill config
EDIT: solved double urls, was simply because of scheme in APP_URL that should be removed
But anyway, image goes 404
'media_library' => [
'disk' => 'uploads',
'endpoint_type' => env('MEDIA_LIBRARY_ENDPOINT_TYPE', 'local'),
'local_path' => env('MEDIA_LIBRARY_LOCAL_PATH', 'uploads/images/'),
'image_service' => env('MEDIA_LIBRARY_IMAGE_SERVICE', 'A17\Twill\Services\MediaLibrary\Local'),
'cascade_delete' => env('MEDIA_LIBRARY_CASCADE_DELETE', true),
'filesize_limit' => env('MEDIA_LIBRARY_FILESIZE_LIMIT', 50),
'allowed_extensions' => ['svg', 'jpg', 'gif', 'png', 'jpeg'],
'translated_form_fields' => true
],
'file_library' => [
'disk' => 'uploads',
'endpoint_type' => env('FILE_LIBRARY_ENDPOINT_TYPE', 'local'),
'cascade_delete' => env('FILE_LIBRARY_CASCADE_DELETE', true),
'local_path' => env('FILE_LIBRARY_LOCAL_PATH', 'uploads/files/'),
'file_service' => env('FILE_LIBRARY_FILE_SERVICE', 'A17\Twill\Services\FileLibrary\Disk'),
'filesize_limit' => env('FILE_LIBRARY_FILESIZE_LIMIT', 50),
'allowed_extensions' => ['pdf', 'doc', 'docx', 'xls', 'xlsx', 'ppt', 'pptx'],
],
.env
MEDIA_LIBRARY_ENDPOINT_TYPE=local
MEDIA_LIBRARY_IMAGE_SERVICE=A17\Twill\Services\MediaLibrary\Glide
It throws a FileNotFoundException from the Glide Filesystem class,
Also, this is the symlink of storage:link command storage -> /home/vagrant/penta/storage/app/public Isn't that strange? Shouldn't be simply that the public/uploads points to storage/uploads ?
Edited
Ok, my fault because I didn't remember that "uploads" is not one of the supported disk.
A full working config for Glide with default values should have the "disk" value as the Laravel's default public, then the LIBRARY_LOCAL_PATH as follows:
'media_library' => [
'disk' => 'public',
'endpoint_type' => env('MEDIA_LIBRARY_ENDPOINT_TYPE', 'local'),
'local_path' => env('MEDIA_LIBRARY_LOCAL_PATH', '/'),
'image_service' => env('MEDIA_LIBRARY_IMAGE_SERVICE', 'A17\Twill\Services\MediaLibrary\Local'),
'cascade_delete' => env('MEDIA_LIBRARY_CASCADE_DELETE', true),
'filesize_limit' => env('MEDIA_LIBRARY_FILESIZE_LIMIT', 50),
'allowed_extensions' => ['svg', 'jpg', 'gif', 'png', 'jpeg'],
'translated_form_fields' => true
],
'file_library' => [
'disk' => 'public',
'endpoint_type' => env('FILE_LIBRARY_ENDPOINT_TYPE', 'local'),
'cascade_delete' => env('FILE_LIBRARY_CASCADE_DELETE', true),
'local_path' => env('FILE_LIBRARY_LOCAL_PATH', '/'),
'file_service' => env('FILE_LIBRARY_FILE_SERVICE', 'A17\Twill\Services\FileLibrary\Disk'),
'filesize_limit' => env('FILE_LIBRARY_FILESIZE_LIMIT', 50),
'allowed_extensions' => ['pdf', 'doc', 'docx', 'xls', 'xlsx', 'ppt', 'pptx'],
'translated_form_fields' => true
],

September 1, 2019 at 7:34pm
In localhost upload not work fine

September 10, 2019 at 11:23am
any idea when will Twill support for Laravel 6.0 be released?
Edited
like-fill
3

September 16, 2019 at 2:00pm
I am planning on moving all my sites into the new Vapor. Just waiting for Twill to support Laravel 6.

September 24, 2019 at 1:49pm
, same as and , I plan on upgrading to Laravel 6 (to use Vapor). Any idea on when Twill might be compatible? Thanks!

September 26, 2019 at 12:15am
Hi all! We're actively working on it and planning on releasing in the next 2 weeks. You can review our progress on the following PR: https://github.com/area17/twill/pull/389.
like-fill
3

October 24, 2019 at 10:37am
Excellent! I'm about to start a new project and need a CMS addon. I decided to give Twill another whirl. Will this still be long?

October 25, 2019 at 4:26pm
Hi ! Laravel 6 support has landed in master last week and will be officially released as part of 2.0 next week!
like-fill
4
Great! Thanks for the update.

October 29, 2019 at 11:54am
I think you forgot to update the version file in the package and in the admin area. When i run composer show it says 1.2.2 but there it says 1.2.1.

October 31, 2019 at 9:39am
Hi sorry but, is there any hope to get this feature on version 2.0?
Edited
Awesome. It's all working for myself now, however, I did have a couple of snags. I figured out the solutions and they're as follows.
Image paths were broken I just moved my 'uploads' folder from 'public' to 'public/storage' and made sure the 'APP_URL' was set in the '.env' file.
Issue with locale column when saving Edited my database and added a 'locale' column to the 'mediables' table
Edited

November 12, 2019 at 7:42pm
Still waiting for laravel 6 support...
like-fill
1
Show more messages