https://twill.io logo
Join Discord
Powered by
Twill 3 publication dates
# ❓questions
j
Hi using twill 3. I added publish start and end date in my migration and model. But in my edit form sidebar nothing is showing up like in twill 2?
How do i ge them there?

https://cdn.discordapp.com/attachments/1096435065526952046/1096435469723631706/image.png▾

i
hmm they should show automatically if you have them in fillable and casts
might be a regression if not, let me check
j
I forgot to add the cast and published one already. Maybe that's an issue?
But tried a second one, also there not showing
I have cast them:
Copy code
public $casts = [
        'publish_start_date' => 'datetime',
        'publish_end_date' => 'datetime'
    ];
But seems they are null in the DB: "publish_start_date": null, "publish_end_date": null
Checked the database, the columns are there.
l
Not that it's much help, but those fields are by, default, timestamp, not datetime in my database. I used the default commented out ones in the twill created migration. However, found that casts just wouldn't work to do this, and created a mutator to convert to the format required for saving
Copy code
public function publishEndDate(): Attribute
    {
        return Attribute::make(
            get: fn (string|null $value) => $this->formatDate($value, 'get'),


            set: fn (string|null $value) => $this->formatDate($value)
        );
    }
Copy code
protected function formatDate($value, $action='set'): string|null{
        if ($value === null) return null;
        $time = new Carbon($value);
        if ($action =='get'){
            $time->toFormattedDateString();
        }
        else {
            $time->toDateTimeString();
        }
        return $time;
    }
Somebody else could probably write that in one or two lines!
For the 
publish_start_date
, you can override a function in 
model.php
.
Copy code
public function setPublishStartDateAttribute($value): void
    {
        $this->attributes['publish_start_date'] = (new Carbon($value))->format('Y-m-d H:i:s');
    }
Just adding this for completeness. It struck me for both these fields, that it was the datepicker was just being awks!
i
you shouldn't need to add any custom code for these fields to work
I'll investigate
l
I didn't want to trouble you!😳
@ifox when I was trying to find a solution... https://github.com/laravel/framework/issues/46737#issuecomment-1507557295 Perhaps Laravel?
i
just tested from a blank module: migration
Copy code
$table->timestamp('publish_start_date')->nullable();
$table->timestamp('publish_end_date')->nullable();
model
Copy code
public $casts = [
    'publish_start_date' => 'datetime',
    'publish_end_date' => 'datetime'
];
works fine for me
l
...and that's using the datepicker?
i

https://cdn.discordapp.com/attachments/1096435065526952046/1096477162841854173/Screenshot_2023-04-14_at_6.48.41_PM.png▾

no need to add any field in the form for this
they show up here
l
I did a fresh Laravel install yesterday, to be on the safe side, still had a problem with date format with either of the two (new) modules I installed late yesterday. :🤷: My minimum stability is dev though...mmm
i
Copy code
laravel new twill-3-publication-dates
cd twill-3-publication-dates
composer require area17/twill:"^3.0"
php artisan twill:install basic-page-builder
then uncommented the 
publish_start_date
and 
publish_end_date
in the generated migration and added them to the model fillable and casts. no issues. also tried to use stability at dev and composer update, still no issues.
l
I have the same install. Must give that a go tomorrow when I get time. Thinking it may not be twill at all. Maybe something else.
I got a bit of time to do this. Actually had three attempts before I was sure I got all in right order, including migrations. Still the same result as shown. Casted both as 
'published_start_date' => 'datetime'
and 
'published_start_date' => 'datetime:Y-m-d H:i:s'
for both fields. Any time the datepicker is used, up pops this error. Doesn't matter if date picked is before now() or later in either field. If status is changed from draft to published, the start date is added by the system, and correctly stored in the database, then correctly retrieved and displayed by the datepicker, next time form is opened. Using the datepicker to change this value results in the same error. I am curious what's causing this, but not sure it's worth any more time, by either me, nor, particularly, you! I think there may be an implication that is something outside the laravel / twill setup. FYI Ubuntu 22.04.2 Apache 2.4.57 mysql 8.0.32 (It's Sunday, and I'm off to make curry!)

https://cdn.discordapp.com/attachments/1096435065526952046/1097136409296502864/date_save_error.png▾

j
I have exactly the same:
Copy code
$table->timestamp('publish_start_date')->nullable();
  $table->timestamp('publish_end_date')->nullable();
Copy code
public $casts = [
        'publish_start_date' => 'datetime',
        'publish_end_date' => 'datetime'
    ];
But it's now showing for me in the cms.
Did a fresh migration and local install and php artisan twill:build but no luck yet
Some things which may or may not be related, just guessing. I have: $this->disablePermalink(); on the controller as i'm building en API and don't need urls.
No thats not doing anything
And the fields are present in the database 🧐
I see you have revisions and preview changes on. I don't have. When using the cli i said i don't want a preivew and i picked said no to revisions. Maybe this makes a difference, ill check
So still no dates 😮 but the rest is present

https://cdn.discordapp.com/attachments/1096435065526952046/1097445898516168765/Screenshot_2023-04-17_105657.png▾

This is a new blank module generated using the CLI.
I'm on twill 3 and laraval 10
i
Please share a repro repository and your database version
l
You did add those two fields to $fillable property in your model? (I forgot to do that on the first go! 🫢 )
j
My man
im so stupid
🫣
I only added the casts
Working as intended
thx for you patience 😶
i
glad you figured it out! missing fillable are always painful, but better safe than exposing a mass assignment vulnerability
j
Let's be honest it's not the first time either 🤣
l
Did I ever tell you the time I started programming in PHP, and could never find the semicolon button when I needed it? 😂
i
When I switched from azerty to qwerty, I missed my $ key for a while
j
Yup programming is fun sometimes 🤣 I tried fixing a bug for 6 hours+ only to find out a variable was capitalized and i was trying to acces it without captital letter, it was a SOAP XML api so that did not make it easier on the eyes.
i
slippery soap
l
@jefsev I found an interesting one today about fillable fields, thought I might share. When creating a Medias field, the name of the field has to be in the fillable array of the model, or the selected image won't save. I never thought of adding it, since that field doesn't exist in the model table! Just for future reference! Inference is that the fillables applies to the twill_mediables table, and probably at least some of the other linked ones as well.
i
that's not correct @Lucius Vorenus you do not need the name of medias fields in fillable
l
I have a field in my article (module) 
image_url
, as I thought I would be saving an image url for the opengraph photo for the article. As such it was added to the 
fillables
property. I ended up using that field name in a component block (article header) which saved and displayed as expected. Creating a new componentBlock, 
image
, with exactly the same logic, but a different field name (
article_image
), I could not get the image to save (crops had been added for 
article_image
). It indicated that all had saved correctly, but either viewing it, or reloading the form after the update showed it as missing. Adding 
article_image
to the fillables on the model fixed the problem (though I'm still wrangling over crops, and whether their exists a default set in twill).
i
the default crops configuration only works for a medias field not in a block named 
cover
, it's here https://github.com/area17/twill/blob/9d53e795732521d1515661f12ba793dcee21d7b4/config/twill.php#L239. for blocks, it works by default if the field is named 
image
. Configuration is here https://github.com/area17/twill/blob/9d53e795732521d1515661f12ba793dcee21d7b4/config/block_editor.php#L23. any medias field that you add to your form or a block needs a corresponding crop configuration.
I'm very surprised by the fillable helping it save
l
Thanks.I'll have a look at that later, when I'm back at the computer.
I've bookmarked those two. It's delightful that i can just call every medias field 'cover' in the componentBlocks, and I get all the default crops, including flexible. It's some package, is twill!
4 Views
PreviousNext
Powered by