wait sorry, where exactly are you trying to access that? In the block itself, or in a repository hook maybe?

site/layouts/block.blade.php

ok makes sense

yeah in that instance the block is completely dynamically hydrated. It's an object that doesn't even know it's attached to something yet

i guess we could inject the record that it is being edited on

in the request to preview the block we could add the module name and ID of the record you're editing, which would allow us to hydrate ->blockable

In BlockRepository->hydrate?

the editor block preview rendering is all happening in

BlocksController@preview

currently the request only submits the block content, not it's context

but yeah if we send blockable_id and blockable_type in that request too, we can add some code in BlockRepository@hydrate to load the record

might be worth trying instancianting a block model with those fields in, we might not even have to do anything, the morphto relationship should load

I'll give this a try later today and get back to you @Bubumeister

👍 Thanks!

Maybe also a newly created (not yet persisted) block benfits from this as well. E.g. access a template field from the module and previewing the content in a specific style.

@User When I enabled supportSubdomainRouting there is an error here : https://github.com/area17/twill/blob/b5a0b52bdf2c7b6fde49e8946d9440fb94fbd166/src/Services/Routing/HasRoutes.php#L96 It should be $middleware not $middlewares no ?

Maybe I do something wrong but when change it to $middleware everything is fine 😉

definitely, that's a regression from a refactor. I was going to review this PR today that is addressing it. https://github.com/area17/twill/pull/908

I did a PR here : https://github.com/area17/twill/pull/908

ok that's you, perfect 🙂

I will merge it

nice !

and there is also a bug when you call $this->urlGenerator->route in the Handler the $subdomain params is missing , I fix it but maybe there is a more elegant way to do it 😄

(par contre mon anglais est naze donc je vais m'arrêter là bonne journée hein)

I see

lol, pas de soucis, let's move to #811986379034198017

Has anyone been able to implement a src field to input a source of a hosted image? For instance in the WYSIWYG form, I want to be able to insert media between posts so before I create the post I upload the media to my media library and then grab the links from there (hosted on S3) and then I want to then add these to the post body in an

<img src="HOSTED URL" alt="" />

but this does not seem possible. My solution currently is to create the post, head over to datagrip, grab the post and then edit with the img tags and save

@User the WYSIWYG field does not support images and will probably never do, because that's 99% of the time a wrong approach, especially with a field that saves HTML in database. by

posts

, do you mean paragraphs in the field?

Hey @User yeah I don't want to save the image in the WYSIWYG field, though I was hoping to be able to create a img source field and just add the image source url into this so when a user views the post they will see the fetched image from the url in the post body.

posts

is my table for the blog content/body, this will be from the opening line all the way to quotes and code samples or links and post content as on a blog.

I don't want to save the image in the WYSIWYG field as this creates a base64 entry into my DB and that is just cause for huge space consumption

if the image has a specific location on your page like before or after the wysiwyg content, you should use a

medias

field in your form. if the image needs to be mixed in with the wysiwyg content, you'd have to use 2 blocks in the block editor: 1 for text and 1 for images. that way you can create a text block then an image block and then another text block for example.