Billie is a beautiful accessible WordPress theme. It can be used for any type of website, but is designed for blogs and portfolios.
The theme has two option menus, including a social menu, several different widget panels, and a footer widget are that will hold any number of widgets.
The theme is compatible with the block editor, and also includes a Call to Action button and two page sections that you can combine with your front page.
I recommend that you install the Jetpack plugin to make full use of supported features like featured content, contact forms, testimonials, social sharing and more.
To create a portfolio, install jetpack and create your projects. All the templates are already shipped with the theme.
As I am writing this, Ian has just packed the theme that will be included in Release Candidate 3 of WordPress 5.3.
This means that tonight alone, about 11 issues that we have worked on this week were closed.
I meant to write more regularly about the process, but I was not able to find the time. Both me and my partner had some health issues, and I was not able to help out with the theme as much as I wanted. This was also true for some of the people who has helped us out, so the pace slowed down a bit.
I don’t want to talk about burn out, -that’s not what I want to call it, but I think we will be happy to see the theme released, and work with the future updates a little less… intensely.
I have learnt a lot about the process of releasing a new WordPress version. This is knowledge that I wish I had when we started working on the theme.
What is a bug?
A whole lot of bug fixes, big and small, has been added in this version. Most of the fine tuning of the positioning and spacing of the block elements has been finished.
But what is a bug, and what is an enhancement? That is a question that I have asked myself many times the last two weeks, because only bug fixes can go into a release candidate.
It is important that our time is spent on fixing the right problem, on problems that can be fixed and tested in a timely manner, and then merged. What is important for one person, might not be such a big problem for someone else, so how do you choose? We all have our pet peeves.
Fixing accessibility issues
I have not always been able to communicate directly with the contributors about why something is or may be an accessibility issue.
We have had regressions because the accessibility has not been considered when pull requests has been added. This has meant that it has taken a long time for accessibility issues to be solved. And I see the same pattern with browser testing. I regret this but I still feel that I have done my best. Testing everything is hard.
To me, the main remaining accessibility issue is the sub menus of the desktop horizontal menu. Hopefully we can find some one to help us solve this soon.
-But this does not mean that there aren’t other things that needs to be improved for the theme to be more accessible. It just means that I have not found them.
If you find a problem, please report it and open a new issues. -For now, the theme is still being developed on Github.
After a dissapointing doctors appointment on monday and an important work meeting on tuesday afternoon, I had to sleep 12 hours and missed a lot of the fun.
Luckily, Ian has been able to spend more time on the theme this week.
The JavaScript for the menu has been added, but it is not yet perfect especially not in IE11. Many awesome people contributed to improving the JS and removing jQuery depenendancy for the front.
More of the design has been added. Many block styles are still missing, as well as some styles for the comment area.
Color settings are being redone to assure a high enough contrast between background and text. The new accent color will be a hue setting and it is looking really good. The code for the color setting is under review right now and will be included soon.
We still have many github issues to go through and some that could be closed because they have already been fixed. Hopefully these will be looked at on thursday.
I also noticed that some things that already have been fixed once, has sneaked their way back in, and those issues needs to be reopened.
The first week, making decisions on open pull requests was fairly easy. This week it has become harder for me to make decisions on my own without discussing it with the other maintainers. This is probably the way it should be though!
And I’m helping! As a representative for the Theme Review team, I’m here to help contributors follow the theme guidelines, and make sure that are no major requirement breaches, such as licensing problems.
Our first week has contained meetings, discussions regarding build tools, coding standards, accessibility, fonts and JS.
This is the first time I participate in a project like this, and I am excited, humbled, overwhelmed and honored, and I am already learning a lot.
Finding time to work together has been a little difficult this week, which is not surprising considering this time frame. I still feel that we have made progress with the theme.
When we started developing the theme, we did not start from scratch, but with the Chaplin theme by Anders. The version that we started with was a shell that had many of the extra options removed.
Because Chaplin had already been approved by the Theme Review team, we knew that the theme followed the theme requirements. We also knew that the structure needed to change to match the vision for Twenty Twenty, and that the accessibility needed to be improved.
We had many contributors show up to help with the theme, we made some big changes and many smaller changes to get closer to the look and functionality that Anders have envisioned.
Personally, I have struggled with improving my Git and Github skills, but the members of the Theme Review Team, especially William Patton and Denis Žoljom have been incredibly helpful and positive. I am thrilled that so many members of the Theme Review team has already contributed by opening issues, giving comments and advice, and pull requests.
The theme review team is requiring all themes to implement keyboard navigation in two months time, around the third of september 2019.
Because this may be a complex task for many authors, we encourage you to start planning for and working on this as soon as possible.
We want to point out that this requirement does not only include menus. All functionality should work using a keyboard only. Any action you can complete with a mouse must also be performable via keyboard.
Theme authors must provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. All controls and links must be reachable using the keyboard.
We would like to collect examples for the keyboard navigation, including menus. If you know of a good resource that is not already included, please add a comment and link.
Navigation menus and controls
Drop down menus and controls must be available when tabbing, using keyboard only.
Both forward and backwards tabbing must work. To test backwards tabbing, hold down Tab and Shift at the same time.
Controls also include open and close buttons for modals such as off canvas sidebars or search forms.
Form fields
Don’t break the browsers default focus by removing the outline. Other kinds of decorative changes are also allowed. Only showing the marker inside the field is not enough.
Submit buttons
Submit buttons may be hidden during it’s normal state but visible on focus.
A high contrast color change, an outline, a border, or a text decoration change will assure that visible submit buttons pass the requirements.
Text links
Make sure you can see visually which link is focused. Focus should either incorporate a visual change that is not based on color (background change, underline, shape) or a color change where the difference between the two colors meets the WCAG 2.0 level AA contrast ratio (4.5:1) .
Basically, don’t break or remove the browsers default focus by removing the outline.
Mardi Gras a fun, colorful theme for the carnival season. The theme has four widget areas, two menus including a social menu, and displays your posts in a 3 column grid. The default colors are the traditional New Orleans Mardi Gras colors green, purple and yellow. You can change the number of columns and select your favorite colors and fonts in the customizer. The theme is responsive and also supports the new block editor with wide and full width blocks.
When reviewing themes for the WordPress.org theme directory, you will find that there are mistakes that are more common than others. This means that we often use the same type of messages in different tickets and reviews.
We can use this fact to make our reviews faster. I have done so many reviews that many of the texts are in my muscle memory, but I still save some of my reviews with the purpose of being able to copy paste them into other reviews later.
But we can improve on this further by using the code editor of our choice to add the most common texts for us.
I use VS code, and I followed these instructions to create my own review specific snippets:
In VS Code, go to File, Preferences, and select user Snippets
Now you can choose to create a snippet for a specific language, or a global snippet file. I write my reviews in a simple .txt file so I created a global file.
Documentation for how to create a new snippet is included in the file header of the new file, which made it very easy.
Place your global snippets here.
Each snippet is defined under a snippet name and has a scope, prefix, body and description.
Add comma separated ids of the languages where the snippet is applicable in the scope field.
If scope is left empty or omitted, the snippet gets applied to all languages. The prefix is what is used to trigger the snippet and the body will be expanded and inserted.
Possible variables are:
$1, $2 for tab stops, $0 for the final cursor position,
and ${1:label}, ${2:another} for placeholders.
Placeholders with the same ids are connected.
Example:
"Print to console": {
"scope": "javascript,typescript",
"prefix": "log",
"body": [
"console.log('$1');",
"$2"
],
"description": "Log output to console"
}
I decided not to use a scope, here is an example of one of my custom snippets:
"Missing license": {
"prefix": "missing license",
"body": [
"Themes are required to be 100% GPL compatible.",
"Reviewers can not confirm that a theme is GPL compatible unless all the license information is included in the theme.",
"Missing license information for:",
"(Placeholder: include additional information like a script name or image used in screenshot)",
"$0",
],
"description": "Missing license information for included assets."
},
So when I write my review, all I need to do to add the information about the missing license is to start typing “license” or “missing” and press enter.
Here is the first iteration of the file: Download.
The Theme Review Team on WordPress.org encourages reviewers to find their own flow and tools that work for them. There is no right or wrong way to review a theme, as long as the requirements are checked and the author receives useful feedback.
My personal review process require a lot of manual effort.
While I liked the GUI of flywheel, it was just way too slow and sometimes buggy. I also found that it was not suitable for me when I wanted to do other projects than WordPress. Which happens about 3 times per year 🙂
Docker was easy to get started with, but there was a bit of a learning curve for me to get things exactly the way I wanted them. I now use two very basic docker compose files (with a persistent theme and plugin directory).
Sometime during the year, there was a big update to Sublime Text which broke all my settings. I could not get my extras like the PHP Code Sniffer to work again and truth be told, I gave up. I switched to VS Code, and I love it.
Normally it takes me 5-10 minutes to see if a regular sized (or underscore based) theme needs to be closed because there are 5 distinct issues, or if the review can continue.
But summarizing the findings and adding references, explanations and images to help the author fix the issues takes a little longer.
I try to consider whom I am writing the review for:
-Do I need to add references?
-Do I need to help them find a solution, or is it enough if I mention the issue?
Not all steps are performed on all themes, it depends how the theme is built.
I also split large themes over several reviews, because I don’t always have enough time to check several hundred files in one go.
If I quickly find 5 distinct issues I may close the theme as not approved without doing a full review.
First I check if the screenshot in the ticket is reasonable and not a logo or mockup.
Then I check the Theme and author URI before I download the zip file.
I look through the theme files before I install the theme.
If I do not recognise the theme author, I normally start by checking the license information in style.css and the readme.txt file, and check the theme and author URI. This is to make sure that I am not spending time on reviewing a theme if the theme is not GPL compatible.
Then I continue by opening functions.php, header.php and footer.php:
Are there hard coded scripts?
Is there text that is not translation ready?
Is everything escaped?
If there is a footer credit link does it match theme or author URI?
Are the functions in functions.php prefixed and are scripts and styles enqueued correctly?
Are menus, widget areas and theme support added correctly?
Then I check if there are folders named js, css, dist, assets or similar, and if there are minified files. I also check if there are any plugins, demo files or similar included in the theme folders.
If there are minified files, is the non-minified version included as well?
This is when I start making notes and adding items to the review.
I already have texts written for common errors that I can add and adapt for the specific theme.
Run the plugins.
Are there any errors reported?
Check any warnings manually.
Then, depending on the theme, I use my code editor to search the entire theme folder for the following:
get_theme_mod -This helps me find theme mods that are not escaped.
remove -This helps me see if the author has removed any customizer settings or non-presentational hooks.
function, -This gives me a handy list to help me check prefixes and whether custom functionality is used in place of WordPress functionality.
script -This helps me find hard coded scripts.
alt=, title=, placeholder= -This will help me find translated texts in attributes and make sure the texts are escaped.
add_theme_support – This helps me check if the author has added support for title (required), custom logo (instead of using their own) etc.
If there are multiple post formats and templates I might also search for wp_link_pages, query and reset.
Then I install and activate the theme to make sure that:
There are no php or js errors.
There is no redirect on activation.
Notices are not global and can be dismissed.
Plugins are not required, only recommended.
Testing the theme layout and custom options.
Is the correct number of posts displayed?
Are comments displayed correctly?
Are there any php or js errors?
Perform a search.
Test the 404 page.
Test the navigation.
Set up a menu, is it working? Test the menu in a smaller window, is it working? Make sure that it is not overlapping or in other ways disturbing the admin bar.
Test custom widgets and make sure there are no php notices, warnings or errors.
Make sure that there is only minor content creation.
When I go to the customizer and test the options, I also open the customizer.php or related files in my editor and make sure the options are sanitized and set up correctly.
Check to see if there is demo content, content creation or plugin territory functionality.
Is the upsell reasonable and is it added with the customizer API?
Go to the post editor and double check if any meta fields has been added, and that they are for presentation, not content.
Test the meta options and repeat for pages.
Test page- and post templates.
If there is starter content, reset the install to fresh and test it.
Does the theme match the tags and description in style.css?
Whether I find issues or not, I still open each file in the theme folder manually and review them quickly, including minified files. This is still the fastest way for me to check for untranslated texts and anything that stands out.
When the review is finished, I save it as a .txt file and then cut and paste the text in the Trac ticket.
Some early (and early morning 🙂 ) thoughts about Phase 2.
I’m still a bit confused about what will go into earlier updates, and what will go into phase two. I mean there was a ton of block ideas that got postponed, will these blocks or some of them be added in phase 2?
Simplicity is important. Having a lot of visible elements (and in different colors) on the same page editor can be stressful.
I’m finding it difficult to picture if -or what part of, the current customizer sidebar will be visible at the same time as the new editor toolbar/inspector.
I think that having both the customizer sidebar with the panels and settings visible, and also have visible toolbars for selected blocks; and on top of that, the customizer shortcuts, could be too distracting. The visible panels and settings has to be carefully selected.
How will the customizer shortcuts be used, when many but probably not all elements will be editable directly? If we don’t use the customizer shortcuts, how do we show the user which elements that are editable?
This might not work…
Would the customizer only be used to edit the front page, or would we be able to edit the search results page, 404, archives, single pages, shop pages etc?
Because when we talk about layouts and in an extension, block page templates, all these inner pages are likely to look different from the front page and from each other. For example, a header image and large site title and tagline might be a visible editable area for a front page, but might not be visible in a single post view.
Currently, the customizer panels can have unlimited options. It would not make much sense, to have a panel with a setting that selects the sidebar position for my single posts, if I am currently viewing and editing blocks for the front page.
Perhaps the theme would declare support for different views which can be edited?
It would be nice to have a simple option where we can choose whether we want to show the full content, excerpts, or even just the titles on the blog, archives and search result pages.
I sometimes receive support requests from users who are asking why the full content is showing, even when they set the feed to only display the summary.
No, this setting is not for the blog.
I want to be able to create reusable block templates, and not only for custom post types.
We might need several different kind of templates:
Layouts where we select the position of our widget areas, header images, adverts, menus etc.
Layouts for individual content blocks, recommending a specific order of blocks for individual content.
In phase 2, will we really need both pages and posts? If we are able to change the visibility of the meta information like the post date etc, the difference between the two types will continue to be blurred out.
If I want a front page of ten posts, then I don’t want to manually have to drag and drop ten individual post blocks and order them in the customizer.
I want to be able to add the latest ten posts in one go, but maybe I don’t want to use the current latest posts widget either. That block has a different purpose.
Then again, if I added post block(s) to my front page that I am editing in the customizer, and I spotted a typo, then I would want to be able to edit it directly in the customizer and save it, instead of having to leave my view and open the individual post.
I want to be able to edit everything in the post. Like title, permalink, images…
I want to be able to add a simple one page menu. A menu that checks what posts or pages that I have added to the current page view, and automatically creates the links for me.
I think adverts is something that have been forgotten. Today you might install a plugin, or a few plugins, or add a code to a theme setting (!) in order to include your ad code, but displaying the adverts correctly on the page is still not that easy. We could greatly improve this and help users optimize their adverts.
Social media links with icons is something that nearly every theme adds, either as link options in the customizer, or as a menu. There should be one simple, recognizable way to include social media links. If a menu system is used, I still think it needs to be a lot simpler than it is now.
It should not be more difficult than adding any other type of link, and the visual feedback must be better. The icon should be visible immediately, not only on the front.
We use cookies to ensure that we give you the best experience on our website.OKPrivacy policy
