How we tackle gutenberg


Some remarks about the talk:

  • What I didn’t mention about meta blocks: I’m not sure if there will be an actual block type called „meta block“ or if we’ll do that with dynamic blocks that will for example just show a Editor-UI block with settings that are saved gutenberg-style or classic-post-meta style but aren’t representing themselves with HTML in the frontend.
  • A very important setting that doesn’t seem to exist yet, are „templates“ or „required“ blocks to make it possible for a certain type to always have certain blocks already available. This would be great (no, required!) for (meta) settings blocks. Also, if a post type has no content, gutenberg should only allow registered settings blocks, but no content blocks, if they’re not shown anyway. We’ll see how (or if) register_post_type will be changed for that.
  • At the moment I’m working at a prototype and I realize that something like a „meta block“ doesn’t seem to exist (yet). But with lots of effort and hacks I was able to do a „meta block“ prototype that provides a text field within a block and that is being saved to post meta. I just hope there will be some APIs making that job easier – Maybe there are APIs/functions and I just didn’t find them yet. As I said: We’ll see what the future holds.
  • At the core talk after lunch I asked, how, for example, a user can set the font size (because that was a question and the answer was „yes, the user can set the font size“. I did ask that because in the current prototype of gutenberg, a lot of inline styles are used in the frontend, some of them are not even responsive. Font size in my opinion shouldn’t be settable like „11px“ by a user, but rather with different sizes like „large, medium, normal, small“ and then be added to the paragraph as classes – This makes it possible for theme developers to define what sizes are possible within the theme and different screens. Setting a font size by px, pt, em or rem is, in my opinion a thing of the past and nothing an average user should be able to define. Same with font colors. I didn’t dive deep into those parts of gutenberg as I’m pretty confident that we won’t make a step back there (inline styles would be a *huge* step back in my opinion).

Overall architecture of gutenberg

I didn’t talk too much about the actual underlying architecture of gutenberg – on purpose. I was and still am not sure if the architecture of mixing structured and renderable data in one database field, while using a syntax that is beta-ish, is a good idea. I know that this won’t be changed anymore at this point – We’ll have to live with that and hope that Core handles it well. Nevertheless, the goal of my talk was to take away some „fears“ of developers, freelancers and agencys that a) metaboxes may not be backwards compatible (they will be!) or b) things like metaboxes for settings are a thing of the past (They’re not, blocks like that will still be possible *and* the right post sidebar still exists for narrow type meta boxes).

After all, we still have to wait a little to see the picture. I’m looking forward to the first WordPress 5.0 alpha or beta, where gutenberg is fully integrated and we’ll see the full scope of possiblitites in regards of compatibility and APIs.

Adopt a WordPress made by someone else

It was over a year ago when I was that nervous the last time. I had the honor to talk about things that can go wrong when overtaking support, change management and/or hosting for a WordPress installation that you didn’t do yourself. We’ve been asked to do than quite a lot now. Also, I had the chance to participate in the panel with other swiss agencies. So after Noel and I were finally able to plug-in the VGA by force, I told the audience how much things can go wrong. Heh.

So first things first: When I first practiced my speech, I was talking to myself for about an hour. Because it’s a very interesting topic, and there are so many examples, what can go wrong (or at least what unexpected stuff can happen). Of course, it greatly depends on the type of website, size and what you’re going to do for your client, but most of those questions can prevent bad things from happening.

Now, here’s the actual presentation (and here’s the slideshare version if it). It’s a link to the google presentation, which has comments enabled. Feel free to ask questions or add information to the list. And: I needed to remove the sweet pug, since I’m not sure if this image if available for free use.

But now, let me add a few more thoughts and examples:

  1. „Is there a documentation?“
    This can be very helpful to understand what features the website has, how the code works etc. Any kind of documentation might help you.
  2. „Does the customer make changes on his own?“
    I think I stated that clearly enough. If you’re a developer and you don’t do content editing, consider subcontracting that task. Or keep the hands of that project.
  3. „How did you test your software?“
    Once again: If you’re asking a developer, ask it that way. If you’d ask me if I tested, I’d beat yo‘ ass.
  4. „How much traffic does the site have?“
    Depending on how you host, this might be a good thing to ask, even if the customer has frontend caching plugins enabled. If you’re hosting with a 5$ company, there might be a slight difference in running a „1’000 visits per day“ or a „1’000’000 visits per day“-website. Also very interesting: Look at the logs if possible. We’ve once had an installation that was bruteforced nearly 24/7, resultung in a few million requests per day. 99.9% was blocked, though it used up a lot of traffic and cpu resources.
  5. „Where and how is it installed?“, „Is there a test/deployment system?“
    Normally, you won’t face any difficulties here. But there are some managed hosters, where it’s not so easy do deploy changes to the website. At least, with bigger websites you’ll often see git/github deployments or even more sophisticated tools in use. If you don’t know those tools: Learn how to use them, or keep your hands off.
  6. „Are there paid plugins / license keys?“
    Just so you don’t have to start a war with the previous developer/agency/freelancer. Ask this, and count the license costs to your budget, if you have to buy them again.
  7. „Closed source plugins?“
    Now that is a complicated one and I didn’t say anything about that in my talk. The reason: It’s a very rare occasion. Believe me when I tell you, that there are (especially) agencies developing their own frameworks as plugins, but they’d tell you it’s „closed source“ once you want to move. So probably you have to do everything new, because the theme doesn’t work without that framework plugin. Now you’d say: A plugin within WordPress can’t be closed source, since … uh, GPL. Well. You’re not wrong, but the developer’s an…nevermind. GPL or not, they possibly can (and would) still go to court, which can cost a lot more (time and money) than an all new website.
  8. „Take a look at the code (and install locally)“
    Even though this will take some time, it’s always a good thing to analyze the code you’re going to have to maintain for the next 3 – 5 years. And always keep in mind to add some „bugfixing“ budget upfront. You’ll almost always need that.
  9. „How is the compatibility?“
    What I meant here is basically how the theme is developed. Did the developer correctly use filters and actions or are there more complex things, like an override of the gallery shortcode, nav menu walkers, which may break after core updates. Good thing is: Since WordPress has very solid backwards compatibility, sometimes even the worst things won’t fail after a core update.
  10. „PHP / Frontend Frameworks?“
    This is mostly about frontend frameworks, like SASS, Compass, Grunt, Gulp etc. if the theme or plugins are set up to only be editable with a correct installation of those frameworks, make sure to know them. Else, you might not be able to minify JS or compile SCSS files. I have like 5 VMs covering all sort’s of frameworks – Some of them even need different versions of ruby (and gems), so even with RVM it’s next to impossible to get different setups running on one machine.
Von Florian Ziegler

Opensource Agencies Panel – Bild von Florian Ziegler

Zeiterfassung mit Smallinvoice

smallinvoice-logoNach vier Jahren mit Salesforce weiss ich: Zeiterfassung kann ein mühsamer Zeitvertrieb sein. Oh, Zeitvertrieb? Nicht gut, wenn man es so nennen muss. Bei der comotive GmbH werden wir Smallinvoice einsetzen, ein fantastisch einfaches, schnelles und günstiges Tool um Kunden, Rechnungen und Projekte zu verwalten. Mit einem Klick kann man sogar Briefe & Rechnungen per Post verschicken. Die Zeiterfassung von Smallinvoice ist  ganz klar effizienter als bei Salesforce. Aber wir dachten uns: Da geht noch mehr. Dank der API von Smallinvoice konnten wir unsere Ideen umsetzen.

Wir arbeiten schnell mal an verschiedenen Projekten. Interne Entwicklungen, Kundenprojekte oder Support. Wenn man für jeden Zeiteintrag ein Formular ausfüllen muss kann das schnell zeitraubend und mühsam werden. In Salesforce ist dies genau wie in Smallinvoice leider der Fall. Abgesehen von Fakt, dass Smallinvoice die Daten schnell speichert, was die Zeiterfassung deutlich angenehmer gestaltet. Daher wollten wir ein Tool schaffen, in dem man seine aktuellen Projekte wählt und mit möglichst wenigen Eingaben Zeit erfassen oder per Stopuhr aufnehmen kann. Weiterlesen…

Sideprojects: Tales of Tyora

Tales of Tyora Wie angekündigt. Das Buch wird veröffentlicht. Allerdings nicht auf Papier im Einband – Das würde ein kleines Vermögen kosten. Sondern als Webseite. Ich habe dafür auf die Schnelle ein WordPress Theme gebaut, welches diesen Fall simpel und einfach abdecken soll.

Ein kleiner Einstieg in die Geschichte des Buches: Die Welt im Königreich Denoir ist in Ordnung. Fast niemand ist arbeitslos, keiner muss hungern. Die Stadt wird jedoch zu ihrem 530. Geburtstagsfest von einer dunklen Macht heimgesucht. Für den jungen Wildhüter Jay beginnt ein Abenteuer. Zusammen mit Adelbert Rechsteiner und Prinzessin Anett begibt er sich auf einen langen Weg um dem Bösen Einhalt zu gebieten. Auf ihrem Weg lernen sie neue Gefährten kennen und entdeckten die fantastische Welt von Tyora. Weiterlesen…

Managing the stepchallenge-challenge

Stepchallenge Wunderlist Einige kennen mich als Wunderlist-EvangeLIST (haha). Mit fast 40 aktiven Listen, derzeit rund 90 Tasks und mehreren tausend erledigten Aufgaben gehöre ich sicher zu denen, welche einen gewissen Platz in der Wunderlist-Datenbank beanspruchen.

Deshalb und wegen der zusätzlichen Features bin ich auch seit einiger Zeit Pro User. Wunderlist nutze ich primär geschäftlich bei Blogwerk und bisher eher sekundär für einige kleine Sideprojects. Mit kam erstmals ein „etwas“ grösseres Projekt dazu. Jetzt wo seit Kurzem Wunderlist 3 auf dem Markt ist, wurde es Zeit, mal einen Beitrag über dieses fantastische Tool zu schreiben. Ein Erfahrungsbericht mit Tipps und Tricks. Weiterlesen…