Liquid : Custom filter or custom properties

[_ZoR]

Hi !

I’m acutally evaluating a migration from Magento to Shopify, and here’s my first problem.

In a Magento ecosystem, I’ve the ability to create php helpers to do “things”. I’m actually trying to find a way to add pre-order functionnality for products.

I tried many preorder apps, and all have the same problem: apps code occurs after the render of the page. Their behaviour is to change the button label of the “add to cart” button and hide the “buy now” button with Javascript code. The side effect is there’s a short time where “add to cart”/“buy now” are visible and clickable.

In Magento, what I did is modifying the template file by using my own helper with something like that :

if Myhelper::isPreorder(product)

echo “pre order”

else

echo “add to cart”

The important part is that code is executed on the server side.

Another important thing is I don’t want a metafield “is_preorder” with true/false state. I want a metafield “preorder_date” to be a real date. My function should test in real time If a product is a preorder by testing the current date. With that system, I don’t have to change anything the day of the end of the preorder period.

Here, my question is how can I handle that kind of templating ?

If I follow the Liquid “style”, I can imagine the 2 following way, but I didn’t find a way to achieve that :

• either adding a special filter like: {{ assign isPreorder = product | isPreoder }}

• or extend the liquid “product” by adding a property, like product.is_preorder (here, my wish is "is_preorder propertiy should be a function/callback/whatever that compare the metafield preorder date with current date)

Is there a way, throught custom app/theme/anything, to achieve something like that ?

Thanks for your anwser !

[tim_1]

No, you can not extend Liquid.

Also, traditionally, precize time is unavailable in Liquid as well. This is done to speed-up rendering and allow for server-side caching.

However, it’s not impossible to do what you want.

Variants in Shopify have inventory_quantity inventory_policy and also next_incoming_date, incoming so you can pretty much control your cart button look based on this. You simply set your incoming inventory and theme should be able to decide whether output “Sold Out”, “Preorder” or “Add to cart” on a cart button.

Which is probably better because if your incoming delivery is delayed, your inventory_quantity (iq) would not update until you actually accept your incoming stock, while date-based logic will update the button before you have stock to sell.

iq <=0, ip == “deny”, incoming == false → Sold out;

iq <=0, ip == “continue”, incoming == true → Preorder;

iq <=0, ip == “continue”, incoming == false → “Add to cart” for, say built to order products;

iq > 0, → “Add to cart” for stocked products;

No need for special preorder date metafield.

If you need to do something based on time, you can schedule tasks or check against current time in Flow and then change product data.

[_ZoR]

Hi Tim,

Thanks a lot for your reply, It give me some explanations/ideas.

You’re right about caching, I noticed it, yesterday I tried to use {{ assign current_date = “now” | date: “%Y-%m-%d” }} and compare it to my metafield and yes, I saw that the current date was cached.

I didn’t now about all of those properties you mentioned. It could help. But, with your algorithm, the day the release date is reached, nothing will be changed for the customer. The product will stay in “pre order”.

So, I also understood that you said there’s a way to use a scheduled task that could change the “incoming” property every day for concerned products (or similar). I’ve to admit that for now, I didn’t take a look at all at the Flow system. I will. To me, It sounds like a cron task that could occurs in the background.

I suppose the best way to setup that kind of “little logic” is to create a snippet that return the correct label, so I could use it “on a product listing page / product page / checkout”.

But, I’m pretty sure I will need a function “is_preorder” in other places, for other logic. As an example, If the pre-ordered product also have a digital file that should be available only when the release date is past. In that case, I would like to remove the link so the customer can’t download it before. To do that, If I’m correct, I will have another snippet to render (or not) the link. And so, that snippet will again contain the same “little logic”.

That’s doable, but I doesn’t sound “perfect” to me. I don’t want to rewrite the same logic many times …

Another option I can have, tell me If I’m looking in the good direction, is using Hydrogen/Oxygen/Remix to have a fully customized front end. Is that correct ? But in that case, I loose the benefits of all apps (or at least, their ‘front end’ part).

Thanks a lot !

[Jo_EarlyBird]

Hey Zor!

I asked my technical co-founders about your scenario, as I thought our pre-order app might be able to help.

Listing out a few things below, keen to hear your feedback as I’m always what different businesses need when managing pre-orders.

“Add to cart/Buy now” buttons being visible and clickable on your pre-order products’ product pages:

• We still need to render our widgets after the page has loaded, but we handle that by showing a loading spinner until we know if it’s a pre-order or regular add to cart button. This prevents the short time where “Add to cart/Buy now” are visible and clickable.

• We show the loading spinner on selectors we’ve hard-coded in, before our app fetches data. This approach has worked for most of the stores we’ve come across so far. But for yours, you might need to edit your theme to add classes to certain elements.

Not wanting to have to change anything by the end of the pre-order period:

• You can run pre-order campaigns in our app to automate and handle the pre-order admin for you. We’ve designed the UI and UX similar to running a social media ad campaign with a reporting dashboard.

• Everything is reverted back to normal by the end of the pre-order campaign date you’ve selected. Either as in-stock, or back orders (if you’ve enabled it through our app).

If this is relevant to what you need, I can share two 5-minute videos to show you what it looks like on the storefront and in our app?

[tim_1]

Yes, Flow can be seen as cron tasks, but it’s more.

Incoming data is not just about the dates – you should actually accept inventory and then the product status changes, inventory becomes positive and cache is invalidated, so it’s properly reflected on your storefront.

It’s not the date comparison that works in this case. It’s rather data-driven – when product record is updated, storefront renders it based on new data.

As for the headless – yes, it would probably be more similar to your usual ways of doing things.

Obviously it’s a much more dev-time hungry approach.

And you’d need to care about more things.