Parenthood – The journey begins


Parenthood is a never-ending journey and every day is a new adventure into making mistakes while trying to keep some sanity. Parenthood has no rules, guidelines or even a reference guide but it is still a great thing to be a part of. I entered upon this journey on June 7. Okay not entirely but that was the day my little boy, Salvador, was born so I will count that as the actual day the journey began. I will add more and more pages as time goes on and I get time to share these little life lessons.

Parenthood and the rules

Really there have been no rules for either one of us since SJ was born. SJ because his middle name of course begins with a “J” and if you were to look at my little man you would say that is a big name for a little guy. Now I’m just getting a little off track. The things that both of us have learned are things that people often tell us. A good example is when people tell us that we won’t be getting any sleep. I’m used to not sleeping so that is not really new to me. My body has been so REM deprived over the last years that I am more than capable of functioning on three or four hours of sleep a day. The one thing that has changed about that is that the so-called sleep pattern is more random that ever.

Parenthood and the guidelines

Okay the basic guidelines are pretty simple when you get down to it: Don’t kill the baby. That is the basic guideline and the one thing to really follow. Everyday is an exploration into a world of how to. How to keep the little one entertained while keeping your sanity, how to keep him quiet long enough to make a bottle so he won’t scream your ears off. No one thing will work the same way the next day. That is one thing you can count on to be true. There are moments when you will want to be alone to think, read or do something so simple as taking a shower but it can feel like forever because you are changing, feeding, burping and then changing again just to keep your little one from bawling.

What can oftentimes make things easy is having somebody there to help out to accomplish those basic everyday tasks like doing laundry, eating, cooking, cleaning or taking a bath. Unfortunately, I know some people out there don’t often have that luxury and I often wonder about how they manage to do it and have a huge amount of respect for them for being able to pull it off.

Week Eight

Okay, sort of back on track with this thing. For the most part. This week I really tried hard to do all things in the command line. I did learn how to go to a specific line but still have to look it up from time to time. I at least remember how to exit the editor both by saving changes and not saving changes. I successfully edited a file, saved those changes, staged the file, and made a commit.

The next few minutes were spent on correcting the spelling of a function check but it worked either way. I amazed myself when I checked my site and it didn't give me a white screen or an error. Needless to say I celebrated with a little dance at my desk when I saw no errors.

I am getting a bit more comfortable using core JavaScript as much as I can and of course I do have this habit of commenting it all as I write it out. The biggest reason is because I know there are several other people who will be looking at the code and it is nice to show your work, even if it is in comment form.

I'll end it with one thing. I will always dislike CSS because it can be irritating to troubleshoot browser specific things.

I'm looking at you IE.

It was a fairly good week with a few things learned along the way and this coming week I want to push myself more so I can better improve and get that muscle memory within the command line.

Week five, six, and seven

Okay, super late and just combined to make it a little easier. I hope. Been working a lot on retaining knowledge learned. Some days have been easier than others.

One thing that I have made progress on is getting more comfortable using the command line. At least when it comes to working with Git. I am understanding more and more since I am forcing myself to use the command line to stage changes, commit things and add commit messages, and just the overall process of making branches not just from a master branch but from a specific commit as well.

The next thing I'll try and work on is editing files while in the command line. I do want to use vim but may just have to resort to trying it out on a random personal project to get more familiar with it all.

There is one last thing that I do want to work on as well and that is my reading. I need to pick up a book or two on computer science because it is neat to learn about those things and maybe another book on JavaScript. I do still need to finish reading Eloquent JavaScript first though – I have like two more chapters left to read.

Week Four

Okay, week four and I’m still trying to use this new editor. One thing I have been noticing is the loading of the sidebar.

Some of the little modules load rather quick and some take a little longer. The one that does appear to take a little longer is the Categories & Tags. Not something most people would worry about but something I randomly noticed.

I’ve also been sort of recuperating from our WordCamp a few days ago. I will try and post a recap of that on my other, random blog since this site is more towards development and WordPress related code.

I did learn a few more things on how Media Element works which is pretty neat. It is sort of a wrapper for the audio and video HTML5 elements. I’m really hoping that browser support does improve a lot more in the coming year.

There are a few other things I learned but mostly about CSS specificity. Edge cases are super strange and selectors are weird. I’m getting more familiar with the React lifecycle and understanding a little more on how it works and when to use things. I will look into learning about using local and session storage in the coming days.

There are times when I feel like I need to expand on my knowledge of all the things but I’m come to understand and realize that I can only have so much time on a given day.

Week Three

Okay, again, late to posting.

This time it hasn’t been much but I am getting a little more familiar with the Gutenberg editor. One of the things I do like is the saving in the background. There is a small animation that happens when it does it and it is nice knowing that it is being saved.

I know there have been a few questions as well when it comes to editing a post after it has been published. It may not be super intuitive for many since you have to be on the posts list screen to see a link and it also makes sense not to have another list of the same posts in another location.

At the moment I’m not sure how I feel about using the shortcut /for auto-completion but that may only be because I don’t write on a daily basis. That is a feature I may only use once or twice, I guess.

Though the only thing that came to mind was, “why would I need to use that if I just wanted to add a paragraph? Is it just doubled up?”

If I needed another paragraph I would simply keep writing and I don’t need to use the slash, right?

As for things learned, I dove a little deeper into core WordPress and some of the bundled scripts. In particular the MediaElements library. Super cool little scripts but it
is just beginning to slowly make some sense so I can manipulate it a little better.

I also did manage to learn a little bit about using transformand some other CSS things. Kind of neat how a browser can render 3D things.


This week a little on the history of things and get ready for WordCamp Sacramento.

Week two

Yes, I know a little late to writing this one out but at least I am doing it. This last week I did manage to read up onthe document.getElementsByClassName()function a little bit and it was pretty neat. There are also a lot of other functions that I really need to read up on and practice with so I can really up my JavaScript game.

Now, there were a few things I did learn from it and the neatest thing was that it returns an array-like object. Yes, an object – because JavaScript wasn’t confusing enough without other objects.

Okay, that is beside the point but it is cool that you can manipulate a lot of the data from it. The reason I like it is that it is a step in not having to depend on third-party scripts for things like that. Having to not load up jQuery is a very good thing because it means one less script to load and one less server request. Even more so when all you need to do is get a single element with a class. For example, just the first element.

Another thing I did learn was being able to use non-ASCII URLs in WordPress is super cool but can be a little frustrating as well. A lot of it is because of the encoding that needs to happen. What is nice is the functions esc_url()and esc_url_raw()do provide for this ability. The key thing is making sure they are used when they need to be.

As for work, I’ll be – again – focusing on bug fixes. The reason is I want to learn how things can break before taking on a feature. I am looking forward to this week even though it is a short work week.

Week one

In the last week a few things happened. I worked on a few bug issues assigned to me and learned more about how the code works and does all the magic behind the scenes.

It is a good change of pace for me and am loving the fact I can help out so many at once as well.

A few things I did learn and relearn were that if you are working on something you want to make sure that you are working in the right directory. I spent about an hour editing a file, making changes, and wondering why it wasn't changing in the browser. As it turns out I was working in the wrong folder when making those changes.

Another thing I learned was it can help to keep the grunt watch task running if you are making changes to either CSS files or the developer files so they can be reflected after making those changes. Yeah, that was a fun one to remember.

Now for this coming week, I will, of course, focus on bugs and will try to get some compatibility issues.

In the following days I will also be doing my best to expand my knowledge on ES6 and ReactJS so I'll most likely be rather quiet on social media – this may be a good thing as well – unless I'm sharing a random article or video I find useful to me.

Weekend updates

I know it has been quite some time since I posted anything on here and I'm hoping to change that. The last time I posted anything was back in June and that was rather short lived as well. With Gutenberg getting frequent updates this could be a fun little thing and experiment for my weekends.

I say that only because the editor itself does have a lot of potential behind it but needs to get a little more steam from others. What I will be doing is posting an update every Sunday on how not only my week went but what I hope to accomplish for the week.

There have been several changes to my life and the biggest one is I am now working at Elegant Themes as a Junior Developer. The even more amazing thing is I'll be working, tinkering, and learning more about ReactJS since that is what the visual builder uses.

The biggest thing I am looking forward to is setting mini-goals for myself and hopefully helping in making the Gutenberg experience much better.

The biggest challenge could actually be keeping the posts to development related things.

Testing these waters

Okay, this is the second time I’m actually typing on this Gutenberg plugin and I’m not 100% sure how I feel just yet. The reason is
because I am so used to working with the previous TinyMCE editor and working with some HTML markup in order to create my posts.

I will say that I do like some of the things already laid out. Being able to add things with a click of a button is a great thing.

I know I won’t be writing an article every day so this really won’t be a huge hinderance for me. I can, however, see a good side to those who live in the editor. It may take some getting used to for some but in the long run, it will be a better experience.

A small primer on theme mods

Oh, the many things I encounter while doing reviews is amazing.

One of the reasons I love contributing to the review team is to get a better understanding of how WordPress at its core works and it is because of this I feel like there are some things that still are not being mentioned or shared.

A fairly good example of this is what I saw today. I’ve seen this on several themes but I think I finally reached a point where it really, truly irks me.

What are settings?

WordPress themes can use two things to save user inputs – or better yet theme mods. The neat part is there are two ways those can be saved. Using option or theme_mod when registering a setting in the customizer. What I want to focus on for this is the use of theme_modsince it is the recommended method for most themes. Notice I say most. There are cases where it makes sense to use option but that’s for another time. The WordPress theme mods are saved and retrieved using a few functions.

  • get_theme_mods() – gets all theme settings
  • get_theme_mod() – gets a single setting
  • set_theme_mod() saves a theme setting

Now, there are two other functions for theme mods.

  • remove_theme_mod() – remove a single theme setting
  • remove_theme_mods() – removes all theme settings

Those are least likely to be used but they are good to know.

How it works

The WordPress customizer is magic. Okay, not completely and I only say that because if you look at how things work in the JavaScript file it quite literally says, “return magic;

The way the customizer saves things is by using a few object methods. It uses the save() method, which calls the update() method, and tfinally the set_root_value() method of the Setting class. It’s here where our setting actually gets saved.

If we look over the highlighted code we can see what is actually happening.

protected function set_root_value( $value ) {
	$id_base = $this->id_data['base'];
	if ( 'option' === $this->type ) {
		$autoload = true;
		if ( isset( self::$aggregated_multidimensionals[ $this->type ][ $this->id_data['base'] ]['autoload'] ) ) {
			$autoload = self::$aggregated_multidimensionals[ $this->type ][ $this->id_data['base'] ]['autoload'];
		return update_option( $id_base, $value, $autoload );
	} elseif ( 'theme_mod' === $this->type ) {
		set_theme_mod( $id_base, $value );
		return true;
	} else {
		 * Any WP_Customize_Setting subclass implementing aggregate multidimensional
		 * will need to override this method to obtain the data from the appropriate
		 * location.
		return false;

The default setting for registering a theme option is theme_mod and what this means is that when the user clicks that save button, the function set_theme_mod() will be triggered and the setting will be saved to the database. Super cool! Now, what does that little function actually do?

Well, let’s take a look over it:

function set_theme_mod( $name, $value ) {
	$mods = get_theme_mods();
	$old_value = isset( $mods[ $name ] ) ? $mods[ $name ] : false;

	 * Filters the theme mod value on save.
	 * The dynamic portion of the hook name, `$name`, refers to the key name of
	 * the modification array. For example, 'header_textcolor', 'header_image',
	 * and so on depending on the theme options.
	 * @since 3.9.0
	 * @param string $value     The new value of the theme mod.
	 * @param string $old_value The current value of the theme mod.
	$mods[ $name ] = apply_filters( "pre_set_theme_mod_{$name}", $value, $old_value );

	$theme = get_option( 'stylesheet' );
	update_option( "theme_mods_$theme", $mods );

It gets all the theme mods, then creates a filter for us to use, gets the name of the currently active theme, and finally updates an option.

An option?

Yes. An option. I know. I know. We were talking about theme mods but the way the customizer works with theme_mods is by creating an associative array per theme. For example, if my theme were called For Real Yo, the $theme would be for-real-yo.

WordPress then turns it to a slug. So, the best way to get those options would be to get the option or use the core functions get_theme_mod() and get_theme_mods() to do things for me and because we like using good practices we use get_theme_mod() in order to get the single setting – or rather theme_mod.

You are probably wondering what get_theme_mods() does. I know I did when I first read the code.

function get_theme_mods() {
	$theme_slug = get_option( 'stylesheet' );
	$mods = get_option( "theme_mods_$theme_slug" );
	if ( false === $mods ) {
		$theme_name = get_option( 'current_theme' );
		if ( false === $theme_name )
			$theme_name = wp_get_theme()->get('Name');
		$mods = get_option( "mods_$theme_name" ); // Deprecated location.
		if ( is_admin() && false !== $mods ) {
			update_option( "theme_mods_$theme_slug", $mods );
			delete_option( "mods_$theme_name" );
	return $mods;

From the core code, we can see that it gets the theme slug, gets the option ( from the options table ) for the active theme, then it checks to see if it is populated or not, and finally returns the array of theme_mods.

So, why this post?

I am making this because the code that I stumbled across looked a little like:

 *  Default theme options
if ( ! function_exists( 'for_real_yo_default_options' ) ) :
	function for_real_yo_default_options() {
		$default_options = array(
			/* super long list of "defaults" */
		return apply_filters( 'for_real_yo_defaults', $default_options );

*  Get theme options
if ( ! function_exists( 'for_real_yo_theme_options' ) ) :

	function for_real_yo_theme_options() {

		$for_real_yo_defaults = for_real_yo_default_options();

		$for_real_yo_option_values = get_theme_mod( 'for_real_yo' );

		if ( is_array( $for_real_yo_option_values ) ) {
			return array_merge( $for_real_yo_defaults ,$for_real_yo_option_values );
		} else {
			return $for_real_yo_defaults;

Looks rather harmless, right? It is until you realize how they were registering the setting.

		'default' 			=> 'title-text',
		'sanitize_callback' => 'for_real_yo_sanitize_select'

If you can spot the issue, awesome. If not, it is creating an array for one setting of a setting. Yes, a little odd to say the least but I’ll show a quick example.

Let’s say we are comparing one of the core themes with our above code. Okay, let us look at the returned array from each one. Twenty Seventeen would yeild something like:

    [header_image] => path/to/file
    [header_image_data] => stdClass Object
            [attachment_id] => id
            [url] => path/to/file
            [thumbnail_url] => path/to/file
            [height] => 1198
            [width] => 2000

    [page_layout] => one-column
    [header_textcolor] => cfe23d
    [colorscheme] => light
    [colorscheme_hue] => 0

Now, if we look at the above example’s way of registering you can see the difference much better.

    [for_real_yo] => Array
            [some_setting] => 
            [another_setting] => 
            [top_bar_left] => menu
            [right_social] => 
            [right_hours] => 


Hopefully this does help in understanding how theme_mods are saved and retrieved and does at least help out one person.

A metabox for your layout options

It’s no surprise I can be vocal when I am reviewing a theme. Many know that I’ll spurt out what I end up seeing in a lot of themes. There is one thing that really does drive me crazy though and that is when people copy and paste code to their theme without actually knowing how the code actually works.

One file that has really been rather popular is using a metabox in order to choose the layout of the post or page. That’s great. I love that ability but then again who doesn’t love having that control? I think what drives me bonkers is that this code is super predictable before the file is opened. The file adds two actions. One to add_meta_boxes and the second to the save_post hooks. Great! Very super simplistic and hard to mess up, right?

I created a gist with the name of the theme changed. The code is the same that I’ve seen in many other themes though. From authors who have several themes in the repo to new authors to the repo.

One of the first things that you may notice is the use of two globals.

global $post, $deargodwhy_sidebar_layout;

First there should be no reason for that and second those hooks pass the $post object. We’ll look at the first one: add_meta_boxes

Using the developer resources as a guide we see that the hook for adding metaboxes uses two arguments. The post type and the post.

do_action( 'add_meta_boxes', string $post_type, WP_Post $post )

The first one being the string of the current post type and the second being the WordPress post object. Now, what’s super cool about that is that we can now register a metabox in any post type we want and it does on every post type if we don’t pay attention to what we are doing. There is also one more hook we could potentially use in order to use a metabox in only one specified post type. That hook is add_meta_boxes_{$post_type} and the developer docs does explain it a little better. For example, if you wanted to add a metabox to only your EDD downloads, you could do something like:

add_action( 'add_meta_boxes_download', 'jmc_download_extra_metaboxes', 10 );
function jmc_download_extra_metaboxes( $post ) {
	// Do our magic here.

In order to now add our metabox we do need to use the function add_meta_box() so let’s take a look at how that function is used.

add_meta_box( $id, $title, $callback, $screen = null, $context = 'advanced', $priority = 'default', $callback_args = null )

Now, if you want to take a closer look at what each one of those parameters actually does then I suggest you take a look over the developer docs. It is well worth your time if you really want to understand how to create a better user experience and understand how WordPress creates those.

Another thing I wanted to look over was the save_post callback being used. The biggest issue is the use of the foreach() loop.

foreach( $deargodwhy_sidebar_layout as $field ){  
        //Execute this saving function
        $old = get_post_meta( $post_id, 'deargodwhy_sidebar_layout', true ); 
        $new = sanitize_text_field( $_POST['deargodwhy_sidebar_layout'] );
        if ( $new && $new != $old ) {  
            update_post_meta($post_id, 'deargodwhy_sidebar_layout', $new );  
        } elseif ('' == $new && $old ) {  
            delete_post_meta( $post_id,'deargodwhy_sidebar_layout',  $old );  

The reason is it is creating an unnecessary loop. The only thing that needs to be checked is the value being input and to make sure that it is a valid option. A quick change to the code and we have:

if ( ! empty( $_POST['deargodwhy_sidebar_layout'] )
	&& in_array( $_POST['deargodwhy_sidebar_layout'], array( 'right-sidebar', 'no-sidebar' ), true )
	) {
	update_post_meta( $post_id, 'deargodwhy_sidebar_layout', $_POST['deargodwhy_sidebar_layout'] );

Knowing those things we could make changes to the file and not only will we have a better understanding of how WordPress creates metaboxes but we have a file that doesn’t pollute the $GLOBALS with info that we only use in one place. If you look at what those changes were in the diff, you will see that not a lot was changed. It only looks that way since I removed a lot of the linting errors.