My Journey at WordCamp Europe 2017

My fellows from Pixelgrade and I attended WordCamp Europe 2017 in Paris, and I must admit it was a blast. Again. Luckily, I haven’t lost anything this year. Yaaay!

This was my first time in Paris, but visiting a vastly cultural city didn’t overcome my expectations as the event itself did. I admit that I’m not such a great fan of Paris. Instead, I truly enjoyed the beauty of WordCamp and the warm of people from 79 countries all over the world.

In this article, I want to share with you some specific thoughts about my journey: the talks that I enjoyed most, the people who changed my perspective, the WordPress mates who shared useful stuff.

Before the WordCamp

We landed in Paris pretty early (on Monday), so we had plenty of time to visit the city before WordCamp. Also, enough time to experiment some restaurants with tasty food and outstanding wines. Well done on this one, Paris!

In the first days, I was lucky enough to be invited by the Pantheon team to their enjoyable, pre-WordCamp dinner with WordPress lovers. I must admit that I wasn’t expecting for such a great gathering. In fact, I thought I would deal with a bunch of people talking business, advertising or everything in between.

Well, I was quite impressed to see that people came just came to enjoy a dinner, have a friendly chat and a good time. I’m glad that I was there, made some great connections and some bonus points for catching the first row at the photo table.

Day #1: Contributors Day

This WordCamp started with a Contributors Day and I choose the JavaScript path with no regrets.

1) The first workshop was lead by Zac Gordon in the beginnings of JavaScript Vanilla. I’m not a JS amateur anymore, but from the start of the day, I wanted to learn how the masters teach their students and sure Zac is a great source of inspiration in that sense. #teachseption is the new keyword. Code source of the workshop here.

2) And why not strike the iron while it’s hot? Adam Silverstein shared an engaging history lesson about the evolution of JavaScript within WordPress. I’ve learned that a good javascript framework doesn’t need to be cool to do its job well. On top of that, backbone.js was always that nice buddy who maintained the models and collections in a performant and consistent way. Code source of the workshop here.

Here are my two cents on this matter:

We can debate all day long about the React vs VueJS, but these frameworks are meant to create nice interfaces and render the content fast and clean. How we deliver data to those frameworks will still be a JavaScript problem, a data processing concern, and backbone.js is still damn good at data handling.

In a Workshops day, Talks are like a breath of fresh air.

3) David Aguilera made a strong point about the fact that the WordPress themes and plugins directories could use some analytics data. All the big marketplaces like Playstore or Apple Store have good analytics served by default, why not have this kind of data for our toys? After all, we just want to make them better, so we need more information to relate to.

I know that there were a few people in the room who linked with this concept, but I find this topic very interesting, and I’m sure that if we get over the privacy paranoia we can achieve even more.

4) This particular point was rephrased by John Maeda in his talk as well, along with Mark Uraine and Cate Huston. The only difference is the phrase they used: “We need to know our clients to understand their problems”. Slides are right here, (btw, this was about the REST API data), but shouldn’t be also about analytics?

Moreover, K. Adam White iterated on this matter too and highlighted the fact that good software needs relevant data and that data needs a good visualization.

Day #2: WordCamp Europe, bring it on!

1) I started my day with Alain Schlesser and his speech about the loading process in WordPress. I need to admit that I studied how WordPress loads on several occasions, but I never got it as fast as he made me do it.

2) Next, the schedule challenged me to take a tough decision: a good community talk with Caspar Hübinger or a good developer talk with Otto Kekäläinen?

I went with Otto’s talk about PHP profiling, speed, performance and lots of good tips. The slides are here and I highly encourage you to take a look over, but the speech itself is hard to equal.

3) John Maeda comes on stage and he strikes again with his overall attitude. Funny, witty, with a very inspirational talk, full of motivation and good vibes.

Overall it was a great day, I’ve met a lot of new people, re-connect with older folks and I felt the network started to grow. Thumbs up!

Day 3: time to dig deeper!

1) The second day starts with Andrew Nacin. I still remember his awesome quote: Developers solve issues too.

By now I picked my favorite talk for this episode of WordCamp. Andrew inspired and motivated me to go over my fears about decision making and concentrate on the problem solving not on the code itself.

I’m glad that he broke a piece of this paradigm in which designers are presented as the rulers of this world.

2) Improv Lessons

“Slack is great to pass an image from a computer to another, but that’s it. The real communication is face to face when you can see your partner reactions.” – Dwayne McDaniel

A delicious speech, funny and eye opening. I enjoyed it in every word even thought it means (for me personally) to get out of my comfort zone, drop the never-ending NO, and learn how to handle my conversations with my team in a better way. Resource about this talk on his blog

3) Rian Rietveld reminded me about some great Accessibility rules that I kind of forgot. She is kind enough and already made these tips public on her blog. I was lucky enough to meet her on my way home, in the metro, and had the chance to thank her for the wonderful speech.

4) Over-heap time

Before the lunch, I though I would clash or something because I really felt overwhelmed and wanted to get some distance and sleep on what I heard during the days.

It was a lot of new information to me, a bunch of new people, new names, new programming tips, so so many things to remember and I felt like I really needed a break. I detached from all the people, even from my teammates, and just watched them. Nothing to say, nothing to remark, it was just a moment of “please free some memory from RAM so I can go back to Talks.”

The short meditation moment went well, the lunch was nutritious, so I was back in business.

5) The moment of Matt’s Interview. Since are plenty of ideas and lots of feedback about it, I just want to add that I strongly agree with his vision, and I’m eager to embrace new challenges.

6) John Blackbourn roles and capabilities. Nothing fancy to talk about here, but from a technical point of view, this speech taught me that I’m not even close when we talk about roles and capabilities. I have some hooks and technics in my mind, and I feel I have a better clue about how to use them. All in all, here are the slides.

7)K. Adam White – Data Visualization with the REST API.

It couldn’t end better than this. Adam gave us such a new perspective about the RESTfull API and how we could make the most out of it. And this comes from a guy (me) who tried to give new purposes to this system since it was a beta plugin.

Au revoir, Paris

Even if Paris wasn’t as beautiful as expected, I cannot complain. Caspar wrote an article after WCEU, and he taught me with his story that empathy is a big thing, and there are people with bigger problems than how beautiful and clean is a city or not.

Before this WordCamp started, I was lucky to talk with Bridget Willard. At some point, she said that “WordCamp is about the people” and she is right for many reasons. It’s not about the place; it’s not about the code, it’s not about the products, not even about the strategies or visions. It is only about the people, their problems and the way we can learn to solve them.

Dream big and see you in Belgrade … or maybe in Iași at some point?

Add theme suggestions for plugins for real


Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 118

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 119

This article is about my thoughts on different scenarios regarding the moment when a WordPress theme adds plugins suggestions in a clear and useful way.

I think the whole WordPress community raises a strong need for a visible and clear relationship between plugins and themes. I came across situations when a theme adds a style for a certain plugin, but the same WordPress doesn’t offer a clear way to tell us “What plugins can I use with this theme?

Why should WordPress add theme suggestions for plugins?

In my opinion, this is a good topic to sleep one since the latest debate in the WordPress community regarding the moment when the Zerif theme was removed from the wordpress.org.
After a deep review, admins discovered that the theme has plugin-territory code and features which should not be set inside a theme.To be more explicit, Zerif creates some minimal content for the home-page. Thanks to Ionut Neagu for the heads up.

Let’s imagine a scenario when a theme registers a custom post type, such as a testimonial, all the content held by it depends on the theme. This behavior is completely wrong since a user will lose all the content when he takes the decision to switch to another theme. A proper solution is to register the custom post type from a plugin, but keep in mind that the theme should recommend that plugin.

This behavior is completely wrong since a user will lose all the content when he takes the decision to switch to another theme. A proper solution is to register the custom post type from a plugin, but keep in mind that the theme should recommend that plugin.

 Current solution?

Well, the WordPress community knows this issue, and maybe this is why a library called TGM Plugin Activation gained so much popularity that nowadays when you say “recommend plugins in theme” you automatically say “TGMPA.
This is the WordPress approach when something isn’t touched by the WordPress core. It will always be proposed or implemented by the open-source community via plugin / library / CLI.

Now, please don’t get me wrong. I’m not saying that TGM is not a good solution, I’m constantly using it myself, but:

  • It is not a genuine WordPress feature, and some users aren’t confident with it.
  • It is hard to keep it up to date. When a core feature has an issue it is modified with the core; this library must come with a theme update which is again, an update feature = plugin-territory.
  • It replicates a separate page, outside of the plugins list page, for plugin activation, installation, etc. Duplicating features is not a WordPress thing, always use WordPress functionality and features first, if available.
  • A personal one, it always messes with Theme Check requirements.

Let’s find a real solution and build it!

My honest desire is to take this subject to the next level of conversation and implementation as well. As you may know, the plugins and themes relationship is already a big deal in the WordPress ecosystem, but now I guess it became a true requirement.

Every guideline tells us explicitly to separate features from view, even if we talk about Codex, Envato, wordpress.org they all sing the same song: keep out functionality from view/template.

We already have a way to ask a feature from a theme.There is a function which says “Hey! This theme supports the X feature.” The function is, add_theme_support and it is present in:

  • Default Twenty themes (and others) when they call core features like Custom Logo or Custom Header Image.
  • Every WooCommerce theme like which want to declare support for this plugin must use add_theme_support( ‘woocommerce‘ ).
  • Soil plugin where they ask modules with this function.

Here’s the place where I recommend to dig deeper. This functionality can help us see which plugins can work nicely with the active theme, and which not. Maybe something like this could make the trick:

I don’t say this is the best way to implement the “asking.” A better solution could be a separate function like “add_recommended_plugin” or something else, I’m just theorizing here (or playing with the trial-and-error approach).

However, in my humble opinion, a list of plugins supported by the active theme is mandatory.

theme-suggestions-list

Also, the brand new Shiny Updates V3 should bring a great user experience while adding plugins suggested by theme.

theme-suggestions-add

Still, what I say is pure theory. But hey! Hopefully, I will have the guts to open a track ticket on this subject.

 

Automated Testing, what can they bring

Please let me set your expectations from scratch. I really want to highlight the fact that I’m NOT an Automated Testing Guru, neither a testing-driven developer. I wrote a few tests in my “coding” life, and half of them I’ve already deleted because I’m way too embarrassed to showcase them. However, I see the added value they bring, and honestly, I want to pitch my colleagues at PixelGrade that we should take advantage of automatic tests. We want to deliver flawless WordPress products from top to toe.

Now I’m going to cover the general idea, a specific terminology (which, btw, I find it important), and some thoughts about the automatic tests before using them.
tddSteps

Test-driven development – TDD

It’s a methodology which promotes the development in very short cycles and creates a test case for each one.

Basically, it requires you to write tests first, make sure they fail, and after that, code and refactor until they pass.

It is also the methodology which inspired Acceptance Test-Driven Development – ATDD and Behaviour Driven Development –BDD

Unit testing

It’s a software testing method which breaks the software in tiny pieces (units) which can be tested individually.

It’s also the mechanism that stands behind some methodologies extreme programming or …

Regressing Tests &

A method which is testing software, already released, that still performs correctly after getting some changes (new features of bug fixes).

Continuous Integration &

It can be narrowed to tools (like Travis, CircleCI or GitLab) that help us run automated builds and test in order to be able to quickly deliver a product version suitable for release.

Until recently we had an integration with Travis for our themes, but it didn’t make too much fuss. Just checking the PHP syntax to be correct until the 5.2.4 version. Personally, I think it is a time saver since it notifies us whenever we broke syntax and miss it (believe me it is happening twice per month). The struggles avoided by our products are significant, and this is far more important than some extra spare hours.

[hr align=”center” size=”double” style=”striped”]

Presumption – Testing is slow!

I always thought that if I’m going to write code and also ensure tests, it will slow me down. It will definitely slow your rhythm because the methodology slows you down, the tests will run slowly, everything is like a tortoise in this process. Well, at least the product quality should catch some speed.

I’m gonna bust this myth and prove you with data tha … no I won’t .. to process is still slow, but there must be a reason why programmers are building software with testable code since ages:

People are still using them, actually since 1976, I’m not sure if my mom was born at that time. Nowadays they are already a requirement because they’ve added a layer of quality to work.

[hr align=”center” size=”double” weight=”thick” style=”striped”]

If a factory is building car pieces with robots, those robots have work limits and sensors to prevent Mr. Terminator shooting with lasers into employees to revenge his race –– the same is with QA tests.

This is our case, we need to test at any time the fact that our products are working between our acceptance limits.

Did I mention Agile somewhere above, why?

Q: Wasn’t that about delivering a Minimum viable product fast? The testing process is getting us slow in development it’s far away from being Agile, right?

CpJlZzLUkAEQ_7i

A: Well yeah, the lethargy won’t disappear, but if you take a look over the Agile Glossary you will see lots of references to testing technics. Why is that?

Because Agile is not about delivering fast a broken product, is almost the opposite(if you except the speed) the Agile Manifesto is based on twelve principles, here are 4 of them:

  • Customer satisfaction by early and continuous delivery of valuable software
  • Sustainable development, able to maintain a constant pace
  • Continuous attention to technical excellence and good design
  • Working software is delivered frequently (weeks rather than months)

I’ve changed the order for my needs, but how can you provide all these without a strong testing environment and tools? You need to frequently deliver updates to improve your products, but also keep them high quality and I can bet all my money that Customer satisfaction will drop fast if you bring a feature and ruin another by mistake.

[hr align=”center” size=”double” style=”striped”]

 

Before we go on, can you tell me what kind of feeling this quote gives you?

We want to spend all our time coding. Remember, real programmers don’t write documentation.

Manifesto Elicits Cynicism

[hr align=”center”size=”double” style=”striped”]

 

This was a counter-manifesto against Agile around 2001. However, I think there is an association between the documentation and automated tests. Moreover, I think this deeply contradicts some strong programming principles like:

DRY – Don’t Repeat Yourself

The redundancy wouldn’t drop when you write a Documentation about something that is getting annoyingly repeated over and over again?

KISS – Keep It Stupid and Simple

Isn’t simple to read a Documentation and quickly start programming with those principles in mind? I know it’s hard to build a good-writtenn documentation, but it is making the process simple and smooth.

YAGNI – You Aren’t Gonna Need It

I dare to state that documentation can help you identify faster what you don’t need!

What could go wrong?

v0zetcx

 

Another risk in writing tests is that they can get redundant and boring(but what good thing in life comes without sacrifices?).

A few years ago I had a colleague apartment, also a programmer, who told me that he hates writing unit tests and this GIF describes him at best when he does this boring task.

post-21623-Writing-unit-tests-gif-DevOps-pUPY
Like seriously … this is for real

Benefits for automated testing

As a product, I think that the benefits are already clear. The quality assurance adds a great layer of a product, it puts a motorcycle leather on a software which makes it look so badass.

When we talk about a team, I’ll risk my nuts and say that everybody should benefit from automated tests:

  • Developers – they should be less stressed if there is another testing entity(sometimes a better one) aside their own and escape from the Impostor Syndrome
  • Designers – Every designer has some acceptance limits for every project, wouldn’t help them to know that further development won’t break those limits? Or at least to accept that tests will fail when this happens.
  • Custom Service Heros – Who else encounters most of the problems of a product? They are also the happiest ones when an automated tool prevents the same problem going into production and producing tickets again.
  • Marketing and Copywriting –Automated testing should help us keeping our promises to our clients. Isn’t this a good thing to brag about and a strong trigger to keep happy clients on board?

[hr align=”center” size=”double” weight=”thick” style=”striped”]

Let’s get practical

[hr align=”center” size=”double” weight=”thick” style=”striped”]

WordPress tests

WordPress core team is promoting the use of PHPUnit tests and QUnit and now they are also a requirement when contributing You can always take a look at the trunk WordPress from SVN

In my opinion, they lack Behat so it could be a little user-friendly … but if I can really dare to dream … imagine combining them with a  Speech Recognition Software.

Visual regression tests like Wraith or Gemini

These kinds of tests fall in the End2End methodology area which endorses the product testing in a real environment(not just a terminal or a PHP request). In web development, this means we have to emulate a browser and make the automated system trigger some actions like authentification add a comment or even buy a product.

A good practical example can be the guide made by Kate Kligman @ Pantheon

Another good and powerful example can be gemini

Nightwatch

Another End2End tester is NightWatch – and you can see this tutorial a little piece about what it can do.

And above all … the tests should be Continuously Integrated

Don’t forget about CI! All the test you are doing they should be able to be executed on tools like Travis or GitLab. They are time savers when they are building tests exactly in the moment that you commit a change.

The end

That’s it for now, let’s hope I can talk about this subject in the future articles,

Chears!

1Click update language pot files with phpStorm

result

Let me provide you a short context about this article’s purpose. In few words, what I’d like to do is to walk-you-through the process of updating language post files in faster and automated way. But hey! not fully automated, ok? You will need to click some buttons, but that’s a piece of cake.

For Sublime fans – quick end: In case you are not using phpStorm, but you still want to update the language files faster, I highly recommend you a grunt module called grunt-wp-i18n. I assume it’s easier to run a grunt command in the terminal than updating the from source files manually.

How it all started?

For me, this idea came into my mind while reading Otto’s comment on this specific topic. There is a wide range of solutions to create a .pot file, but Otto’s answer uses a tool which is bullet proof in the WordPress community aka respecting some high standards. So why not use it? Well, maybe because it’s pretty hard and annoying to repeat all those commands every time you change the syntax in your theme or plugin.

Smarter is simpler

I’m using phpStorm, and this IDE has a bunch of tools to help developers. One of them is Task Manager, which has various types of configurable default tasks. By the way—if you can’t find a task that you need, then I’m pretty sure that somewhere in the digital world there is a plugin for that. On top of that, you can easily check my article about running Gulp Tasks from IDE. The tool is powerful, and it can help you cut tons of redundant, and time-consuming tasks.

First of all, we need to BashSupport plugin for phpStorm. This will provide all we need (aside phpStorm) to automate Otto’s suggestions. So go in phpStorm preferences, Look for Plugins, Hit the Browse Repositories button and then search for BashSupport plugin to install.

To quickly brief you about my WordPress installation setup, I must say I use pressmatic.io, which influences my folders structure but it’s very helpful in order to keep me organized. Beside what pressmatic.io gives me (WordPress installation, configs, and logs) I also get the WordPress SVN Trunk version because it contains all the grunt and internalization tools. It’s always good to have them, right?

my_setup

The makepot.php file is actually all we need to use. This can by executed with PHP and it takes commands like:

  • wp-theme – creates a pot file for a theme
  • wp-plugin – creates a pot file for a plugin
  • The file has other commands for WordPress internalization like admin area, time zones, glotpress, wordpress.org but this is out of our topic.

This should be your Create Theme pot task:

create_theme_pot

Hot points above:

  • The Name is free to edit
  • The Script can be wp-theme or wp-plugin
  • Interpreter path: This needs to be the path to your local PHP. If you don’t how to manage it, just run the which PHP command in your terminal and you will find out (or take a closer look at a phpinfo() page);
  • Program arguments: Contains the path to your theme / plugin and the name of the pot file.
  • Working directory: Remember about the makepot.php file? The working directory must be the way to that file.

If now you’d like to have your “Create” task set, you can run it for a test. You may observe that the script is creating a file near makepot.php, called as your required in your second program arguments.

Cool, now we have the file! Big thanks! But wait, the magic deal was about 1click automatisation, right? The job is ready when the pot file is in the right place.

Create a task which moves the pot file

We can create a task that moves the theme.pot file from his birthplace into our theme or plugin. This is what I usually use:

move_pot_file

  • Name – Free to change
  • Script  The file destination path. I know it doesn’t sound intuitive, but the Script is an argument to the Interpreter.
  • Interpreter path – We need a terminal command to move the file. On Mac OSX and Linux I use mv. Windows fans should see this.
  • Interpreter options – The only option we need is the new file name.
  • Working directory – The path to the makepot.php file.
  • One Before launch command – The beauty of the phpStorm Task manager is that we can chain tasks. What I did here is to chain the Create Theme task described above.

At the end of the journey, the flow should be easy-peasy:

  1. Click On Moving Task.
  2. The Create Task will be called first and create a new .pot file.
  3. The moving Task will do the rest of the job and put the file where it belongs.

This is it, dear WordPress lovers! Feel free to hit me with a tweet or comment if you like or if you have any questions. Bonus: let me give a nice spoiler about the next article on this subject: GULP.

Custom Body Class plugin for WordPress


Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 118

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 119

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 118

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 119

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 118

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 119

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 118

Notice: A non well formed numeric value encountered in /home/nginx/domains/a.lupu.pro/public/wp-content/plugins/crayon-syntax-highlighter/crayon_formatter.class.php on line 119

WordPress custom body class plugin – What is this?!?

Yesterday I’ve created a WordPress plugin which allows you to add a custom CSS class on the HTML body tag. Obviously this works only if your theme follows standards and uses the body_class() function. Here is the basic workflow:

1) First you add your custom class in the right sidebar of the edit page, like this:

add my awesome class

2) Once you’ve done this, and saved your post, you should already have your unique class on your <body> tag. So when you hit “View Post” and inspect the page you should see it like this:

body_class_result

Now this isn’t such a big thing (you can probably do this with some custom code, but … why bother?), but I find it very useful since you can customize any post, page or custom post type item as you wish. Now you can choose which of your posts should be awesome by adding some custom CSS style in your theme’s style.css file or you can use our Customify plugin which allows you to add and edit custom CSS, with live preview, directly in your Customizer panel.

A simple test?

Well even if you didn’t notice this, the article you read is the living proof because I really added the .my_awesome_class to this article and in Customify there is a CSS snippet which adds a small border to all the images in this article:

This is the only article on my website with bordered images, but who knows, maybe in the future I may need this class on other articles.

More features

For now this plugin lacks in extensive features, but you can enable / disable the visibility of the plugin’s metabox or select what post types should have this feature.

Screen Shot 2015-07-28 at 10.48.10 AM

I plan to improve this plugin and also add options for categories, terms or taxonomies. Who knows maybe some custom rules or global ones, it depends if they are really needed.

But Why?

Why did I decide to create such a simple plugin? Firstly, I find it very useful, there wasn’t one on the market, but this is the actual use case that motivated me to create it:

While developing WordPress themes and plugins often our clients come and ask us for help with customization for their websites. I noticed that most of them ask things like “I would like that one of my pages to have black borders” or “I would like to hide the featured image on one of my article’s page” and is fairly simple for us to serve them a CSS snippet like

And this was enough! They were happy and we were happy to help them, but there was a redundant thing when they came back and ask us to add this feature to another post, now the CSS selector gets long and ugly, we needed another solution.

Also while editing a WordPress post or page, did you ever found yourself in the need of doing something unique only with the current post? I personally did, I imagine that if you are familiar with CSS you surely did add this kind of code in your style.css file

Then you were happy with that outcome and in your next article you think “Hey let’s do the same with this one” and turn your CSS selector in something like this:

In the end, you need to admit that this is ugly and it could get worse.

Enough, go and play with it.

To sum it all up, you can use this plugin only if you like to play with small CSS edits and you need to add them only on some posts or pages. I hope you find it useful, and, if that is the case, let me know your thoughts on it (some reviews would also be nice 🙂 ).