Tweaking the Site Branding

The following is basically just an experiment leading to unexpected diversions, but with - perhaps - interesting results. What got me started was coming across a few search results (Google, Bing, Yandex) where - somehow - within the displayed rich snippet search results a useable phone (tel:) link was made available. Surprisingly, without the use of json-ld enhancement.

Turns out, it's basically just parsing schema.org structure elements:

@type WPHeader
headline  https://mk-pmo-jcmrs.c9users.io/
description Keyword action phrase - call 562-867-5309

So I set out to tweak the beans_site_title_tag a bit. I'm sure this can be done in a more elegant manner, but hey - learning curve.

beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-text-center');
beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-margin-top');
beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-text-break');
beans_replace_attribute( 'beans_site_title_tag', 'class', 'uk-text-muted', 'uk-text-success' );

I considering using beans_remove_attribute to get rid of the uk-text-small class, but that was not the brightest idea of the day. Turns out, Beans came to the rescue with Less, but more on that later.

The result was having figured out a modicum of control over this element. But how to add a useable phone number (or other type of link). I must admit, I actually tried putting raw html through WP admin itself. Also not the brightest idea of the day. That's alright, because beans let's you throw around markup everywhere you want to. In an orderly manner as well. So I added a test tel: link to the beans_site_title_tag.

add_action( 'beans_site_title_tag_append_markup', 'mk_site_title_tag_append_markup' );

function mk_site_title_tag_append_markup() {

  echo ' - bel <a href="tel:1-562-867-5309">562-867-5309</a>';

}

Which worked well, or rather, well enough. It appended the markup, but obviously styling was horrific. On top of that I remembered that various browsers, apps and even device platforms have quirks where it comes to picking up on such links. They parse the content, notice there's a phone link and treat it in their own manner. As a consequence, I found myself having to cut that off before it happened, and the only way to really do that is provide the styling before any such process can mess things up. Caveat: I haven't tested with everything, just the typical ranges for devices (android, ios).

Don't laugh, but not having any clue whatsoever on weird things like pseudoselectors and whatnot, it didn't take long before I figured out that the availability of Less provides a more clear procedural logic for approaching these things. Especially taking into account UIkit's Customiser and Beans support for it all. So I ended up with making use of Less variables and a modification routine utilising the available variables. I'm sure this can be done more elegantly, but once again: learning curves. Also, I'll probably need to tweak positioning (and such), considering I still have to integrated a Header Bar (result from another experiment), not to mention not getting owned by sticky meny details. Either way, this ended up in style.less:

/* Site Branding modification
 ========================================================================== */

.tm-site-title-tag a:link {
  color: @text-success-color;
 font-family: 'Lato', sans-serif;
  font-size: @text-small-font-size;
 line-height: @text-small-line-height;

  &:hover,
  &:active {
    color: @base-link-color;
    background-color: #fff;
 }
}

.tm-site-branding a {
 color:  @text-primary-color;
  font-family: 'Libre Baskerville', serif;
  font-weight: 400;
 &:active {
    position: relative;
   margin-top: -1px;
 }
}
.tm-site-branding a:active {
  position: relative;
 bottom: -1px;
}

Obviously I'm following the default available UIkit styling provided with the Beans framework itself, though a few bits of testing confirmed that you can easily declare elements (for example @text-success-color) as variables, so I ended up applying that trick to the primary menu & dropdown as well, example:

// Variables modifiers

@dropdown-navbar-background:   #fff;
@text-success-color                #8cc14c
et cetera

On the side, it appears that using Less making use of Google Fonts is not a problem, and the output is actually quite good, keep in mind this is all in development mode though - how this compiles, what the output looks like is something I'll have to tackle some other time. In case anybody wonders:

/* Font
 ========================================================================== */

@import url(https://fonts.googleapis.com/css?family=Libre+Baskerville|Lato);

Which using Less can in turn be declared as variables for text classes, nifty.

In the end, the result is a tel: link within the wpheader description markup, which - always depending on the complex math and policy preferences of Big Search - once given enough weight is put to use for rich snippets. Fun thing, you can also use other link elements which are tied to schema actions, which then end up - controllably - within first view on search result elements. Added bonus, they give a litle extra weight.

On the side, got to love the uk-text-break class.

What I haven't figured out yet is how to ensure that it displays properly for all breakpoints. As you can see I had to add a uk-margin-top in order to getting slapped with Tap Target errors (which is a term for search providers being concerned about people with big fingers using small devices - UIkit in spite of being touch and swipe friendly doesn't really accomodate this out of the box). Hiding the site title tag is a really bad idea in seo. Removing it is an ever worse idea, as it completely screws up schema structure (at which point the robots get angry). I'm serious, this is one information tag which needs to be present somewhere on a page / blog.

Repositioning seems to be the only way. Which may get in the way of the primary menu for various breakpoints. I may have to completely remake the actual header so that it contains a grid - I'm open for suggestions.

Either way, this was fun.

Just thinking, I found a code snippet among the docs for removing site title tag. It's nifty, but it's also a bit destructive - after structured data markup testing it turns out that doing this (in this case for site title tag) wipes out a core element of wpheader. When the bot finds no description, it either substitutes it with whatever markup it finds next (bad bot, obviously, really funny when you see this happen on sites that use visual builders like VC). Or it parses whatever comes next, but decides to not add weight to both site and (!) content value (Google has a tendency to hurt sites hard with this).

So I did some more testing, this time to reinsert it.

// Adding a header bar and moving the site title tag to there.
// Issues: Mountain View sanctions; site+content. Schema; WPHeader headline can change to undesired pulled in markup.

// Removing the site branding.
beans_remove_action( 'beans_site_title_tag' );

That takes care of removing the thing. But the idea is to put it back, just in another place where we can make good use of it (seriously, site title tag tends to get marked as high value in Search for keyword action phrases, so it's a terrible waste to just ditch it).

// Add Header Bar
beans_add_smart_action( 'beans_header_before_markup', 'header_bar' );

But in order to put it somewhere else, it has to be made to fit in. And this is - I think - where things break down in terms of the actual data structure markup.

// Strip the default styling for site_title_tag before giving it a new place. Add class attributes here, or within markup?
beans_remove_markup( 'beans_site_title_tag' );

Now I can style the area I want to actually place it in until I see blue in the face:

// Style beans_site_title_tag
function header_bar() {

  ?>
  <div class="tm-header-bar uk-block-muted">

    <div class="uk-container uk-container-center uk-text-justify">

      <div class="uk-grid" data-uk-grid-match data-uk-margin>
         <div class="uk-width-large-1-2 uk-width-medium-1-2 uk-text-primary uk-text-middle uk-text-left uk-text-center-small uk-text-break">
           <?php echo beans_site_title_tag(); ?>
         </div>
          <div class="uk-width-large-1-2 uk-width-medium-1-2 uk-text-right uk-text-middle uk-text-center-small">
            <a href="tel:1-408-555-5555">Call now to get your beans!</a>
          </div>
      </div>

    </div>

  </div>
  <?php

}

But this does not add the data structure back in. Now unless I'm really stuck with my head in a ditch the site title and the site title tag are two distinct elements within beans. That should make it possible to reintroduce either or both elements somewhere else WITH the connected data structure, no?

Question: <?php echo beans_site_title_tag(); ?> basically tells wp where to place the beans_site_title_tag Header Fragment.

That function consists of the following:

function beans_site_title_tag() {

 // Stop here if there isn't a description.
 if ( !$description = get_bloginfo( 'description' ) )
    return;

 echo beans_open_markup( 'beans_site_title_tag', 'span', array(
    'class' => 'tm-site-title-tag uk-text-small uk-text-muted uk-display-block',
    'itemprop' => 'description'
 ) );

    echo beans_output( 'beans_site_title_tag_text', $description );

 echo beans_close_markup( 'beans_site_title_tag', 'span' );

}

So why does it not result in the correct markup (note: itemprop output) when called. Added as a custom function however it does - yet in such a manner that it does not get parsed for structured data.

I'm wondering at this point whether or not in beans it is a requirement to keep elements such as these (containing schema markup) contained within the same fragment? beans_head? That would be strange.

Hey J.C.

Glad to hear you are experimenting things. A few notes in your code. When adding/replacing/removing attributes you can add multiple add the time. For example:

beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-text-center');
beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-margin-top');
beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-text-break');

can simply be:

beans_add_attribute( 'beans_site_title_tag', 'class', 'uk-text-center uk-margin-top uk-text-break');

Even easier, you your very first snippet which contained the code above you also have a replace so you can replace the entire snippet with the following line:

beans_replace_attribute( 'beans_site_title_tag', 'class', 'uk-text-muted', 'uk-text-center uk-margin-top uk-text-break uk-text-success' );

Then I see in other code snippet that you use beans_add_smart_action. You don't have to use that and may use add_action unless you want your action to be extendable further for you or other users if it is a production product.

Regarding the title tag itemprop, it would be there no matter where you use beans_site_title_tag() but I see you have a line of code that removes the markup beans_remove_markup( 'beans_site_title_tag' ); itself. Indeed if you remove the markup, it won't be there 😉

It's nifty, but it's also a bit destructive

We have already spoken of the impact of modifying things and it is up to you not to break things. In fact, if you type asdf anywhere in a PHP file it will completely break your website. This isn't PHP fault, it is your duty to follow the way things work, we just enable you to do some magic 😉

Happy coding,

Heh, I've heard that before 🙂 "don't break things!" 🙂

Serious though, I see the point. Yet I'm not sure I see a way to take the beans_site_title_tag out of where it is by default, and put it back in another spot.

I mean, in order to get it in one place, you'd have to remove it from its default place, no?

Yes and no, depending on what you do with it!

If you call the function manually somewhere else (in header_bar() in your case), yes you have to remove the action using beans_remove_action( 'beans_site_title_tag' ); and not beans_remove_markup( 'beans_site_title_tag' ); which would remove the HTML markup only.

If you just want to change the hook it is attached it to (move it around), then refer to this reply 🙂

Hope that helps,

// Add Header Bar
beans_add_smart_action( 'beans_header_before_markup', 'header_bar' );

You mention I can use the regular beans_add_action, when I do this (in an otherwise default functions.php) it results in a bunch of errors printing on the page. With beans_add_smart_action it does not. It makes no difference whether I have the <?php echo beans_site_title_tag(); ?> within the markup or not, it also matters not whether I use before or prepend. What am I missing? Chances are there's something messed up with my workspace though, considering the errors:

Warning: Missing argument 3 for beans_add_action(), called in /home/ubuntu/workspace/wp-content/themes/tm-nursing/functions.php on line 41 and defined in /home/ubuntu/workspace/wp-content/themes/tm-beans/lib/api/actions/functions.php on line 31

I'll try to figure out what's going on there 🙂 Moving right along.

beans_modify_action_hook( 'beans_post_title', 'beans_fixed_wrap[_main]_before_markup' );

This moves the post tile before the main content area. Now this should "take along" the fragment markup. From the looks of it, this is exactly what happens.

Yet when I run the output through a structured data test it gets weird. No longer is the post title read as headline for the CreativeWork type. Is it possible that the schema markup within fragments do not carry relations to their type? I think this may be the case.

If so, I'm not sure how to maintain a data structure when creating a custom content layout. If there is a way, I'm getting the idea I might have to keep the order of schema markup generated on page coming from the schema markup contained within fragments in the exact order by which Search reads and expects it. To be honest, I think I'm going to leave this one rest until such a time as I figure out more basic things like the UI around the content itself. I think this will have to wait until I figure out how to rework beans_content properly.

Obviously I'm likely to be screwing up something here, yet when I use the abovementioned directions to move around the site_title_tag it gets interesting. In the original experiment I created a header bar:

// Add Header Bar
beans_add_smart_action( 'beans_header_before_markup', 'header_bar' );

An alternative approach would be:

// Add Header Bar
beans_add_smart_action( 'beans_header_prepend_markup', 'header_bar' );

I noticed that in the first case the use of a sticky header resulted nicely in the header bar not getting pulled along, but ending up out of view. In the second case, it remained visible when scrolling down. When I applied the site title tag before the header markup, by means of echo inside the header bar, it's schema markup ends up being read as description for WebPage.

beans_modify_action_hook( 'beans_site_title_tag', 'beans_header_prepend_markup' );

When I do that, it ends up - correctly - as description for WPHeader.

The first smart_action approach puts the new header bar outside the actual header itself, with as result Search not having a clue on any relation so it just throws it the first place it can throw it at. With the second approach it sees the site title tag in another spot, yes, but within WPHeader, thus it reads it in as it should.

From this follows that at least for things like site_title_tag I should be able to move it around on page, as long as I keep things within the beans_fixed_wrap[_header]? For this that would likely be fine, but while I can thus reposition the actual site title tag element itself, how do I put it within the new header bar itself.

I have to make sure I use prepend_markup, but can I use that hook to put the site title tag inside the header bar output? I get the idea that if there were a header bar fragment this might be a lot simpler.

Caveat: I'm not sure this is making sense, I'm missing a lot of the terminology to express things for a code perspective - apologies.

Hey J.C.

What I suggested is that beans_add_smart_action() may be replaced with add_action() unless you want your action to be extendable further for you or other users if it is a production product. Be careful, I are trying with beans_add_action() while I was say add_action(). If you try with add_action() you will see that it works as expected 🙂

If I understand well, you want to have a bar above the header with the site title tag and the call now to get your beans right?

Thanks,

Correct. That's the idea at least 🙂 A header bar above the regular header, which wasn't going to scroll along if I set the header itself to sticky, which I then could use to present useful elements while still retaining structured data support.

I think it is possible, I just have make damn sure that repositioning does not lead to related schema markup ending outside of the schema type declaration, so to speak.

I mean, I can create a header bar (not scrolling along) using:

add_action( 'beans_header_before_markup', 'header_bar' );

as well as (which does scroll along):

add_action( 'beans_header_prepend_markup', 'header_bar' );

And I can modify the beans_site_title_tag via hook to end up before the regular header segment.

beans_modify_action_hook( 'beans_site_title_tag', 'beans_header_prepend_markup' );

(alternative: before).

While the site_title_tag is thus displayed above, I'm not seeing how to either put it inside the header bar, or alternatively turn it into a - so to speak - row by itself for styling (and sticky control).

I think I'm approaching this not the right way, maybe I'm thinking too much in a sense of html structure - as if in my head I'm picturing it as a div structure (if that makes sense) and I can't see how to cut one nested div out to paste it above the nest - without breaking the schema.

Hi J.C.

While the site_title_tag is thus displayed above, I'm not seeing how to either put it inside the header bar, or alternatively turn it into a - so to speak - row by itself for styling (and sticky control).

If you want to move beans_site_title_tag in your custom HTML block, you would remove it the action which attaches the fragment to the page beans_remove_action( 'beans_site_title_tag' ); and then call the beans_site_title_tag() function straight into your custom HTML block.

Alternatively, you could write your custom HTML using Beans HTML API which will create markup id. Then you will be able to change the beans_site_title_tag action hook to attach it somewhere in your custom HTML.

Remember, everypart of the page is set in a fragment function which can be moved around (modifying the hook), replaced (modifying the callback) or removed (removing the action). That said it can also be called manually in your HTML by simply calling the necessary fragment function.

It is all about finding the balance, sometimes it is better to modify some markup using the Markup API and modifying actions, but for major HTML structure changes, it is sometimes necessary to write your own HTML and call the various fragment functions as you need.

Hope that makes sense,