Code Amp

Hey @veganliebe

Thanks for your message some great points in there!

I’ll try to address each point one by one:

1. Dynamic visability
Because each item (post template), in a layout is generated from a WP_Query – choosing what to show or hide becomes a bit tricky. Because the list is generated, its hard to “pick” a post, and do something with it (like add block visibility conditions) because that generated list of posts might change under various circumstances.

I think a practical solution (the only one I can think of right now) would be that you could modify the query to include / exclude what you want.

In fact, this is somewhat already possible (but requires a little coding). You can filter our query using the hook ‘custom-layouts/layout/query_args’:
https://customlayouts.com/documentation/action-filter-reference/

And from there, you can build out some advanced functionality. Showing/hiding posts based on user role would look something like this:

A. Create a custom field for your post type, that records which user roles are able to view the post (I tried looking for something premade for this like ACF but I’m not sure it exists) – then update your posts accordingly with the user roles that are allowed to view that post
B. Use our hook (linked above) to filter the layout query, so that only posts with the current users role capability will be displayed.

If you can handle a bit of coding, I would be happy to dive further into the logic of setting something like this up with you.

2. Theme fonts – this is a huge one, but a lot more difficult to tackle that I first thought.

Essentially the problem here is that in WP there is no standardised way of a theme to add a font, well not yet exactly. It does look like there is one way to tap into this though – page builders.

Page builders such as Elementor, Beaver Builder, Divi and (soon) Gutenberg etc have design systems, and ways to implement fonts in a standard way. I think the plan for this is, to build integrations with each page builder, so we can detect and pull those fonts into our plugin.

Every other theme (not based on a page builder) could implement fonts in hundreds of different ways, and there would be no logical way we could detect those fonts, and offer them in our admin UI… The good thing about page builders is that they mostly standardise some of this, so we could add some code to extract that information and use it our layouts/templates.

Anyway, those are the limitations as I see it, we plan to add page builder support (for fonts and other styles) in the not too distant future – early next year I would imagine (there is a big update planned).

3. Additional image fields
Great idea, we’ve had a few requests for this already and it’s on our todo list.

4. Responsive in more places
Also planned! The truth is I’m not 100% happy with the current UI, so I didn’t want to roll that out across the whole plugin when I know its going to need reworking sooner rather than later.

Also, we’re kindof waiting to see what Gutenberg is going to do – its been in discussion for a long time how to implement responsive controls and there are some talented people working on making this a better experience right now.

My thinking is, like most of our UI, we’ll likely copy their implementation – because in the end it probably going to be easier to use that something custom we make, and also, people will be familiar with the gutenberg implementation (over time) as its the default experience shipped with WordPress.

Anyway, if they take too long on that front, no doubt we will cook something up ourselves!

——-

Also – I’m going to sticky this so other people can share their feature requests here.

Thanks for your feedback so far, and please do let me know your thoughts / any further suggestions.

Best

• This reply was modified 4 years, 7 months ago by Code Amp.
• This reply was modified 4 years, 7 months ago by Code Amp.

Hey @ja4st3r

Yeah I think you are right on this.

Essentially, we use the WP functions for converting the timestamp, which takes into consideration the timezone of the site but not necessarily the ACF time.

While we are planning to add more ACF specific functionality in the future, for now my suggestion (work around) would be to:

1. Use a text field instead of custom field
2. Inside the text field, use the the ACF shortcode for displaying the time

We are planning on some big improvmements (such as better ACF integration) but they are likely coming early next year.

I hope that helps!

Best

Best

Hi @ja4st3r

I need to have a think about the apis for all this (which is why some things are undocumented), but I think you could have some success with the following:

1. Check what is already in $query_args and apply your changes conditionally.

If the gutenberg layout you want to target, is the only one displaying events, then you can check it the $query_args['post_type'] === 'events (it might be an array array( 'events' ) ) and then you could add your ordering parameters.

2. Alternatively, you could use the before_render hook, get the extra info about the layout there (this has an undocumented paramater which gives you all the layout settings).. and then add your query_args filter there.

Then make sure to remove the query_args hook in the after_render hook for the layout (so you don’t affect all layouts queries).

Let me know if that all makes sense?

For reference, all our hooks are here (some with undocumented parameters): https://customlayouts.com/documentation/action-filter-reference/

Best
– Ross

• This reply was modified 4 years, 7 months ago by Code Amp.
• This reply was modified 4 years, 7 months ago by Code Amp.

Hey @palomar83

Regarding ordering by post meta – you can go either way. I would probably say, loading S&F on to the query, just for ordering is probably overkill – I’d would just use the query_args filter…

If you plan to let you users Search + Filter the layout later, then I would go the S&F route…

I’ll mark this as resolved for now then, @nitof please let me know how you got on.

Best

• This reply was modified 4 years, 7 months ago by Code Amp.

Hey Keryn

Thanks for your replies.

I see you are using S&F pro, would you be able to contact support and mark for my attention?

Then I’d be able to get your logins and take a look around the site for any issues.

Regarding the uninstall, I’ll have to double check, I don’t think it has uninstall processes right now… However at this stage the issues you mention don’t seem related to how the layout is saved / stored.. I could be wrong though…

Thanks
– Ross

• This reply was modified 4 years, 7 months ago by Code Amp.

Hey @palomar83 + @nitof

I managed to figure this one out – if your attribute is not public it won’t be shown.

It seems enabling “archives” sets the taxonomy for the attribute as “public” (via the WC attributes screen):

https://snipboard.io/yfoHNX.jpg

Can you test and let me know?

Best

• This reply was modified 4 years, 7 months ago by Code Amp.

The true should be a 2… I’m suprised that works!

So it should be:

add_filter( 'custom-layouts/layout/query_args', 'layout_query_args', 10, 2 );

Best

Great stuff @herondino glad you are setup!