Tag Archives: Theme

Automattic Releases Quadrat, a Block-Based Podcasting WordPress Theme – WP Tavern

[ad_1] A few weeks ago, Automattic released Quadrat on the WordPress.org theme directory. It is now the company’s fourth block theme. Like its predecessors, it is a child of Blockbase, a project that serves as a foundation for the work of Automattic’s Theme Team. After spending a couple of months diving deep into the world of block themes, I was beginning to feel a little burned out. When I wasn’t sleeping, eating, or doing yard work in my off-duty time, I was building or exploring one project or another. Soon, it all had become a blur. I knew I needed to take a small break, and I have not touched themes for a couple of weeks since, at least not outside of work. However, Quadrat appealed to the theme developer within me. I am not sure if it was the soothing color scheme or just seeing the work the professional designers had put into it, but it offered a pathway for easing myself back into the block theme world. Outside of the work by Anariel Design with Naledi and Clove, most block themes have felt more like proof of concepts or starting points. Quadrat can now be added to the list of those with some personality. It does not push any particular boundaries, but it is a well-designed blogging and podcasting theme. Mostly, I am just a fan of the color scheme — sometimes you just need something other than black, white, and gray to get yourself out of a funk. One of the other reasons I have been following the work of the Quadrat theme was because it was the first showcase of header patterns I had seen. Kjell Reigstad shared what this system would look like in June. The goal is to include the patterns shown in the video in core WordPress, so they are not currently included in the theme. However, there is still an open ticket for header patterns in Quadrat. The only real trouble I ran into with the theme is with fully aligned blocks in the content. There is an overflow issue in version 1.1.1 that creates a horizontal scrollbar. Horizontal scrollbar appears with full-width Cover block. Quadrat includes nine custom patterns. The focus for most is on podcasting, but some are general-purpose enough for other use cases, such as “Media and text with button”: Media and text with button pattern. The development team missed a prime opportunity with its podcast-related patterns. Instead of integrating with a podcasting solution, they are simple, static blocks from core WordPress. For example, the Latest Episodes pattern is a two-column layout that features Image, Heading, and Paragraph blocks. That is acceptable as a base pattern for users without a podcasting plugin. However, it may be practically useless for those with one enabled. Or, it creates unnecessary work because users must manually update their page content anytime they publish a new episode. Latest Episodes block pattern Given Automattic’s recent bet on Castos as part of a $756K pre-seed fundraising round, it would make sense to integrate with the podcasting company’s plugin, Seriously Simple Podcasting (SSP). If the development team wanted to take the Latest Episodes pattern to the next level, they would create it with the Query Loop block and display the latest podcast episodes from the plugin. For users without SSP installed, simply fall back to the current pattern. Or, offer both. Right now, it is little more than eye candy and not nearly as useful as it could be for real-world use cases. I often talk about the need for theme authors to elevate their game. Not only would such integration be beneficial to podcasters, but it would also showcase the power and flexibility of the block system. All of this is to say: If you are going to build a podcasting theme, build a podcasting theme. Quadrat appears to be one. However, when you peek behind the curtain, it is just a well-designed blogging theme. It has the potential to be so much more. Like this: Like Loading… [ad_2] Source link

Continue reading

Full Page Patterns Are Still the Missing Piece of Block WordPress Theme Development – WP Tavern

[ad_1] It was the early days of the Gutenberg project. Many on the Theme Review Team and those in design circles were trying to wrap their heads around this new concept called blocks. In particular, we wanted to know how it could be applied to theme development. There were many discussions on the pros and cons of the early editor. Overall, there was a bit of cautious excitement in the air, our optimism tempered by a buggy version of alpha-level software. The block system could potentially solve one of the biggest hurdles of theme development: inserting default/demo content for a full page into the editor. I cannot remember who initially explained the idea, but it was a lightbulb moment for many at the time. The general concept was pre-building a custom homepage or any page design that users could choose visually. It would all be done through a standardized block system, and we would no longer need to rely on piecemeal theme options, third-party plugins, or attempt to work around the review team’s “do not create content” guideline. No one really knew how this would work in practice, but we understood the theory of how it would make the life of a theme developer much simpler. In October 2019, Automattic developer Jorge Bernal opened a ticket titled Starter Page Templates. His team was working on a template selector for mobile apps, and the WordPress.com Editing Toolkit already had the feature. The goal was to bring it to the core platform, allowing third-party theme designs to build on top of it. Starter page templates idea initially shared in the ticket. Because the term “template” is overused in the WordPress space, I will refer to these as “page patterns.” This naming convention was coined by Noah Allen, a software engineer for Automattic, in the ticket. It makes sense because we are actually talking about a page’s content rather than the wrapping template. The Genesis Blocks plugin is one of the best ways to understand the page pattern concept. It has a Layouts button at the top of the editor that, when clicked, creates an overlay of designs to choose from. Selecting a full-page layout from Genesis Blocks. These designs are split between sections and layouts. Sections are the same thing as patterns in core WordPress: small, reusable pieces of starter content. Layouts are full-page starting points for users to create various types of pages. The StudioPress/Genesis team was not the first to market this concept. However, they have created a well-rounded user experience on top of the WordPress editor. You will find similar experiences via GoDaddy’s onboarding process for its managed hosting service. The Redux Framework allows much the same, and Editor Plus offers templates and patterns from the Extendify library. That initial excitement has waned a bit. It felt like that early promise was a dream that would never be a reality. Theme authors, especially in the commercial space, have long offered home-brewed solutions for the one-click insertion of full-page content. Whether via a ThemeForest project or a popular theme on WordPress.org, there are endless examples of everyone solving the same problem. One might even argue that these custom inserters are so ingrained into theme agency systems that anything WordPress offers at this point will not appeal to those who have already brought their solutions to market. Where the core platform has failed to meet user demands, our development community has stepped up. Some of you may be thinking that the current block patterns system works for this. Yes, and no. Theme authors could shoehorn full-page designs into it, but the user experience is lacking compared to third-party solutions. Patterns today are one of the best theming tools available, but they fall short of what is needed to see this thing through. The foundation of this feature exists via the Patterns API. From the theme author’s perspective, they merely need a method for flagging a pattern as a full-page layout, separate from the others. However, the UI and UX flow need an overhaul. The flyout panel for the current inserter does not cut it, especially on large screens. A fullscreen overlay has become the de facto standard among other systems. Users should also have another option between selecting from an existing page pattern or starting empty upon creation. “I think this would be so useful to have in the core,” wrote Ana Segota of Anariel Design in a recent comment on the ticket. “I created 2 FSE themes so far and also our latest premium theme is made with block patterns and this is exactly what I thought and talked with few people about. It would be great when a user opens a new page, to chose design/page patterns however we called it and it starts editing it right away. Most of the users just want to add a page, choose a layout and start adding their content.” Of course, this is not a revelation to the average theme author who works with end-users daily. Inserting or importing entire page designs into WordPress is one of the most common requests. WordPress is almost there with its current patterns system. We just need to take it to the next level. Like this: Like Loading… [ad_2] Source link

Continue reading

Open Survey for WordPress Theme Authors on JSON Files and Block Themes – WP Tavern

[ad_1] WordPress 5.8 introduced an opt-in system for themes to configure block settings, styles, templates, and more. It is done through a new theme.json file that authors can put at the root of their theme folders. Anne McCarthy, the lead of the FSE Outreach Program, announced a survey earlier today to get feedback from developers on this feature. “Since this new mechanism is an early step towards a comprehensive style system for the future of WordPress, it’s important to hear from everyone who is currently using theme.json to learn more about how folks are using this tool and what might make sense to include in Core going forward,” she wrote in the announcement. The survey is open to all theme authors who have used theme.json, giving them a chance to put in some early feedback and help steer the ship going forward. Because I have worked extensively with this system over the past few months, I had a few things to say. Plus, I just like participating in WordPress-related surveys. I also decided it would be an opportunity to share some of my unfiltered thoughts from a development perspective on the current state of theme.json. What follows are my responses to the survey’s questions — well, the tidied-up version. Note: This is a developer-centric post that might not universally appeal to all of our readers. I have attempted to explain some things in user-friendly terminology, but some prerequisite knowledge of theme development may be necessary. Experience The first question of the survey is pretty cut-and-dry. It asks what your experience is with building block themes or using theme.json. It provides four choices (and an “other” option): I have built and launched block themes. I have experimented with building block themes. I have explored using theme.json with a classic theme. I have used a block theme, but I have not built one yet. I chose the first option because I have already built two block themes for family and friends. These were simple personal sites that I already maintain for free — honestly, I need to start charging. I am also working on a theme that I hope to release publicly. How It Started and How It’s Going The second question asks how one got started with block themes and theme.json. The choices are between forking an existing theme, using the Empty Theme, or starting from scratch. Again, this is one of those things where I have experimented with each direction, but I cannot remember the exact starting point. The bulk of my work has come from forking a theme that I last worked on in 2019. I plan to release this as a new theme for free at some point. I am mostly waiting on the following: Navigation block development to settle down The Post Author block to be split into smaller blocks A robust set of comment-related blocks Post Featured Image block to have a size option I think I could realistically release a use-at-your-own-risk beta version of my theme today if those items were addressed. Templates and Template Parts The survey asked which templates and template parts themers always include in their block-based themes. There was a freeform comment field — steps upon soapbox… I have a love/hate relationship with block templates at the moment. The static nature of HTML templates reminds me of simpler times when theme development was less complicated. However, this also presents a problem in a dynamic system. I cannot remember the last time I have built a traditional, PHP-based theme with more than one top-level template: index.php. The dynamic pieces have always been the guts of the thing, which are template parts. With PHP, it is easy to set some variable or use a function call to contextually load the templates parts necessary for whichever page a visitor is currently viewing on a site. The block template system does not work like that. It essentially forces developers into breaking the Don’t Repeat Yourself (DRY) principle. For example, if a designer wanted to display a different header template part for pages and posts, they would only need to create a header-page.php or header-post.php template in traditional themes. However, because the block template system is different, they must now create two top-level templates, single.html (post) and page.html, to accomplish the same thing. This is a “bad thing” because theme authors must duplicate all the other code in each of the top-level templates. There is no way to contextually load different template parts. To answer the question: I am using almost all of the possible top-level templates out of necessity. I also answered the second part of the question and listed my most commonly used template parts (broken down by hierarchy): Header Content– Loop– Sidebar Footer The content-*.html and loop-*.html template parts are those with the most variations. Defining Colors The next section of the survey asks how theme authors define their color palette slugs in theme.json. Believe it or not, naming colors may be the most controversial topic in the theming world in years. The only two things generally agreed upon are “background” and “foreground” colors. Morten Rand-Hendriksen opened a ticket in 2018 for standardizing a theme color naming scheme. It was not the first discussion and has not been the last. The problem it was meant to address was the slugs for colors in the system, which is how themes define their palettes. Once a user makes use of a preset color, the slug is hardcoded into their content. Switch to another theme with different slugs, and the old colors disappear and do not automatically change to the new theme’s colors. I use semantic names that follow something that closely resembles the Tailwind CSS framework’s shading system. Instead of red-medium (descriptive), I would use primary-500 (semantic), for example. A semantic approach would allow theme authors to define a set of colors that are updated each time a user switches themes. Of course, there are other schools of thought, and even everyone who prefers

Continue reading

Theme Creation Will Be Easier, But We Are Not There Yet – WP Tavern

[ad_1] “The way that themes have evolved within WordPress has made creating them easier,” wrote Tammie Lister in the opening line of her article titled Theme creation is now easier. “That feels like a bold statement, but it’s true.” It is not a stretch to say that many would be asking for this secret-sauce recipe of easy theme creation. If anything, WordPress theming is at its most complex stage in history. It is a weird mix of APIs and years upon years of legacy baggage. Jumping into traditional theme development today carries with it a high barrier to entry, especially if you want to build anything grander in scope than any of the default Twenty* themes. But Lister is talking about the WordPress of the future, a platform that will render its front-end output via blocks. The thing about blocks is that they put this veil over a lot of the messy legacy stuff, creating a new standard where anyone who wants to build a theme does not have to worry about a lot of the history that got us from Point A to Point B. That is a Good Thing. Standardization of the system was long overdue, but we are still in the process of making that final leap forward. It is a tough time to be a developer. It can also be an exciting new adventure if we stop thinking about themes from a traditional mindset. Lister made sure to point out the difference between theme “creation” and “development.” In almost two decades of WordPress, we have only ever had WordPress theme developers. Only those with the minimum knowledge of HTML, CSS, PHP, and [sometimes] JavaScript could build a theme. And, that is absolutely still true today. However, it will not be true tomorrow. The act of front-end design does not have to be an all-or-nothing affair. Creators can build custom patterns and soon be able to submit them to the official pattern directory. WordPress 5.8 launched the template editor, so anyone can dip their toes into the shallow end of the template-creation pool. Global styles, a feature yet to be released, carries with it the promise of customizing fonts, colors, backgrounds, borders, and much more. From a developer’s perspective, some of these features can seem limiting. We dive into code and see the world around us changing. Nothing is like the WordPress of old. There are moments when things are more complicated — sometimes by magnitudes. However, for people who have never written a line of code in their lives, there is something magical brewing. WordPress is lowering the barrier to entry to almost nothing for the “regular” folks. I remember how empowering it was to create my first personal blog design on top of WordPress. It was a fork of a theme by Tung Do, the former owner of the now-defunct WP Designer blog. I knew enough HTML and CSS to hack my way through most of it and just enough PHP to break my site several dozen times. It was a life-changing experience for me that played no small part in launching my career. However, I also think about all the people who never got to build their own site designs because they did not have the prerequisite knowledge, the available time, or ran into some other blocker that disallowed their entry into the experience. WordPress is positioned to change that with new tools, building a runway that allows more people to become a part of our collective design community. It is not only about building personal blog designs. It is about allowing anyone who wants to contribute to this open-source experiment, founded on the idea that we can share with our neighbors. The pattern directory, which is only a few days old, is an early example of that. As we continue removing barriers for non-developers, it opens an entire world of possibilities and, perhaps, allows some who did not previously have the privilege of contributing an opportunity to do so. Or, it could even be the launchpad of a new business for some. There is also a two-year-old ticket on starter page templates that is picking up steam. It is a sort of companion to block patterns, tackling entire pages instead of sections. The initial goal would be for themers to bundle these in their themes, but I envision a future where users can create and share these freely with their peers via WordPress.org. But, it is rough going for theme authors today — plugin developers too, but we’ll save that for another post. Traditional themes carry all the legacy baggage mentioned earlier, and some of the new block-related tools have added to the load. The current phase often breaks classic projects or forces developers into mixing compounds and waiting to see if the amalgamation explodes. And, the promised future of easy theming with blocks is still in its infancy. The moment developers get into anything slightly more “advanced” than a simple blog, there are hurdles and pitfalls aplenty. For example, if you want to use different image sizes and orientations in various sections of a front-page template, that is impossible with the Post Featured Image block. Or, maybe you have a theme user who wants to put a dynamic profile/account link for registered users on their own site. It is not happening without building a plugin or finding one to handle the job. It can also be a tough sell when four lines of PHP code worked just fine in the past. These are merely simple examples of an array of issues that theme authors deal with on a day-to-day basis. They are problem-solvers for the masses, but they do not yet have a robust enough set of tools. Foundationally, the block system can handle most problems and even provide better solutions in some cases, but not all of the necessary blocks or options are in place yet. As we continue solving these problems and adding the missing pieces, theme creation will

Continue reading

Everse Theme Review: Multipurpose Elementor Theme

[ad_1] Elementor is a powerful page builder, but it requires a compatible and customizable theme. While there are dozens of ‘highly compatible’ themes for Elementor out there, you need to do a thorough check before you can say for sure that the theme is a good fit for you. In this article, I’ll be reviewing the Everse theme by DeoThemes. If you are looking for a compatible theme for your WordPress website running Elementor, this article is perfect for you. Everse Theme: Quick Overview Everse is a lightweight and customizable multi-niche WordPress theme which comes with in-built seamless compatibility with popular products like Elementor and WooCommerce. The pro version of the theme comes with 20+ professionally pre-built starter sites. Almost every starter site has more than five well-designed pages or sections that you can import with just a single click and can customize further. Here are some highlights of the Everse theme: Everse comes with full compatibility with the WooCommerce theme allowing you to create an eCommerce store and start selling products and services online. Since the theme follows strict high-quality code standards, the theme is blazing fast and lightweight. Moreover, you don’t have to worry about SEO as it is fully optimized to rank well on Google search results. The theme also features a powerful mega menu builder to create unlimited mega menus for your website. With this feature, you can create and present large catalogs of products/ menu items while simplifying the website’s navigation. The header and footer builder of Everse allows you to take control over their design. Even if you do not have Elementor Pro, you can pretty much customize every aspect of the header/footer with ease. With Everse, you get access to the Eversor plugin, which extends elementor and adds unique and valuable widgets in your library. Regarding pricing, you can get Everse for $49/year for a single site license. If you want an unlimited websites license, you can get it for $99/year, and for the lifetime license, you can get it for a single payment of $249. Now to explore the theme features in detail, let’s look under the hood and see what Everse can achieve on a standard WordPress installation. On Hands with Everse In this section, I will give Everse Pro a test spin and explore its features. So let’s jump right into it! Installation Once you have Everse Pro, you can install it on your website like any other plugin. Go to the WP Admin dashboard > Appearance > Themes > Add New. Now upload the theme and click on the install button. Once you have installed the pro plugin, you need to enter the license key on the Freemius activation page. Simply enter the license key to activate the plugin. Setting Up After installation, you’d be redirected to the plugin’s setup page. However, before you can start using the theme to its full potential, you need to install a few more plugins. Here are the plugins: Everse Core: The main supporting plugin for the theme with functions like social media, CPTs, and WordPress widgets. Elementor(If you don’t have it already): Customize parts of the theme and pre-built starter sites. If you do not have Elementor pro, you can work with Elementor’s free version as well. Eversor: Elementor’s extension that adds a library of 15+ custom widgets[1]  and 20+ WooCommerce widgets. Kirki Framework: A robust framework for adding options in the WordPress native customizer. The plugins mentioned above come pre-packaged. So you just have to click on the ‘begin installing plugins’ link on the notice, and they will be installed automatically. Article Continues Below Everse Starter Sites In the WP Admin dashboard > Appearance > Everse Starter Sites, you can access and view all the designs. In addition, you can import as many templates as you want and can customize them further. To import a starter site, just go to the design you wish to import and click on the import button. If a theme uses any required elements to function correctly, it will be displayed in a prompt. Then, you just need to click on ‘Install and activate plugins’ to grab the required plugins with a single click. After the import was completed, the theme was live on the website. Customizing Everse Starter Sites Customizing the pages is pretty much the same as customizing any page built with Elementor. Go to pages > the page you want to edit and click on the ‘Edit with Elementor’ button. In the Elementor editor, you can quickly make changes to the design, content, or styling of the elements. On the elements sidebar, you get a section for Eversor widgets. You can use these widgets while designing. Here are some of the widgets: Services Contact form 7 Pricing tables Image before and after Navigation menu Off-canvas Breadcrumbs Advanced Google maps Menu Search Projects Everse WooCommerce Builder Everse comes equipped with a powerful WooCommerce builder. You can create a new product template from scratch or you can import a demo from the Everse Starter Sites plugin and start customizing it. With 20+ custom-built WooCommerce widgets like product title, product price, or related products, you can create every WooCommerce parts or page that is required to run a successful eCommerce store. WordPress Native Customizer Options While the theme is pretty much editable with Elementor, DeoThemes added more options in the WordPress customizer. Kirki powers the options in the customizer, so make sure you have that installed and activated on your website before you visit the native customizer. You get all the standard options like colors, font styling, website logo, and site identity. On top of these options, you get some unique features: Header and footer customization options such as layout styles, logo, etc. Social options can add links to social profiles such as Facebook, Twitter, or Instagram, and they will be applied on the page automatically. Option to make the website GDPR compliant by showing a cookie consent notification bar with the opportunity to customize

Continue reading

A Developer-Centric Call for Testing Theme JSON Configuration – WP Tavern

[ad_1] Round #8 of the Full Site Editing (FSE) Outreach Program began yesterday. Instead of the user-centric call for testing features from the UI, program lead Anne McCarthy asks that volunteers dive into code. The new adventure is all about testing theme.json files. The twist is likely to limit the pool of usual volunteers. However, it could open it up to an audience that may have been sitting on the sideline for the previous tests: theme developers. Before jumping headfirst theme JSON files, we should probably all get on the same page. I have been calling theme.json the tipping point between the old WordPress and the new WordPress. When version 5.0 of the core platform launched in late 2018, it was a revolutionary step forward, but not on the surface. A new editor is just a new editor. Some will love it; others will hate it. And, it was more often clunky than not. For the most part, WordPress was still WordPress. The core software was due for an upending. Newer technologies were not only democratizing publishing in their own ways, but they were also bringing that same concept to design. The introduction of blocks was merely foundational. The new editor was an imperfect tool, often feeling like the proverbial round peg being shoved into a square hole. The only way to live out the early vision of the Gutenberg project was to continue bridging the gap between what the user sees in the admin and what gets output on the front end. That is what the theme.json file is all about. It is a translator that allows users, themes, and WordPress to all speak the same language. What does this mean exactly? From a user’s viewpoint, they see all sorts of controls for changing their blocks. Color, font size, alignment, and other options are tools that allow them to customize their content. Customizing a profile card for my cat using block options. There are severe limitations with what is possible in the current system. Theme authors can register a handful of options. Outside of that, the theme and block systems can feel like they are pitted against each other for control. That is where the theme.json file comes in. It allows themes and WordPress to get on the same page, creating a standardized system that improves the user experience. This file that lives a theme’s root folder hands over the power to configure dozens of presets (e.g., color and font options), custom CSS properties, and default styles for blocks and HTML elements. It also gives themers the power to enable or disable specific features. For example, developers can turn off the ability for users to set a custom font size but provide access to their perfect scale of choices that fit into the design’s vertical rhythm. However, it will move beyond the simple configuration of blocks in the content editor. When the global styles system launches alongside the site editor in the future, users will customize many of the presets and overwrite the default block styles. Because everyone is speaking that same language, fewer conflicts arise. As designer Tammie Lister pointed out in her piece for Ephermeral Themes, Theme.json inspires, themes have been stuck. The software, the community, has put too much responsibility on the shoulders of themers over the years. They have had to innovate and build the systems that should have been coming from WordPress. Not only did the core platform need to be turned on its head, but the design system deserved an overhaul. “I am very aware that saying ‘first major theme process to core’ in years is quite a statement,” wrote Lister. “Theme.json to me is that though. I don’t say this ignoring iterations and improvements, WordPress is a project flowing with the energy of those. However, themes were on life support stuck in a land when the rest of front end development was moving on. It wasn’t for some trying to change that, mostly when they did the time wasn’t right and as it didn’t come from core it was always a harder change.” It is time for a new front-end design era. But, first, we must test. Testing Theme JSON Real-world theme.json file. The more I journeyed into this call for testing, the more I realized it did not feel right for me. Over the past couple of months, I have already been in the thick of working from the theme.json file. I know most of the little quirks and see the gaps. The tricks for working with it feel second nature to me. I have performed all of the beginner and intermediate steps dozens upon dozens of times. I have already filed tickets for any issues I have run into. Or, someone else has already beat me to the punch. Those stages of this testing round need fresh eyes. The best feedback will be from theme authors who will be viewing the problems through a different pair of lenses. If you are in this group, there is no time like the present to test and provide feedback. The advanced stage calls for recreating a classic theme using theme.json. It is best to stick with something simple. Otherwise, you could be looking at a weeks-long experiment. McCarthy recommends Twenty Twenty or Storefront. I have already been performing this song and dance too. My test project was an old theme that I gutted and turned into a block theme. There is one overarching issue that I keep coming back to. It is that theme authors must work from a JSON file at all. I understand the “why” behind using JSON. It is a universal format that we can pass around from JavaScript to PHP. Third-party APIs can understand it. However, I am currently sitting on top of 900+ lines of code in my theme.json. I have heard from a couple of other theme authors who have been doing deep work with similar numbers. I expect it to only grow. “Number of lines”

Continue reading

WordPress Theme Lock-In, Silos, and the Block System – WordPress Tavern

[ad_1] For many years, I was a hardcore advocate of separating any non-design functionality from themes into their own plugins. I wrote extensively on the issue. Whether it was shortcodes, custom post types, user metadata, and any number of things related to a user’s content/data, I drew a deep line in the sand. This belongs in a plugin. If you have never heard of the “theme lock-in effect,” that’s OK. For many, it is a non-issue. Places like the WordPress.org theme directory have, for the most part, drew a similar line in the sand. The goal has always been to avoid trapping a user into perpetual use of a particular theme. It is not an ideal user experience when some crucial data is no longer available when switching designs. And, all users eventually want to change that up from time to time. Getting stuck with [shortcode-soup] tags littered throughout a site is never fun. Neither is losing admin access to dozens, hundreds, or even thousands of pages from a custom post type that suddenly disappears. The WordPress theme development community has avoided this problem — some more so than others — by bundling crucial content-related features separately in plugins. Those theme authors who bypassed theme lock-in via plugins have mostly done so in their own silos. For example, instead of integrating with an existing portfolio plugin, they would just create their own. The only themes that support that plugin? Theirs. Ultimately, users were still trapped. I cannot lay the entire weight of this issue on the shoulders of theme authors. Portfolio plugins are a dime a dozen. Supporting WooCommerce for an eCommerce solution or bbPress for forums are easy choices. But, when there is no clear industry front-runner, an in-house solution is just as good as most others. However, the block system is already complicating matters. When a theme supports features like font sizes, colors, and gradients, it essentially locks users in. Switch to another with a different configuration, and every font size, color, and gradient the user chose to use is gone. Imagine inserting a Paragraph block and choosing that sky blue from your theme as the block’s background. Now, imagine doing this a few hundred times only to have it disappear a couple of years down the road when you want to switch designs. I won’t dive into the technical details of how this works under the hood. It is just the way the system was designed. Some problems could have been mitigated early on, but that ship sailed two and a half years ago with the launch of WordPress 5.0. There are also ways this might be solved in the future with technical workarounds. Last week, a reader named Nick brought up this issue in regards to block patterns. The theme in question used custom CSS classes to achieve a specific design. Because Gutenberg lacks all the features mentioned above, the theme uses some custom CSS classes, and these classes are coded in the theme’s style sheet. The problem with this is that now that you have used these patterns, YOU ARE LOCKED IN to this theme. Because the moment you change themes, the new theme will not have these custom classes defined, the patterns will be broken. This is THE SAME reason why shortcodes were outlawed many years ago from inside the themes — and yet when it comes to patterns, this is somehow allowed? Note: Shortcodes were disallowed in the WordPress theme directory because the actual post content was broken on theme switch. It was unrelated to a broken design. I already hear what some of you are thinking. This is not the same as “content” lock-in. No, it is not. Not exactly. However, because the block system intertwines content and design, it sort of is. I doubt the average user appreciates the distinction when they end up in scenarios with white text on a white background, as shown in the following screenshots: Blue background with one theme. Blue background gone with second theme. That is a very real scenario. I see it almost daily as I test out different themes. And, this is just the beginning. As WordPress’s design system grows and themers can configure more pieces, users will become more locked into their existing theme. Or, they may be locked into one developer’s or one shop’s way of doing things. I do not necessarily see this as a Bad Thing. We have always had these little silos in the WordPress ecosystem, and they have mostly worked out. In a sense, little has changed. Users often stick with the same theme companies for one reason or another. And, those same themers tend to build on top of homegrown libraries or frameworks, reusing the same systems — at least the best ones do. This usually means that users can freely switch between themes made by the same people without losing anything. The old-school purity test of not mixing content and design is gone. This is a chance for solo developers and shops to strengthen their brand. If this is the system that WordPress is providing, build strong products on top of it. Build naming schemes that allow users to switch between your themes. Create loyal customers who will want to stick with you for years. If users are essentially locked into one shop’s theme products, that sounds like a lucrative opportunity to build solutions and healthy user communities around individual brands. I also envision a future where users will need to switch themes far less often. After the site editor and global styles features become available, users will have more direct control over their design. Once they have settled on a solid theme, they may never need to change it as long as it stays relatively up to date. Like this: Like Loading… [ad_2] Source link

Continue reading

Automattic Launches Mayland Blocks, Its Second FSE Theme on WordPress.org – WordPress Tavern

[ad_1] Automattic released its second block theme to the WordPress theme directory last week. Mayland Blocks is geared toward photographers and other users who want to showcase their projects. It is the child of Blockbase, a sort of starter/parent hybrid the company’s Theme Team recently announced. I had high hopes for Mayland Blocks going in. I have kept a loose eye on its GitHub repository in the last couple of months. It was one of the first 100% block-built themes the team seemed to be working on. While block themes are still experimental at this stage, I was admittedly disappointed. Maybe my expectations were too high. I was eager to be wowed when I should have gone into this review more level-headed. However, I am who I am, and that is someone who is genuinely excited each and every time a new block theme comes along. I am ready for the next big thing, but Mayland Blocks did not fit the bill. As I began the process of testing the theme, the first order of business was to recreate the Masonry gallery as shown in the theme’s screenshot: Expected gallery layout from Mayland Blocks My first thought was that the default gallery output would automagically work. It did not. Then, I looked for a Gallery block style. Nothing there. I searched for a custom pattern. Nothing there either. In short, it was impossible to recreate the gallery shown in the theme’s screenshot — one of the primary features that drew me to it. Bummer. I was looking forward to seeing a Masonry-style gallery of images built on top of the block system. Standard gallery output with Mayland Blocks. With a tiny bit of sleuthing and peeking under the hood of the theme’s demo on WordPress.com, I saw that it was using the CoBlocks plugin by GoDaddy. The thing that made the theme special had nothing to do with the theme. After a quick install, I converted my existing gallery to the CoBlocks Masonry block. Success! Masonry gallery output via CoBlocks. At that point, I began to wonder why I was even testing Mayland Blocks at all. Its claim to fame hinged on showcasing photography. The core Gallery block works well enough, and I can use CoBlocks with any theme. Most decent ones provide the sort of open-canvas template that is no different than Mayland’s front page. What would have made it a great theme would have been living up to its screenshot’s promise. This was also a missed opportunity to showcase some alternate Gallery block styles and patterns. If we want more users to buy into this system, some of our best design and development teams need to take that one extra step. For such a simple theme, one well-suited as a one-page design, this was the moment to lean into the photography angle. Provide users a Polaroid picture frame option: Add a “no gutter” block style: Bundle a few patterns that combine the Gallery block with others. Give us a little flavor. Mayland Blocks works well as a WordPress.com child theme because its suite of plugins is available to all users out of the box. For a publicly-released project on WordPress.org, it is a little disappointing that it was a straight port. The child theme is essentially its parent with an open-canvas front page template and some trivial font and color changes. Surprisingly, it made it into the theme directory with so few alterations. Two days later, another child theme was outright rejected for just adding “some minor changes which can be made directly from the parent theme.” The inconsistent application of the guidelines by different reviewers has long been a thorny issue, especially when more subjective rules come into play. However, block themes have more wiggle room at the moment. There are so few for users to test that it makes sense to let things slide. One of the Themes Team’s previous hard lines has been that bundled front page templates must respect the user’s reading settings. This meant that if a user explicitly chose to show blog posts on their front page, the theme must display those posts. Mayland Blocks is the first that I have seen get a pass on this, a hopeful sign of more leeway for directory-submitted themes in the future. Block themes are a different beast. HTML files are not dynamic, and there is no way to put a PHP conditional check in a front-page.html file in the same way as themers once did in a front-page.php template. There is a technical workaround for this, but I do not think it is necessary. Block themes are changing the game, and the guidelines will need to follow. I love seeing the contribution — any contribution, really — of another block theme to WordPress.org. However, I want to see more artistry on top of the Blockbase parent theme. Like this: Like Loading… [ad_2] Source link

Continue reading

Toolbelt Tidies WordPress Plugin and Theme Admin Notifications – WordPress Tavern

[ad_1] It’s a tale as old as, well, WordPress. Ben Gillbanks noticed a conversation where someone thought that admin notices were getting out of hand. Enter another developer’s attempt to address this problem. With a few code additions to his Toolbelt plugin, he had a working solution to stop the madness: the Tidy Notifications module. Despite the early promise of the WP Notify project last year, it still feels like we are no closer to addressing the overuse of the current admin notice system in WordPress. In reality, it is not so much a system as a hook that developers can use for literally anything. It is the Wild West of the WordPress admin. No rules. No order. And no proper API for standardizing how notices work. WP Notify still exists on GitHub and continues to move along at its own pace, but there is no guarantee that it will ever land in the core platform. Sometimes, the best thing a developer can do is solve the existing problem and hope that WordPress follows along down the road with a better solution. I am already tidying admin notifications with Toolbelt on my development install. My primary use case is to hide the non-dismissible notice from the Gutenberg plugin that I have a Full Site Editing theme installed — is there not a guideline against such notices? I did not suddenly forget that I was using such a theme between the 999th and 1,000th time the reminder appeared on every admin screen of my installation. Notifications expand when clicking on the bell icon in the toolbar. The Tidy Notifications system in Toolbelt neatly tucks all admin notices under a bell icon in the admin toolbar. It also displays the number of notifications. It makes the WordPress admin so clutter-free that I do not know how I have lived without it before. I cannot imagine going back. The only problem with Toolbelt’s solution is that there is no way to distinguish between essential notices and those that should be tucked away. WordPress letting you know that your post was successfully updated is an important notice that should not be hidden. However, a plugin author drumming up five-star reviews, yeah, that should not be front and center. Having two systems would be beneficial. The existing admin_notices hook in WordPress should be used for letting users know the outcome of their actions or actions that they should take. The post editor, which does not use page reloads or make the hook available, has replaced this with the snackbar popup system. These necessary notices have their place. However, WordPress has no built-in system for non-essential notices. This leaves plugin and theme authors with two options: bundle an entirely custom notification apparatus with each extension or just use the admin_notices hook. The latter is the more efficient use of developer resources. Of course, we have had this conversation before. Just shy of a year ago, I wrote a post titled Are Plugin Authors to Blame for the Poor Admin Notices Experience? In the comments, WordPress project lead Matt Mullenweg posited that the solution to unwanted notifications is not to build an inbox, comparing WordPress to cell phones. He said that app store guidelines were likely more impactful to user happiness. In general, I agree with that concept. Setting down a few directory UI and UX rules would not hurt. Given the more recent push to loosen guidelines for the theme directory, that does not seem to be in the cards. Admin notices were not one of the guardrails, the safety net of “must-haves” from the Themes Team. The admin notice spam WordPress users see today most commonly comes from plugins and not themes. Why? It is not because theme authors care more about user happiness levels. It is because the theme review guidelines over the years have been strict. Anything too flamboyant gets the hammer. The WordPress Themes Team even has a custom guideline-friendly, drop-in class that themers can use. The plugin and theme directories have taken far different stances on admin notices, and it shows. When the Themes Team moves to minimal checks, there may not be anything to stop themers from competing for the most obnoxious admin notice award. Game on, plugin authors. “Unwanted” notifications may even be the wrong terminology. Often, they are “unwanted right now.” Sometimes, folks might want to read a message — just later. I am still holding out hope that we will have a notifications/messages inbox in WordPress one day. One that is entirely controlled by the user. Until then, I may just stick with the Tidy Notifications module in Toolbelt. There are many other handy components in it too. Like this: Like Loading… [ad_2] Source link

Continue reading

Spice Up Your Food or Recipe Blog With the Nutmeg WordPress Theme – WordPress Tavern

[ad_1] Last week, Dumitru Brînzan announced Nutmeg Plus. It is the latest commercial theme offering through his ILOVEWP brand. Earlier today, the free version of Nutmeg landed in the WordPress theme directory. The theme is built for food and recipe bloggers and is another solid example of building on the block system. As is typical of his style, Nutmeg rests on a foundation of clean lines and readable typography. It pulls elements from some of Brînzan’s previous work, such as the featured pages section of Photozoom and the two-column intro from Endurance. Reusing code is one of the cornerstones of smart development. The theme never gets too flashy, nor is it a bold step forward in design. However, it has a timeless layout that is hard to go wrong with. Where it shines is in its use of block patterns and styles. Recipe post built with Nutmeg. Sometimes, theme authors surprise me with, in hindsight, simple solutions. Nutmeg’s List block styles had me asking, “Why didn’t I think of that?” Last month, I challenged theme authors to build out patterns that are often created as custom blocks. In the post, I showcased an example of how themers could provide pricing columns for their users. The Nutmeg theme is a perfect example of that same concept, only applied to recipes. The unique aspect is that Brînzan did not make it complex. With a few simple styles for the List block, he had all the makings of the typical “recipe card” seen on many food blogs. Is it as advanced as a fully-featured recipe card plugin? No. But, that should not be the goal. If users need more advanced recipe-related features and functionality, that is where plugins make sense. The theme even recommends a few like WP Recipe Maker, Recipe Card Blocks, and Delicious Recipes for those who need more. However, for bloggers who are just starting, undecided on recipe plugins, or simply do not want another dependency, the theme has built-in solutions for them. It is tough to discount the value in that. Adding instructions and ingredients. With a starting point of the Recipe Info, Ingredients List, or Ingredients + Instructions patterns, users can quickly pop these sections into their content. Or, they can go the alternate route of starting with the List block and selecting one of four custom styles. Theme authors should be able to build unique and complex combinations of blocks with custom styles. Users should be able to just make it look like the demo. Block Patterns Will Change Everything It was March 2020. The Gutenberg development team had just pushed block patterns into the plugin, but the feature would not land in core WordPress for months. I do not want to call myself a prophet. It was plain enough for anyone to see: block patterns would eventually change how end-users interact with the editor and build their sites. Patterns were the answer to elaborate homepage setups. Instead of jumping back and forth between non-standard theme options, hoping for the best from a theming community that never learned to entirely leverage the customizer, users could simply click buttons and insert layout sections where they wanted. Recreating Nutmeg’s homepage demo was easy. By just picking a few patterns and adding some custom images, I was up and running in minutes. No tutorial necessary. No half-hour session of figuring out a theme’s custom options setup. Select the custom homepage template. Add the Cover with Overlay pattern and upload an image. Drop in the Opening Message pattern and customize. Insert the Featured Pages pattern and add images. Homepage built from patterns. Simple setup processes like this are the exact thing that theme authors have been repeatedly asking about for the better part of a decade. Except for a powerful Query solution, which is arriving in a limited form in WordPress 5.8 (the Post Featured Image block is the weak point), the tools are mostly in place. The feature set is only growing with each release. One of my favorite solutions in the theme is the use of the Cover block’s inner container. The plugin has several styles for moving this inside box around and creating a featured section. Customizing the Cover block with styles. One improvement I might suggest is to provide “width” styles for the inner container here. Core already provides an alignment matrix option. Styles for 25%, 50%, and 75% width (100% being the default) would offer more variety when coupled with the existing alignments. The only things that felt out of place with the theme were its alignment block styles for Heading and Paragraph blocks. WordPress already provides alignment options for these blocks. I am not sure if there is a use case that I am unaware of for the styles, but they were definitely confusing. The theme is worth a test run for any food or recipe bloggers who need a dash of Nutmeg to spice up their site. Like this: Like Loading… [ad_2] Source link

Continue reading
1 2 3