Small changes that make the difference

In these days, I’m trying to test the new Gutenberg editor on my personal website, and as part of the Gutenberg Challenge, I’m forcing myself to write something about it, at least once a week.

I’ve always thought that the variety of controls that you have at your disposal would eventually become a problem, since there’s only so much space for displaying them.

Splitting stuff in tabs, and displaying quick shortcuts before even clicking the “+” button is exactly the type of countermove to balance the aforementioned abundancy.

The general feeling that I have with this editor is quite frankly great, and for the first time in years I don’t feel the urge to go back writing the post in an editor that’s more comfortable to me, such as Sublime Text or Byword.

The only thing I don’t really see the necessity of is the Drop Cap setting, which is, in my opinion, cosmetic enough to be enforced as an option by the theme that’s currently active, rather than the editor itself.

Yay, Gutenberg!

This is the first post that I'm writing using the new shiny Gutenberg editor that someday will land in WordPress core.


I'm not sure I'll be able to keep up with the #GuntenbergChallenge, that would be trying to write and publish at least one post per week using Gutenberg, but what I can tell right now is that this editor feels like a breathe of fresh air, and a much needed step in the right direction.

We'll probably never be able to bridge the gap between what happens in the backend and the visual representation you have on the frontend, but the ability to have a more visual approach to things is always appreciated, especially with something as fundamental as a post/page content.

If you want to know more, or perhaps getting involved in the project, follow its development on GitHub.

Your code is not the end of the story

This is a quick post to remind me of something important, something that maybe is not only relevant to WordPress, but surely is magnified in that context.

Before starting my own gig, I worked for a software company. Sure, we could pick up data from external sources, but, apart from these sporadic integrations, the whole show started and ended with things that we built, things that, supposedly, we knew 100%.

When working, developing, designing with WordPress your code is never the end of the story. Whether it’s a plugin or a theme, your code will always run alongside other codes, written by other people, with various skills degrees; people you will most likely not know.

If you’re like me, you might reject this idea, even for a little while: running other people’s code can expose yours to issues, and generally impact the end product you’ve so carefully created, possibly making look bad, without you having done nothing really wrong.

Recently, we’ve fixed a couple of compatibility issues with a product we’re publishing. One of those issues, specifically, got me thinking: it was something that I never thought could be a possibility, yet it took only a couple of minutes to adapt what we wrote to that unforeseen scenario.

I’m not saying that we must expect the unexpected, rather than you need to embrace this heterogeneity as a fact, and work for it, not against it.

As with all diversities, it’ll maybe take some time to accept it, but the reward, not necessarily for you, but for the people that are going to use your product, is too big to be missed.

An alternative to file_get_contents

The official WordPress Theme Review guidelines are fairly strict in some cases, and for a good reason: those best practices, tips and rules ensure that the risk of having bad code pushed to the ever growing themes and plugins repository is kept to the minimum.

One of those rules dictates that direct file operations aren’t allowed, unless they’re performed through the Filesystem API. Due to this restriction, the use of an handy function such as file_get_contents is prohibited, and its occurrences in a theme are promptly signaled by the Theme Check plugin.

For local reads, though, there’s a way to access a file’s contents without invoking file_get_contents

$content = implode( ‘’, file( $path_to_file );

which essentially accesses the file, reads its lines into an array, whose elements are then joined in a single string.

Developing locally with a REST API

As you may know, during these days, at Evolve are building our own WordPress themes and plugins shop, in preparation for the launch of our very first independently sold product, Brix, a drag and drop page builder.

One of the things that we’ve implemented on top of a standard WooCoomerce install, is a purchase code validation system that relies on the well known WordPress REST API.

When developing this kind of things, it’s generally a good idea to have a local copy of both the server and the client, so that the latter can make calls, and the former can answer them.

Now, WordPress has a couple of neat little functions whose job is to make GET and POST calls to external services, namely wp_remote_get and wp_remote_post, and if you’re not using them to perform those tasks, by all means you should!

No matter how hard I try, one of the things that I keep forgetting every time I find myself in this situation, is that you’ll need to add a particular command in your code so that your local copy of the server can be called using said functions.

The command is nothing else than a specific filter that will sort of whitelist the local server address, otherwise unknown to the caller. It goes like this:

add_filter( 'http_request_host_is_external', '__return_true' );

After your development is done, remember to remove the line when going in production.

A note regarding importing serialized data in WordPress

The WordPress Importer hasn’t received much love lately.

It does work without any particular issue, it’s a tad slow, but in the end it doesn’t give you any particular headache, if not throwing a couple of warnings here and there if you have the WP_DEBUG constant turned on.

Luckily for us, a redux version is in the works, maintained by the fine folks at Human Made, that looks very promising.

The other day I was trying to import a couple of pages that had serialized data in one of their post metas and the Importer kept failing at adding those metas, while still being able to correctly create the pages.

This situation left me baffled for a while, so I started digging.

The reason for the Importer not being able to import serialized data was related to line endings contained in the array I was dealing with: in particular \r\n line endings had to be converted to \n in order for the importer not to fail.

I’ve written a recursive function you might want to pass your data through before actually saving your post meta, in case it might contain values with line endings, such as the ones generated by user input in a textarea:

function replace_endlines_deep( $data ) {
	if ( ! is_array( $data ) ) {
		return $data;
	}

	foreach ( $data as $k => $v ) {
		if ( is_array( $v ) ) {
			$data[$k] = replace_endlines_deep( $v );
		}
		else {
			$data[$k] = str_replace( "\r\n", "\n", $data[$k] );
		}
	}

	return $data;
}

So actually saving the data to the database would become:

// ... make sure to sanitize user input ...

$data = replace_endlines_deep( $data );

update_post_meta( $post_id, 'my_serialized_data', $data );

On sharing knowledge

A few days ago I was thinking about how I started doing what I do for a living. I think everyone has a memory of a moment that started it all.

For me it was when I first inspected a web page to discover what was hidden behind the words “page source“. I have flashes of that memory: I remember that the page I was looking at was grey, with Times New Roman text, and the classic default blue links.

I distinctly remember though the sense of wonder that I had after opening said page in the default text editor of my operative system, changing a couple of characters, saving and hitting refresh in my browser.

It was the year 1999, or something like it, and I was officially in love.

I also distinctly remember the first time I uploaded a simple HTML document to a free hosting space I had back then.

It was a time when you had to wait a few minutes before actually be connected to the Internet, and those minutes were filled with this weird sound.

The passion that I have for what I do today started because I was able, with a little initiative on my part, to try to alter something that had been written by someone else, just for the sake of seeing what would happen.

My initiative isn’t the end of the story, but merely its beginning.

I was able to change those characters in that grey looking hypertext document because HTML is an open system, and its source can be seen and analyzed by anyone.

This is exactly why WordPress renews for me that sense of wonder almost on a daily basis, and a praise should go to WordPress itself, having created a friendly community that carries on the liberties proclaimed by the GPL.

Problems and solutions aren’t solely yours, or the plugin author’s, but they’re everybody’s territory, and everyone has the possibility to add their own little brick to the wall, actively contributing to something greater.

The other day, I was thinking that we shouldn’t take this for granted. Sadly, many companies out there still defy the logic depicted above.

Some say that Open Source is a true cultural shift, even the cultural shift of our time. What I say from my late-to-the-party perspective, is that ultimately you get what you give.

I’m starting to realize now that there’s much more to get if you share your knowledge with others.

Customizing the “Enter title here” placeholder text

Today I’ve put a new item in my ideal category of “WordPress things I didn’t even know existed”, which is the ability to edit the “Enter title here” placeholder text when creating a new post or a new item in a Custom Post Type.

While there is no way of customizing such text at the moment of the creation of the Custom Post Type, there’s a neat filter that you can use to alter it, depending on the type of the post you’re creating.

It could go something like this:

add_filter( 'enter_title_here', function( $title, $post ) {
	if ( $post->post_type === 'your-post-type' ) {
		$title = __( 'Enter Company Name' );
	}

	return $title;
}, 10, 2 );

Pretty easy, right? This is also a cool way of avoiding calling “Title” what in fact could be a “Company Name” or a “Testimonial Name”.

About WordCamp Torino 2016

Some say that a WordCamp isn’t really over until you blog about it.

So here I am, writing down a few thoughts about what has been an incredible event, WordCamp Torino 2016, the first official WordPress gathering in Italy in years.

First off, a big thank you to everyone involved in the organization of the event and the volunteers: you did an amazing job and everything went so great mainly because of your passion and commitment.

I’d also like to thank the speakers, who all delivered great presentations and I’m sure inspired not only me, but also the rest of the attendees.

Last but not least the sponsors, that made all of this possible.

For those of you who are unaware of the fact, the Italian WordPress community has been kind of lost and shattered for a good while. Even if the project was still maintained greatly and supported over the years by a very active and committed group of people, a complete sense of community was sort of missing.

Still, thanks to the wise choice of having a continent-wide WordCamp, many of us Italian WordPress enthusiasts managed to first met in Leiden, at WordCamp Europe 2014, then again in Sofia a year later, then again in Seville last June.

You know, the thing that strikes me the most about WordCamps is that by attending you not only receive invaluable new notions and tons of fresh inspiration and motivation, but you also get the opportunity of actively connecting with people all around the world.

That’s exactly what happened to us: over time, we didn’t only meet and discuss and contribute to the project, but we also became great friends, true friends and at the end of the day that’s one of the biggest reasons why everyone walked off with a big smile.

Give a group of friends the appropriate amount of time and an event like WordCamp Torino can happen and I’m sure that in the end it will be regarded of the first of many more.

I think two tweets sum it up way better that I’m equipped to do:

and lastly:

Oh yeah, I do too!

WordCamp Torino 2016

For those of you that don’t know, Italy hasn’t had an official WordCamp for a few years in a row, with the last one being held in Bologna in early 2013.

In the past couple of years, the italian WordPress community has reorganized itself, with new local meetups being formed, led by reinvigorated polyglots and support teams, which now provide translations for themes, plugins, as well as WordPress core and apps, and help others over at the italian WordPress hub.

logo

This breath of fresh air led to reorganizing events as well: on April 2nd Turin will host an official WordCamp, preceded with a Contributor Day the day before.

The importance of events like this cannot be overstated, and we hope this is going to be only the first in a long list of WordPress enthusiasts gatherings in our country.

At Evolve, we have decided to help the cause micro-sponsoring the event: it’s a small contribution, of course, but with lots of these great things can be accomplished.

And, hey, there are still tickets available: if you’re around, grab one, and come say hi!