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.

Remove the “Private” and “Protected” prefix on blog posts

Some weeks ago on a client website, we were asked to remove the “Private: ” and “Protected: ” prefixes on a custom post type. If you don’t know what I am talking about, let me quickly explain the feature.

The visibility of a blog post

When you write a blog post, you’ll find the option “Visibility” in the “Publish” meta box. This is usually set to “Public”. The other two options are “Passwort proteced” and “Private”. When you select the first one, a blog post is only visible for logged in users with any role. The second option lets you set a single password for this blog post (this password is store plain text in the post edit screen).

Changes on the blog post titles

When you pick one of the other visibility setting, WordPress will automatically prefix the blog post title with “Proteced: ” or “Private: “, when you use the default functions such as the_title(). So when you don’t want to have the prefix, how could we remove it?

Removing the prefixes with filters

Remove the prefixes is rather easy. There the two filters private_title_format and protected_title_format to change the title of such blog posts. We use it as the following:

function remove_pp_prefix_title_format( $content ) {
    return '%s';
}
add_filter( 'private_title_format', 'remove_pp_prefix_title_format' );
add_filter( 'protected_title_format', 'remove_pp_prefix_title_format' );

Conclusion

So with these few lines, we can easily change the title for proteced and private posts. When I was asked the same questions in a Facebook group, I put this into a small plugin an published it as a Gist just to find out, that someone even had published a plugin on the official plugin directory. I hope you’ll find this useful for your own blog.

WordCamp Cologne 2017 – A BarCamp style WordCamp

 

 

Last weekend, I’ve visited WordCamp Cologne. It was my fourth WordCamp in Cologne and the second year in a row, they organized it as a BarCamp. Last year they had only one day with talks, this year it was two days.

Thursday: Pre Warm-Up Party

I took the train from Berlin to Cologne on Thursday as the Contributor Day was early on Friday. The organizer team organized a small party in a typical “Brauhaus”. Around 25 attendees showed up:

Friday: Contributor Day

The Contributor Day of WordCamp Cologne was taking place at the Microsoft Cologne offices. Microsoft not only donated the space, but they also took care of the drinks. There were around 80 signups and a good number of them showed up:

I’ve helped out in the Design and Accessibility team to work on some tickets and helping people setting up their environments and getting started.

Warm-Up Party

As many of the WordCamp attendees arrived on Friday, we had an official party in yet another Brauhaus. I would guess that around 80 people showed up:

Saturday: The first conference day

As the WordCamp Cologne was a BarCamp, it also followed the rules of a BarCamp. One of this rule is, that every attendee introduces herself/himself with name, profession and three hashtags. With more than 200 attendees present at the start, this took a while but was very interesting, as you got a good feeling on who is attending.

After the indroduction round, every attendee had the chance to “pitch” a talk. If enough hands were raised the talk was put on the schedule, which had four tracks in parallel:

A new community Wapuu

The pitch was done aroud 11am, so we had an hour to prepare for the talks. But before that, the organizing team had one more thing to announce. In May, one of our valuable community members got his very own Wapuu. At WordCamp Cologne, the second Wapuu was presented. And it was the Wapuu for the new community member of the year, Carole:

Start of the sessions

I will not go into details on each of the many very good sessions. But as you might have guessed, I couldn’t resist to pitch some sessions as well. On the first day in the first slot, I gave a talk on how to set up a local dev environment using Docker:

Awesome swag

Any WordCamp attendee knows, that you usually get a T-Shirt. But this year, they had something extra for each attendee: fan scarfs!

Community party

After day one, there was yet another party, this time with all attendees. The organizers found a nice restaurant/bar with a small dance floor in the basement. And there we found some more swag 🙂

Sunday: The second conference day

Just as on the first say, we had another pitch for the sessoins. But we skipped the introduction round 🙂

Two more sessions for me

I pitched with my second talk in which I gave a short introduction into plugin development. In the afternoon I joined some other members of the Pluginkollektiv to present our work. We also found some new contributors for the project, which was amazing!

The  biggest WordPress BarCamp

WordCamp Cologne was more than twice the size of last year, not only in the number of attendees but also in days with talks. I think that most attendees really liked the concept. I had a very good time myself.

Upcoming German WordCamps

At the end of the day, two upcoming WordCamps where announced. In May, we will meet for WordCamp Retreat Soltau. The ticket sale has just started. While Soltau was already presented at WordCamp Berlin earlier this year, another WordCamp was announced. In March, there will be a WordCamp in Würzburg and it will most likely also be a WordCamp in a BarCamp style. There is not fixed date yet, but if you are interrested, make sure to subscribe to the newsletter on the website.

Conclusion

I really enjoyed my fourth WordCamp in Cologne and I like the BarCamp style very much. It would be nice to see WordCamps in other countries with a similar concept. The other BarCamp style WordCamp I have visited so far was WordCamp Europe last year, which had a BarCamp slot (out of three slots) on the second day only.