Hi,
exploring the relation between beans and uikit is proving to be an interesting experience in regards to theme elements (header, footer, etc). That said, being an utter novice, I'm either missing or overlooking something. To clarify where I'm coming from, I'm one of those who have thusfar relied on using bloated themes where the means to structure / design content is typically provided through shortcodes or (as appears to be the fashion) visual design tools).
So while exploring the LESS files I can see how handy it is for the theme as such. I'm not seeing where or how to make use of it for editing content (on page, post).
Any suggestions? And yes, I'm probably missing something, perhaps even approaching matters from a very wrong direction 🙂
Edit: bumped in to a few more things 🙂
Being a novice at these matters I tend to go by examples, picking apart puzzles (admittedly often by copying & pasting and then observing alterations). Don't get me wrong, the documentation is very clear, but a lot of concepts still are a bit beyond me. Often I find myself lacking in affinity, as well as understanding of terminology and concepts.
As such, I'm looking for some examples / starting points on a few things.
1 Sticky header / UIkit addon components
I noticed that UIkit has core, and addon components. One of those is some javascript to make header / nav sticky, with some support for things like making the header smaller / transparent. Normally I'd reach toward a plugin, but I'm curious whether beans will let me find another way. For example, using an addon UIkit component.
2 Logo / Menu
Silly as it may sound, but I'm trying to figure out a way to ensure that logo and navigation in the header are nicely vertically aligned, but I'm missing something. Is there a recommended logo image size? Or do I go back to the realm of LESS?
3 Navigation on devices
Navigation on smaller screen sizes is also puzzling me. In the sense of either having fubarred something, or - again - missing something. As an example, a menu item may have sub items. Those show on hover. But on a device, there's no such thing - only click. Resulting in not having a readily quick means to find and go to sub items.
4 JSON-LD / Schema: extending the framework
In testing I've noticed some quirks in how search engines manage the combination of plugin inserted json-ld and theme based schema (itemprop). For example Yoast's output is not optimal when facing a proper modern innovative theme. Which is fine, as it is possible to just stop(*1) Yoast from dumping json-ld, but it does raise a bit of a question for which the answer might very well be a "down the road" kind of thing. Are there plans or options for framework connected widgets which make use of / follow the current approach. For example, consider how a properly coded address widget would match with and enhance the full picture.
Don't get me wrong, json-ld / schema combo's do not have to have a less-than-optimal impact. It's just how some things out there tend to keep doing things year after year. But since there really is very little in terms of accessible framework concepts which build upon what has been set as the future, it makes me wonder what best approaches could be considered.
/**
* Disable Yoast searchAction JSON-LD
*/
add_filter( 'disable_wpseo_json_ld_search', '__return_true' );
/**
* Disable Yoast JSON-LD Output
*/
add_filter( 'wpseo_json_ld_output', '__return_false' );
So yeah, questions - lots 😛
Hey J.C,
I am glad that you are digging into Beans and you are correct to say that you don't really need any plugins as you can pretty much do everything with Beans various API's and UIkit.
1 Sticky header / UIkit addon components
Refer to this reply which would point you to the right direction.
2 Logo / Menu
There isn't a recommended logo size and I would suggest to use CSS (margin) if you need to adjust the alignement. Feel free to ask if you get stuck 🙂
Regarding UIkit component, it is explained how to use it in this article. I also suggest to take a look at discussion I had with Mariusz, read the discussion from this reply onwards.
3 Navigation on device
This conversation should greatly help you.
4 JSON-LD / Schema: extending the framework
I am not sure I understand your question 100% correctly. When it comes to Beans markup, you have full control of the attributes and may use Beans HTML API markup control do so. It would be great if you could give an example on one markup to illustrate what you mean.
Cheers,
Thanks for the reply 🙂
In regards to using plugins, it's something I've been thinking on. The typical reflex (proverbially speaking) of snagging a plugin for this or that does indeed appear to be not necessary, even overcomplicating things at times. That said, I'm getting the idea that it might be a good idea to keep additions / customisations out of the main theme package, perhaps even away from the child theme approach, and instead use a functionality plugin?
It may seem a bit strange, but that way it might not only be more clear for new people to figure things out, but it could also open a relatively easy door towards providing such a functionality plugin with simple on/off/edit features.
Thanks for the suggestions, I think I'm going to have a busy afternoon with those 🙂
As for item 4, maybe I should have been more clear indeed. Picture it like this: say you've got a skeleton where the bones are the core schema's. Providing structure through markup within the theme package (WebPage, WebPageElement, et alii. Now often people put clothes on the thing, by means of json-ld scripts which provide duplicate or conflicting structured data. It might be a good idea for an article where beans schema markup is listed?
For example, Yoast will generate a script for WebSite, but it will also insert other things. For a search engine walking through that this can provide conflicts (which has consequences).
Because of this, I've been trying to figure out which schema elements exactly are part of the theme / api markup & structure. With this clear, it becomes a lot easier to add on further structured data without inserting duplicate or conflicting elements through JSON-LD (which is a lot easier and flexible to provide structured data insights for actual content and data relations).
A practical example would be that of a local business widget, showing the site owner's contact / business details, with or without map functionality - there's tons of those around. While it's possible to use any of those, it strikes me as less than optimal. With a framework like this, it seems more productive to follow framework concepts, markup and structure to provide such (widget) functionality using the framework's API.
But, and this is probably where my lack of understanding comes in, it seems to me like it might be better to provide such features seperate from the theme / child theme, once again with a functionality plugin? I know, it's possible - and perhaps more logical from a developer perspective - to keep things within the core package? It just strikes me that down the road it might make more sense to third parties if there were a seperation between.
You are correct to say that it is good practice to extract functionalities in a plugin when you are building your website.
Regarding the schema, it is really part of the front end HTML so it wouldn't be justified to be in a plugin but rather belongs in Beans Core. Maybe what we could do is to add a theme support to allow users to turn off/on if one wanted to add it via a plugin or add custom schema manually (I have added it to the feature requests).
Cheers,
That might be an idea. I'm not sure though. Let me put it this way, there is real benefit in using schema integrated markup to define structure for data.
Obviously there are schema elements which are not structure specific, but information specific.
I think it might be an idea to differentiate between these two. For structure, the current approach is picture perfect (except for what I noticed elsewhere, using remove_action can result in schema elements getting stripped, but that's a different discussion). Other than reinforcing this I can't see reasons to deviate from this.
Where it comes to information, this is a bit of an efficiency thing. Everything can be put in itemprops and the likes of it. But is it time efficient? Are informational elements thus inserted easy to maintain? Perhaps, but not without additional work, or investments in bloating the framework with theme options and such. JSON-LD isn't just the simplest, but also Google's preferred medium for the information layer.
The combination of the two is what weighs heavily, before quite a few other things.
Maybe I'm being silly, but I do think that the current approach is the better one, but there should be a clear view on what structure elements are supported / provided. Once the framework starts getting used for "projects" (what everyone else but Automatic calls features like plugins and widgets) the benefits of that road should become clear. A beans widget will not only keep things light, simple, clear and integrated. It will also provider data structures and relations support out of the box. After all, it will be built upon the very same syntax and structure elements as the theme.
A practical example is how so many people look for Local Business widgets to provide highly sketchy schema code support, with widely varying degrees of continuity support. A beans widget from the same beans codebase framework just oozes stability, dependability, extensibility.
Thanks for your feedback J.C, I definitely see where you are coming from and hopefully plugins as such will come. Beans is incredibly flexible and building such plugin is made really easy for devs.
I have been told that some child themes and premium themes are in building process by various devs and heard about some plugins in the making too 🙂
Beans is growing rapidely and there is definitely a lot to come in the future!
You know you're going to have to extend guidelines & best practices to plugins & widgets pretty soon 🙂 I'll readily admit though, it would be nice to see people popping by with their experiments!
Meanwhile I've figured out the logo/menu thing, hurray 🙂
There isn't a recommended logo size and I would suggest to use CSS (margin) if you need to adjust the alignement. Feel free to ask if you get stuck 🙂
Well, I'm stuck indeed 🙁 I just can't seem to get a vertical alignment for logo / header nav. Entirely possible though that I'm taking a clumsy approach, namely that of adding attributes to beans_fixed_wrap[_header] For example:
beans_add_attribute( 'tm-primary-menu', 'class', 'uk-vertical-align-middle'); Both with and without the same applied to tm-site-branding it doesn't appear to make a difference.
Is that a working approach, or did I miss a turn somewhere?
Hey J.C.
That wouldn't work as the logo is floating left and the nav floating right. You can either adjust it using CSS margins or a more dynamic (but a bit more heavy) approach using flex. Adding margins is pretty straight forward and standard CSS so I am not going to give an example. Here is the example for the flex approach:
add_action( 'beans_uikit_enqueue_scripts', 'example_enqueue_uikit_assets' );
function example_enqueue_uikit_assets() {
beans_uikit_enqueue_components( array( 'flex' ) );
}
beans_remove_attribute( 'beans_site_branding', 'class', ' uk-float-left uk-margin-small-top' );
beans_remove_attribute( 'beans_primary_menu', 'class', ' uk-float-right' );
beans_add_attribute( 'beans_fixed_wrap[_header]', 'class', 'uk-flex uk-flex-middle' );Then in your child theme (from official starter child theme) style.css or style.less depending on which one you chose to go for, you will have to add the following snippet:
.tm-primary-menu {
margin-left: auto;
}Happy coding,