An intense year in review

First of all, Happy New Year to all of you! I hope you all made it well to 2018. Since you probably recognized, that I haven't blogged in the past weeks, I want to give you a small review of the past year and the plans for this year.

#Project52 bilingual

In 2017, I planed to continue to blog once a week. But unlike before, I wanted to blog English first and then translate the blog post to German the other week.

For the first 11 month it worked out really well. I blogged at least once a week and created some new plugins along the way. And then came December and the question if I could do an advent calendar in two languages.

The 2017 advent calendar

You might call be crazy or too ambitious, but I started another advent calendar for the third year in a row, with no blog posts prepared beforehand. The first 9 days went really well. Somethimes I posted them a bit after midnight, but I came up with some topics to write about. But then my streak ended.

Making priorities

After all, blogging is just a hobby for me. I really enjoy sharing knowledge and get feedback on it. But there are more important things in life and this year friends and family needed me more then my readers. So after about a week of not having the time to blog, I decided to give up on blogging for the rest of the year, as writing all the missing posts would probably have burned me out.

Plans for 2018

So what are my plans for this year? With my last posts from December 10, I started a little blog series. Although the initial reason is no longer there, I think it will still be a nice little series. I do want to blog bilingual as well this year. And I again want to do an advent calendar in 2018. Maybe I succeed in preparing some blog posts before December 1 😉

If you have any topics you want have covered and you think I could write about, just let me know in the comments below. And if you also have a new years resolution and are brave enough to tell us, please leave a comment as well 🙂

I am wishing all of you all the best for 2018 and I also hope to see some of you on an upcoming WordCamp somewhere.

Getting started with SASS

This is going to be the start of a small series of blog posts. I am not spoiling too much of the end result, but it has something to do with the special seasons of the year. The idea to this series is based on the wish for a blog posts by a very good friend. And I wanted to take the chance to introduce you into SASS. So before get to the actual code, let's start with the basics.

Installing SASS

SASS is an acronym for "Syntactically Awesome Style Sheets". You could see it was "coding in CSS". To use SASS, you write code which will then be compiled into normal CSS. To compile it, you have different options.

Using the official ruby gem

SASS was originally written in ruby. So to get started with this version, you have to install ruby first. On Windows, the easiest way it to use the RubyInstaller. On Mac you might want to you Homebrew with the following command:

brew install ruby

If you are on linux, your package manager most likely has a ruby package available. I would suggest to use ruby 2.2 and newer, but an older version might also work.

To install SASS, you simply have to install the ruby gem (the SASS "package" for ruby) with the this command:

gem install ruby

Now you should be able to run the ruby command in your terminal.

Using grunt

If you are familiar with grunt, you can also install a SASS package and use this to compile your files. It comes in two flavors. One package is using ruby while the other one is using libsass, a JavaScript implementation of SASS. For the ruby package, install this package:

npm install grunt-contrib-sass --save-dev

For the libsass version, which lacks some features of the ruby variant, use this package:

npm install grunt-sass --save-dev

Using gulp

If you preferred task runner is gulp, things a very similar to the grunt setup. For the libsass version, use this package:

npm install gulp-sass --save-dev

There is also a ruby version, but I am not sure if it's still actively maintained:

npm install --save-dev gulp-ruby-sass

Compiling SASS

Once you have SASS installed, you can compile a SASS file to normal CSS with this command:

sass style.scss style.css

This example is using the alternative SCSS syntax, which is more popular, as it is quite similar to CSS. This command will compile the file only once. As you don't want to run this command after every change you've made to a file, simply run the "watcher" which will compile the SCSS file on every detected change (usually when saved):

sass --watch style.scss:style.css

For more options, take a look a the official documentation.

Conclusion

You should now be able to use SASS to improve your CSS development process. In the next blog post I will show you how to integrate SASS into PhpStorm, an IDE many developers are using nowadays.

Correct quotes in WordPress

Different languages use different quotation marks. In English, is usually looks like this: “…”. In Germany it looks like this: „…“. And in French they use other symbols: « … ».

Correct typography is not always easy to get, especially when you can't type those symbols using your keyboard (even with the correct language set up). But where is a way to help you, at least in blockquotes.

CSS for quotes

You can define some CSS which would automatically put the correct quotes on a q element (usually inside of a blockquote element). There is a default to that property implemented in the browser. Just add this:

 q { quotes: "\00ab" "\00bb" "\2039" "\203A"; }

This example defines the two variants of French quotes (as quotes can have "inner quotes" as well).

Using the HTML element

But there is an easier way. Just don't define anything specifically and let the browser handle the correct quoting. All you have to do is to set the correct lang attribute on the document.

<html lang="fr">
    ...

</html>

Now you can just use a q element and the quotation marks will match the defined language.

Fixing quotes in WordPress

WordPress is adding the lang attribute to the HTML tag, but unfotunately it is using the "four digit local", so instead of "fr" it is using "fr-FR" which will break the quoting for most browser. That's why I have written a small plugin to fix that.

This blog is now ad-free

As of today, I have removed all ads from this blog. I've used Google AdSense almost since the beginning of this blog. I have also experimented with some other advertisements and until today I had two banners to the affiliate program of my web hoster (clearly noticable as ads) on my blog.

Why I put ads on this blog

Running a self hosted blog comes not for free. The costs for hosting and domains increased over time, as more performance was needed and more websites were run on this single web server. I tried to cover some of these costs putting ads on my website. In the first years, I probably only got around 15% from costs back.

Why I removed all ads

In yesterdays blog post I wrote down my feelings about affiliate links in support forums and groups. I really don't like this. I also don't like websites which are full of ads, expecially within the content. That's why I tried to put them in places where they don't distract too much.

But with ads comes also a lot of overhead. I just check my blog before I removed the ads and it had around 70 requests from 19 different domains and weight around 1MB. After removing the ads, it only has 30 requests from 9 different domains and weighs aroud 640KB.

But not only the size was one of the reasons I planed to remove the ads. The privacy of my visitors is important to me as well as the security, as ads can be exploited.

How will I finance my blog

Last year I was able to cover all costs through Google Ads (43%) and the second monetarization: VG Wort. This is the german "collecting society" for authors (57%). Now that I drop one of them, I have to cover the costs in other ways. As I host the websites of some friends on my server, I can divide the costs a bit.

How do you finance your blog or website?

What do you do to cover the costs of your personal website? Do you also use some form of advertisements or affiliate programs? Do you use crowd funding plattforms or similar things? For me, only VG Wort and my wishlist will be left for the moment.

Selfish WordPress support

I love the WordPress community. They are wonderful people and I enjoy it very much to attend as many WordCamps in new cities/countries as I can to meet even more new members of the global community.

That also the reason I really like to give support in various ways. I organize WordCamps and meetups, I contribute to different Meta teams and I answer questions in some Facebook groups.

Helping others … or rather yourself?

As the holiday season is near, many companies offering WordPress related products and services offer some great deals. But just today I had another negative incident in a Facebook group. A member was posting a special deal on a well-known premium theme. This is great, right? Anyone will make a good deal. Not really. The one persons that benefits the most is the one who posted the link. Because it turns out that it was an affiliate link.

Stop selfish help!

Maybe I am too altruistic. But I really get angry when someone is just "helping" others to benefit from that help. I have no problem with freelancers and agencies offering help and being paid for that, if they deliever a real value for an individual problem. But posting affiliate links in Facebook groups just isn't right in my opinion.

Your thoughts?

What do you think? Are you also annoyed by this type of help? Or am I just overreacting on this topic?

Gutenberg test

On my way to WordCamp Cologne, I tested the new Gutenberg editor for the first time. As I didn't just wanted to type some random text, I wrote a small blog post about how I just use the editor and what experiences I have while using it.

The blog post was written in German and I am not quite sure if I should just translate it. Why don't you head over to my German site and check it out?

At WordCamp US last weekend there was a live demo of Gutenberg in the "State of the Word" and I realized how few functions I am currently using.

So to get more familiar with Gutenberg I installed him on this blog and I will try to write my new blog posts with him.

Insert shortcodes into sidebar widgets

Shortcode can be very useful, when you want to insert dynamic content into a static page or a post. WordPress is offering some internal shortcodes such as the

shortcode (which is usually rendered in the backend). By default, shortcodes can only be used in the main content of a page or a post.

Insert shortcodes using the Text or HTML widget?

One might think, that you can simply use the Text or the HTML widget. This is possible for some shortcodes, but many of them will not work. The gallery shortcode fails on both and the syntax highlighting shortcode produces incorrect code or fails completely.

The Shortcode Widget plugin

As usually always with such issues, someone else already had the same problem and found a solution. The plugin Shortcode Widget was written just for that one task. When you install and active it, you will find a new widget, quite similar to the old text widget, with only a title and a textarea. In this textarea you can paste ans shortcode you want to use in any of the widget areas.

How to handle closed plugins from the directory

I am pretty sure that everyone of you is using plugins from the official directory. All of those plugins are reviewed before they went live and if they haven’t been updated in the last two years, you can’t find them anymore using the search (but you cann still download them, if you know the direct link). But have you ever wondered, what happens, when a plugin is being closed and removed from the directory, for whatever reason?

A potential security issue

Currently, plugins can be closed and/or remove for different reasons. The current reasons are the following:

  • Security Issue
  • Author Request
  • Guideline Violation
  • Licensing/Trademark violations
  • Merged into Core

Two of my own plugins are likely to be closed in the near future, because their functionality is either already merged into core or will be with one of the next releases. So in this case, it might not hurt to keep them, unless they don’t conflict with the core functionality. But what about plugins that have been closed for security issues. This can be a real issue.

No notification to the users

When a plugin is closed, any user who has it still installed (and maybe active) will not be nofitied about this. Even if the plugin’s author found a way to fix a potential security, no user will get this new fixed version, because the only way to update the plugin for this plugin is through the official plugin directory. In the meantime, any site using the old version can potentially be hacked.

A plugin for the rescue

This problem has been around for a while. And as the plugin team was unable to come up with a quick solution, the plugin No Longer in Directory has been published. When you install the plugin and browse to it’s settings page, you will see a list of all plugins that haven’t been updated for two or more years or have not been found in the plugin directory at all.

But this second list would also show plugins that have never even been in the directory. Especially premium plugins or custom plugins written specifically for a client project. So this solution is also not ideal.

A new way to highlight closed plugins

Through the “Ideas” section on WordPress.org, the issue was discussed for quite a while. On yesterday WordCamp US Contributor Day, the meta and plugin team annonuced, that they have worked hard on a solution to that problem. They have posted some mockups in the main ticket and there is also a first version of a plugins page for a closed plugin. Before that, the link to a closed plugin would result in a 404, with no information that there once was a plugin and why it has been closed/removed.

Conclusion

Handling the closing and removal of plugins in a transparent way is very important to not risk the website security of WordPress users, as those plugins can easily be used to attack a website. I am not sure if a forced removal or additional warnings in the dashboard would be necessary, but I hope the finally this issue will get some more attention.

Enable multisite admins to add custom CSS

This blog runs on a multisite, so I can easily translate all my blost posts using MultilingualPress. Another website on this multisite installation is the website for WP Meetup Berlin. On this site, another user has the admin role. With this role you can usually do most of the things an admin on a single site can do. With some exceptions:

  • Updating core, plugins, themes, etc.
  • Adding sites
  • Adding new users
  • Installing plugins
  • Installing themes
  • Using the plugin/theme editor (which you should never do anyways)
  • Use unfiltered HTML
  • Use the custom CSS option in the customizer

This last exceptions really surprised me. I always thought that this would be the only possible option for site admins to change the design of the site (as they can’t install themes or child themes or change their files). But only superadmins have this option.

Enabling the option for site admin

Fortunately, there is a capabilty called edit_css you can simply assign to the admins. You can do this using a role management plugin such as Members or you simply install the plugin Multisite Custom CSS which is doing exactly this one thing.

Conclusion

For security reasons, it makes sense to not allow the admins of a multisite website to change the theme files. But not allowing them to edit the Custom CSS in the Customizer doesn’t make sense in my opinion. But using one of the plugins, it’s pretty easy to enable this option.

Remove the WordPress.org link in the meta widget

WordPress comes with a lot of widgets bundled in core. One of this widgets is the meta widget. When you install a fresh copy of WordPress, this widget is usually put into the main widget area. Most users remove this widget, as they don’t see any need of it. For specific websites, this widget can come in handy. It has links to register (if allowed), the login (if you are not currently logged in), a link to the RSS feed of the website as well as a link to the RSS feed of the comments of the current page or blog post:

In a Facebook Group, someone asked if it’s possible to remove the link to WordPress.org in the meta widget. Fortunately, there is a filter around this specific link. You can easily change the content of the link or you can simple remove it completely by removing an empty string. With the one of the “magic callback functions” in WordPress, this task can be done with a single line of code:

add_filter( 'widget_meta_poweredby', '__return_empty_string' );

That’s it. Now the meta widget will not show the link to WordPress.org anymore. I personally would never remove the link, but if you want to, just add this single line of code or use the small plugin in this Gist.