“There are three main focuses this year: the REST API, the editor, and the customizer.
For the REST API weâre going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.
The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has âblocksâ to make it easy what today might take shortcodes, custom HTML, or âmystery meatâ embed discovery.
The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization âoutside of the boxâ of post_content, including sidebars and possibly even an entire theme.” (Matt Mullenweg, 2017-01-04)
So the new verson of WordPress has arrived. With it came a new theme: Twenty Seventeen. It’s an attempt to combine the (perhaps too) popular “one-pager” with WordPress content-managing.
The theme has many interesting features. One important addition is the .svg icon theme. These days the SVG format becomes more and more important. Twenty Seventeen may be a proof of concept here.
Of course I had to try the theme. Â The design style is “big image” or even “big video” if you dare to use that option.
The theme has improved greatly since the beginning in october 2016. The process began on Github. Here a team from Automattic co-worked with the WordPress open source community. 68 participants or more gave input and suggested code.
When the theme was ready for the core it moved to Slack. In the end it was integrated in the wordpress-core code.
In this post Helen Hou-Sandi suggests working on starter content to the new Twenty Seventeen theme. UX should be a major concern in all themes:
“While theme review guidelines need to be finalized and documented, it is anticipated that themes being submitted to WordPress.org will be expected to select from core-provided content to promote consistency and to help keep the theme review process from becoming lengthier, with exceptions being made on a case by case basis. Themes being distributed outside of WordPress.org are not subject to the same review process; however, it is recommended that consistent user experiences be the primary consideration in how starter content is chosen and implemented.” (HHS op.cit.)
Right now my research and programming go hand in hand. Saving all sources and notes in a database proved to be a very good idea. Adding new sources to the database is easy in Adminer.
Whenever new additions are made to the database, it’s a matter of seconds to compile a new bibliography file via my Python script.
Now I write, and write. Texts, notes, ideas, chapters, structures … poor out. The database is a major tool in the creative work. Quotations are made via the ID in the database. Since the value is unique there are no conflicts in the bibtex file.
In the actual texts its a matter of adding @wp_81 – or whatever the id of the relevant source may be.
All my texts are written in markdown. I can compile the texts to .pdf, .epub, .docx etc. via a Pandoc script i bash.
With this “toolbox” it’s easy to write the academic dissertation.
Right now the writing process is in a phase of “write-out”. I don’t care to finish anything. It’s like drawing a sketch on paper. But when the chapters are compiled – it turns into a report, with all the academic features: lists of content, notes, and a very precise academic bibliography.
I never thought, that writing and programming were related in this way. But it’s a fact: programming and (academic) creative writing are related.
Why don’t you save the long pandoc command lines as a bash script?
In this project I write in Markdown most of the time. I may need the same text in many formats:
.docx for the boss
.pdf for nice presentations
.tex for serious work
.epub for ebooks
.mobi for Kindle
I have chosen to write most of my texts in Markdown. Pandoc can transform Markdown to all the formats above. Except perhaps .mobi. Here you need Amazon’s kindlegen.
In order to create an Ebook and a Kindle version, you need to:
Let’s try a conversion from Markdown to an eBook. The –ebook-cover will ad a frontpage. So you’ll have an eBook with a nice cover. The –toc means Table of Content.
As you progress the pandoc commandline tends to become very long indeed. I save such lines i as a bash script. Here’s a sample:
#!/bin/bash
# Create the eBook and a Kindle version of the same
pandoc -S --epub-cover-image=owl.jpg --toc -o yourBook.epub meta.txt markdown.md
kindlegen yourBook.epub
Save the file as myFile.sh. Then run this command: chmod a+x myFile.sh. Now you can run the entire command like this:
./myFile.sh
in a terminal. As soon as your pandoc command works you can save it for future use. You could even save the script in
/usr/local/bin/
Then you can use your script as a Linux command.
I’m sure that you can do something similar in Windows or OSX. In the heyday of MS DOS I might have saved the pandoc command in a .bat file. But in the end I prefer a Linux solution.
However, the PDF support needs several dependencies:
Core support is provided through WP_Image_Editor_Imagick and requires Imagick, ImageMagick, and Ghostscript support. When not supported, or if the generation fails, WordPress falls back to previous behavior and saves the attachment without adding image previews to meta. (Quote: Mike Schroder Nov. 15th. 2016)
In 1925 the nobel prize winner and author W.B. Yeats published “A Vision”. Here he introduced the dichotomy of Primary and Antithetical. To Yeats there is an opposition between Primary and Antithetical thinking.
We could draw an analogy. Connect Primary with “Drag and drop production”, and Antithetical with “Focus on code / database”. Then you’ll get a suggestive illustration.
Now the extremes would be rare. But you could perhaps imagine a user, that does not understand any code at all. Everything is done via drag and drop. Would such a user be able to make a professional webpage. My answer is clearly: yes.
You could also imagine a user who does not care for the GUI at all. Everything is PHP or SQL to that user. Such a user could build new funcitonality on the core functions of WordPress. Writing code for the sake of code would be possible. But it’s absurd.
Most users are somewhere in between. The more you work with WordPress development, the more you’ll be dragged towards the code side.
The more you can accomplish with a content management system without having to write code, the better it is. But the human race is creative. We often seek something new.
And so the primary drag ‘n dropper depends on the coder – and vice versa.
In my research project I have seen very good multimedia productions with hardly any code. But if your vision transcends the limits of the out-of-the-box WordPress – then you need a skilled coder.
How to use the model
You can use the model in order to visualize the complexity of a WordPress task or solution. Let’s use a Child Theme as a sample:
A Child Theme will use a given theme – and elaborate on the code. The developer will have to write some code. Depending on the amount of added functionality, widgets, plugins etc. we can place the dot.
In this way we can use the original model by W.B. Yeats in order to visualize the complexity of a WordPress solution.
Another sample:Â install and use a new theme via the dashboard:
Visualize Complexity
The model is a visualization of the balance between code and user. Usability is the raison d’ĂȘtre for code.
Nick Halsey made a usability test on Twenty Seventeen. See the results here. The method seems to be observation of usage and notes during the test. Four users tested the new theme. According to the web guru Nielsen you could find around 90% of the usability errors in this way.
Multimusen.dk will set a few cookies from Doubleclick, Google and the Social Media plugins they ay set some cookies. Some of my pages use APIs - such as YouTube, LinkedIn, Google Fonts, Google Maps, Mapbox, Spotify, Jetpack, Twitter, Facebook &c.. Such plugins may set the odd cookie.