Extend EssencePicture to accept an image OR a URL of the image

[ricky-wong]

See
https://groups.google.com/forum/#!topic/alchemy-cms/HTGS63QD898
(Internal) https://app.asana.com/0/11410371085627/14970415489869

We have some images uploaded already, and want to use those within existing EssencePicture elements, however, this element only supports uploading images and using existing CMS images.

As a temporary workaround, we've added an EssenceLink element next to the EssencePicture element, using the EssenceLink URL when provided.

However, this solution is very short-sighted. It doesn't even support <img alt> attributes.

Before we dive too deep in the workaround, and create a bunch of data structures using the workaround routine, it might be worth modifying EssencePicture to support what we would like.

[wuservices]

Good point regarding attributes such as alt. This isn't something we've
discussed as an issue here, but definitely something we need for basically
images for SEO and accessibility (especially important in emails).

Would we just duplicate the essence to make a new one, extend the essence
and create a database migration, or something else?

On Mon, Jul 28, 2014 at 4:21 PM, Ricky Wong notifications@github.com
wrote:

See
https://groups.google.com/forum/#!topic/alchemy-cms/HTGS63QD898
(Internal) https://app.asana.com/0/11410371085627/14970415489869

We have some images uploaded already, and want to use those within
existing EssencePicture elements, however, this element only supports
uploading images and using existing CMS images.

As a temporary workaround, we've added an EssenceLink element next to the
EssencePicture element, using the EssenceLink URL when provided.

However, this solution is very short-sighted. It doesn't even support attributes.

Before we dive too deep in the workaround, and create a bunch of data
structures using the workaround routine, it might be worth modifying
EssencePicture to support what we would like.

—
Reply to this email directly or view it on GitHub
#6.

[ricky-wong]

I am leaning towards extending the essence.

We could consider doing a database migration either way, but there are so few links so far (maybe 30 max) that maybe it's not worth it.

[wuservices]

Essences are inherently connected to a model and thus a database table. If
you added any fields to the essence, then modifying the database (and thus
creating a migration) would be necessary.

Can you actually extend an essence in the OOP sense (I'm not sure and I'm
asking) or were you thinking of just overriding it?

On Mon, Jul 28, 2014 at 5:35 PM, Ricky Wong notifications@github.com
wrote:

I am leaning towards extending the essence.

We could consider doing a database migration either way, but there are so
few links so far (maybe 30 max) that maybe it's not worth it.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[ricky-wong]

Oh I see. I thought it would just be blank for any existing essence that doesn't have it.. similar to how we add fields to things today.

This means that I'm not sure if this is possible.

[wuservices]

It may still be possible, but this isn't something we've really done
before. I think you may be referring to when we add an essence as a new
ingredient to an element and the admin UI prompts you to create any values
for ingredients that were added after the element was created.

We can probably modify an essence, but I imagine that the process would be
a little different. Since we'd be adding columns to a table and thus fields
to an essence, we'd just have values for whatever new things we add out of
the gate. Since the rows of existing essences already exist, there's
nothing in the UI to initialize. Whatever values there would just be
whatever's in the database.

On Tue, Jul 29, 2014 at 7:28 PM, Ricky Wong notifications@github.com
wrote:

Oh I see. I thought it would just be blank for any existing essence that
doesn't have it.. similar to how we add fields to things today.

This means that I'm not sure if this is possible.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.