Tag Archives: Tavern

BuddyPress 9.0 Scheduled for Short Development Cycle to Ship Block-Based Widgets Ahead of WordPress 5.8 – WP Tavern

[ad_1] BuddyPress 8.0 was just released earlier this month on June 6, but the core development team is gearing up for a short development cycle for 9.0. The release will be specifically targeted at getting BuddyPress core widgets ready for WordPress 5.8’s new block widgets experience. Contributors are aiming to hit the following timeline to ship 9.0 before the next major WordPress release: Beta: July 8. RC: July 12. Final: July 16 BuddyPress entered the world of blocks with the release of version 6.0 in May 2020, allowing users to insert a specific Member or Group into content. Version 7.0, released six months later, introduced blocks for featuring a list of members, a list of groups, and the ability to embed a public activity post. Over the next few weeks, BuddyPress contributors will continue the process of migrating the rest of the BuddyPress component widgets to blocks. These include the following: Blogs Recent Posts Widget: A list of recently published posts from across the network BP Core Login Widget: Shows a Log In form to logged-out visitors, and a Log Out link to those who are logged in BP Core Friends Widget: A dynamic list of recently active, popular, and newest Friends of the displayed member. Widget is only shown when viewing a member profile BP Groups Widget: A dynamic list of recently active, popular, newest, or alphabetical groups BP Core Members Widget: A dynamic list of recently active, popular, and newest members BP Core Recently Active Widget: Profile photos of recently active members BP Core Who’s Online Widget: Profile photos of online users BP Messages Sitewide Notices Widget: Display Sitewide Notices posted by the site administrator BP Nouveau widgets: BP Latest Activities: Display the latest updates of your community having the types of your choice BP Nouveau Navigation Widget: Displays BuddyPress primary nav in the sidebar of the site. (Must be used as the first widget of the sidebar and only once.) In addition to building a block for every BuddyPress widget, contributors are aiming to make it possible to transform existing BP widgets into their corresponding BP block. With the new block widgets screen imminently landing in WordPress, BuddyPress has to make this move forward to keep pace with the progress of the block editor’s march beyond use in the content editor. Otherwise, BuddyPress users would need to disable block widgets with the Classic Widgets plugin in order to maintain access to BuddyPress core widgets. Contributors are also working on creating a new Follow component, a frequently requested feature which would use the now abandoned BuddyPress Follow plugin as inspiration. The feature will work similar to Twitter following or the Facebook follow button that allows users to see public activity posts for those they are following. The Follow component is being built as a plugin first and will ship with 9.0 if it is ready in time. Like this: Like Loading… [ad_2] Source link

Continue reading

Diving Into WordPress 5.8’s New Widgets Screen – WP Tavern

[ad_1] It has been a while since I have touched widgets. Once the site editor landed in the Gutenberg plugin, I almost exclusively dropped the old sidebar paradigm and moved to block templates. Reactivating old themes and jumping into the widgets screen felt like time-traveling into a bygone era. After months of being deeply embedded within block themes, it is hard to imagine moving back to the sidebar widgets system that most WordPress users are still using today. WordPress 5.8 is slated to ship with a small taste of bringing blocks outside of the content editor. However, it can feel like a surface-level refresh of a dying system, one that does not always work. Block-based widgets are part of the transitional phase between classic WordPress and the future, which centers on a complete site editor. Once the bulk of themes are built atop blocks, the need for widgets will wane. The site editor and block themes do not support the old sidebar system. Instead, users will be able to place blocks anywhere. Last October, I asked the question: Are Block-Based Widgets Ready To Land in WordPress 5.6? At the time, the widgets screen was expected to launch with the final release of 2020. However, the development team pulled back on the feature’s inclusion, primarily because the customizer implementation was sub-par. Asking the same question of WordPress 5.8, my answer is mostly the same. It is time to ship the current feature and prepare for a future without widgets. There are so many components that are far more exciting around the corner. The primary user-experience issues will linger around until users have moved on to block themes. I have long been in the camp of starting from a clean slate for block themes, letting widgets die out. However, the path WordPress has chosen is to create this stepping stone for users who may be on traditional themes for a while. It provides an opportunity to use blocks outside of the editor, which may be a leap forward for many. With the vast number of libraries, one-off blocks, and support from plugin authors, users have a wealth of block choices at their fingertips. Right now, if there is no equivalent widget, those users can only ever use those blocks in their content. Within a block-widget system, that limitation does not exist. It also lifts some burdens from developers. Those who want to shed some of their old code and go all-in on blocks can begin considering deprecating or retiring widgets. Transitioning to the new Widgets screen should feel simple to users familiar with the WordPress content editor. Inserting blocks is the same. The difference is that each sidebar has its own container. Widgets screen with a Gallery block in the Footer sidebar. The range of blocks within core WordPress could also let users drop some of their widgets-based plugins. One of the most popular types of widgets over the years has been for handling post lists. There are dozens of such plugins and an untold number of themes that include one. Coupled with WordPress 5.8’s Query Loop block, users can now recreate many of those widgets themselves. Custom post list using the Query Loop block. Much of this depends on the theme’s design support of blocks and whether it will accommodate anything other than traditional widgets. Customizer support for block widgets is lightyears ahead of where it was just a few short months ago. However, it feels awkward at best. There is a deep feeling of not belonging. While it was a remarkable programming feat to make the two features work together, the user experiences are nearly a decade apart. Editing a Heading block in the customizer. Despite the customizer providing a live preview, the Widgets screen in the WordPress admin gives the necessary workspace. Trying to squeeze the block editor into the tiny customize controls panel was never going to be an ideal experience, and it still is not. It gets the job done, but I recommend the traditional widgets screen for fewer headaches. Problems Remain In the eight months since I first dived into the block-based widgets, the system has been overhauled. However, the potential issues I brought up remain. Just dropping blocks into a sidebar can have mixed results. For example, compare a Legacy Widget to Heading and Latest Comments blocks in the footer sidebar of the popular OceanWP theme: Mismatched headings and colors. The issue is that WordPress treats every block as a widget. Traditionally, widgets have had both a title and content. Blocks have no such concept. A Heading followed by something like a Paragraph, Latest Comments, or another block has no special meaning in the block system. They are all treated separately. This issue is in full view when adding blocks to the default Twenty Twenty-One WordPress theme: Block treated as widget in Twenty Twenty-One footer sidebar. Notice the Heading and Latest Comments blocks are columnized because they are seen as separate widgets. To address this, users must add multiple blocks into a Group block if they want them treated as a single “widget.” It is a simple matter, but it could still be a usability hurdle for some. Even with a fix in place, there is no guarantee that blocks will appear as the widgets the theme author intended. I long ago gave up on the hope that there would be better handling for block widgets. The Classic Widgets plugin is available for those who need it, and theme authors can opt-out. These are necessary tools for an experience that can range from downright awesome to utterly broken. Bringing blocks outside of the content editor for traditional theme users is probably necessary for the transition, but the current site editor experience already feels much smoother than block widgets. The long-term focus should be on moving away from the dated concept of widgets and into a WordPress front-end 100% built on blocks. Like this: Like Loading… [ad_2] Source link

Continue reading

Major Revamp Coming to GitHub Issues – WP Tavern

[ad_1] This week GitHub unveiled new features that will be included in a total revamp of GitHub Issues, including project tables that are similar to spreadsheets, custom fields, a keyboard driven command palette, improved task lists, and issue forms. The new project table view is an alternative to project boards, allowing users to filter, sort, and group issues and pull requests. Project managers can customize the table with custom fields and saved views. GitHub is also making it easier to manage issues that include subtasks. Users can now add lists and the issue will automatically track the status with a progress indicator. Issues forms are now in beta for public repositories. Many open source projects currently use Markdown issue templates and encourage contributors to provide more details by removing the placeholder text and replacing it with their own. Maintainers can now set up YAML configured forms with required fields and instructions to better guide the process. The revamped Issues feature is being updated to provide a bridge between the planning tools and the problems the tools were created to solve. Mario Rodriguez, Head of Product for GitHub Enterprise, explained why they are evolving GitHub Issues in the beta announcement: As teams and projects grow, the way you work evolves. Tools that hard-code a specific methodology are too rigid and complex to flex to whatever the moment demands. Often, we find ourselves creating a spreadsheet or pulling out a notepad, just to have the freedom to think. But then our planning is disconnected from where the work happens and quickly goes stale. The WordPress project hasn’t yet moved away from Trac but most of Gutenberg development happens on GitHub. It’s also the most popular repository hosting site for WordPress theme and plugin authors. Contributors to these projects may soon see some of these features in action for personal accounts and organizations that opt into the beta. The new GitHub Issues is expected to be out of beta later this year. GitHub plans to bundle it for free, along with the new project planning capabilities, with its Free, Pro, Team, and Enterprise plans. Like this: Like Loading… [ad_2] Source link

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

Gutenberg 10.9 Renames the Query Block, Adds Collapsible List View Items, and Rolls Out Rich URL Previews – WP Tavern

[ad_1] Yesterday, Gutenberg 10.9 landed in the WordPress plugin directory. The update overhauls the Query and Query Loop blocks, allows users to expand or collapse items in the editor list view, and introduces rich URL preview cards for links. The new version also packs in an updated template-mode creation modal and moves the blocks manager. This update ships several enhancements, particularly to the user experience. One of my favorite low-key upgrades is a new set of add-card, bug, key, post author, and security icons by Filipe Varela, a product designer at Automattic. Another small-but-packs-a-punch UI change is the inclusion of the post type in the editor breadcrumb trail. The type’s singular name label now replaces the root “Document” item. For the past several cycles, the new template editor slated to launch with WordPress 5.8 has been enabled by default. The goal was always to allow everyone the chance to experience it, regardless of whether they were on a classic or block theme. The development team has now scaled this back to only be auto-enabled for block themes. Classic themes must opt-in to support it. Theme authors should read the recent template editor overview by Riad Benguella for the complete details. Query and Query Loop Blocks Renamed Query Loop block in the editor. Query? Query Loop? What the heck is all this? If you are unfamiliar with those terms, you are not alone. Even on the developer end, the early implementation of the Query and its inner Query Loop block could be a little confusing. For the average user, it probably makes even less sense. Gutenberg 10.9 takes one step toward clearing up this confusion for end-users. The former Query Loop block is now named Post Template. This is a far more accurate description of what it does. It is the “template” that outputs individual posts. It contains all the things you see, such as the post content or excerpt, the featured image, tags, categories, and more. This template is, of course, customizable via the block editor. While this is a step toward a less complex user experience, it is not quite where it needs to be yet. The Query block has been renamed to Query Loop. Therein lies the remaining issue. The terminology might not still be confusing. The goal is to expose a variation of this block named Posts List to users. It already exists, but the query-related terminology still appears when using it. There is an open ticket to address this. The primary win with this update is the overhauled text in the Query Loop block sidebar. “The query block is a powerful and complex block,” said lead Gutenberg developer Matias Ventura in a GitHub ticket. “It can be intimidated to users without proper guidance. We can use this block as an opportunity to explain some of the underlying concepts of the WordPress software in a more didactic manner.” The more advanced options, such as whether to inherit from the URL and which post types to include, now have longer descriptions. Each should guide the user through features that have long existed in the developer world. If you are a theme author and have already been building with these two blocks, do not worry about everything breaking when updating. The Query block has simply been renamed to “Query Loop” in user-facing text. Under the hood, it is still the same. The former Query Loop block has literally been renamed to Post Template (core/post-template block name). It is backward compatible. However, you should update any past calls to the wp:query-loop block to wp:post-template. Expand and Collapse Nested List View Blocks List view with collapsed nested blocks. The development team introduced an expand/collapse feature for the editor’s list view. Once opening the panel, users should now see arrow icons next to each item with nested blocks. Closing one or more of them makes it easier to see all or many top-level blocks at once. The downside is that the open/close state is lost once the list view is closed. If I had one request, it would be to store this data while editing the post. That would improve the user experience with longer documents, particularly when switching between navigating and editing. This update, along with the persistent behavior of the list view in Gutenberg 10.7, has made for a much more well-rounded document navigation experience. Rich URL Previews The editor will now show a website preview in the link editor popup. This feature only works for links in a Rich Text context, such as in the Paragraph, Heading, and List blocks. The preview also only appears after the link has been set and clicked on, not when initially typing it. If available, the popup preview displays the site icon, title, image, and description. “In the near future however, we expect to extend this to provide previews of internal URLs and to roll out support to more areas of the software,” wrote George Mamadashvili in the Gutenberg 10.9 announcement post. Admittedly, I was not keen on the idea of adding this feature. It felt like unnecessary bloat when more pressing issues were lying on the table. However, in the past day, I have enjoyed the quick previews when double-checking links in posts. Like this: Like Loading… [ad_2] Source link

Continue reading

Jetpack Launches New Mobile App – WP Tavern

[ad_1] Automattic has launched a new mobile app for Jetpack, available on iOS and Android. The app features an array of Jetpack-specific features, as well as those applicable to users on paid plans, along with core WordPress features. Inside it looks nearly identical to the official WordPress mobile apps, but it is noticeably missing WordPress.com specific features like the Reader. The bottom menu links to “My Site” and “Notifications.” Those who are on paid Jetpack plans will have access to features like backups, restores, and security scanning for use inside the app when on the go. It also includes the same Activity Log and Stats features found in the main WordPress app. In its current state, it doesn’t look like the app offers anything more than what you are used to on the standard mobile apps unless you are a paid Jetpack customer. So far, the app doesn’t include any upgrade paths for free users or to jump from plan to plan. If Automattic decides to add in-app purchases, it will have to share the revenue with the app stores. Having a separate app from the official mobile apps gives the company the option to build in more direct paths for monetization in the future. You may want to stick with the official WordPress apps if you manage both WordPress.com and Jetpack-enabled sites, to keep everything conveniently in the same place. If you decide to use both apps, you will want to remove your Jetpack sites from the main WordPress app so that you aren’t getting double notifications from having the site accessible through both apps. Automattic’s integrated products remain controversial features of the official WordPress apps. It is a good move to separate self-hosted Jetpack sites from the clutter of having WordPress.com-specific features in the app, but it does little for improving the official app’s experience for self-hosted users who are not using Jetpack. Clicking on Stats in the app still prompts users to install Jetpack when managing self-hosted sites. The Reader menu item is ever-present at the bottom of the page. These products take up screen real estate regardless of whether they are being used. A toggle to turn off these features in the app’s settings might be a good stop-gap measure towards disentanglement, but ultimately the official mobile apps should not promote any commercial interests. If Automattic moved WordPress.com features into the Jetpack app, then anyone using the company’s products could be directed to this app for managing their sites. The official WordPress app could then be kept free of any products that the user doesn’t choose to install. If the vanilla state of the app is not enough, users can be prompted to add themes and plugins to enhance the WordPress experience. The Jetpack app is aimed at people who have sites using Jetpack but don’t need the WordPress.com features that are built into the official WordPress apps. It brings more value to those who are on paid plans and want access to those features on the go. More than 500 people have already downloaded the Android app. It will be interesting to see if Jetpack users will gravitate towards the new app or remain on the standard WordPress app for more centralized management of Jetpack and non-Jetpack enabled websites. Like this: Like Loading… [ad_2] Source link

Continue reading

A Showcase of Block Patterns by Anariel Design – WP Tavern

[ad_1] Clove theme homepage. Earlier today, Ana Segota tweeted and announced via the Anariel Design blog that her company had submitted its second block-based theme to WordPress.org. Clove is a more well-rounded follow-up to her first such theme, Naledi. It is currently under review for inclusion in the official directory, but anyone can give it a test run by snagging the ZIP file from its ticket. Or, just peruse the live demo. This should officially be the 10th block-based theme to go live in the WordPress.org theme directory (note that a couple by Automattic are not tagged). That is assuming all goes well during the review process. It has been a long road thus far, but 10 themes with the Full Site Editing tag is a notable milestone. The Q theme by Ari Stathopoulos was the first to land in the directory back in October 2020. Now, eight months later, there is still room for other theme authors to become pioneers in the space. With almost no competition, who will design that first block theme that squeezes its way into the most popular list? If “practice makes perfect,” Segota is now ahead of the curve by pushing her second theme to the directory. This makes her theme company only one of two with multiple block themes. Clove is experimental, as all block themes are. It relies on the ever-shifting parts of the Gutenberg plugin, but it all comes together into a floral, nature-themed design. There are hints of inspiration from Twenty Twenty-One, but it feels more structured, less chaotic. The design is less of a theme and more of a showcase of block patterns and styles. Even on the template level, it reuses those same elements across each of its seven templates, providing multiple entryways for users to tinker with its features. Clove even includes pricing columns. I seem to recall writing about how theme authors could implement them via patterns just over a month ago. Maybe the Anariel Design team came to the same conclusion. Maybe they took my message and ran with it. I like to think the latter is true. Either way, the result is a beautiful, theme-specific pattern — the sort of artistry that is tough to achieve from a plugin. Customizing the Pricing Columns pattern in the WordPress editor. I am less of the fan of the overlapping and uneven columns in some of the designs designs, preferring some of the more-structured patterns, such as Three Quotes Images: Three-column pattern that showcases images along with quotes. Despite my general dislike of the uneven column style, my favorite piece of the entire theme is the Illustrations page template, which leans into that design method. The page intro section is an announcement to the world, “Hey, check out my work.” Illustrations template intro section. I also like the Illustrations page template’s widgets-like area in the footer. It manages to stuff several blocks in without feeling too crowded. It even showcases a box for artists to highlight their next exhibition. Illustrations page template footer “widget” area. The Clove theme also registers 10 block styles for users to choose from. Most of them add different types of borders or frames to various elements. Plus, there is the fun-but-kind-of-an-oddball blob “Shape” for images. Segota was one of several people to submit custom designs to the upcoming block pattern directory. There is some noticeable crossover between her current theme work and submissions, such as the Playful Gallery pattern that did not quite make the cut. Others, like her Recipe design, did. There is still an open invitation for people to contribute. I am always like a kid in a toy store when a new block theme comes along, reaching out to grab the latest gadget. I want to see more experiments like Clove. Keep them coming, theme authors. Side note: For people interested in the background-clipped text design used in Clove’s site logo, I opened a ticket to take us one step closer to doing it in the editor. Currently, users must create an off-site image and upload it. Like this: Like Loading… [ad_2] Source link

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

WooCommerce Selects Paystack as Preferred Payments Partner in Africa – WordPress Tavern

[ad_1] WooCommerce has named Paystack its preferred payments partner for WooCommerce in Africa. More than 20,000 merchants are using the free Paystack WooCommerce Payment Gateway plugin but searching for and downloading the plugin separately is no longer required. Store owners can now easily select Paystack as a payment method when inside the WooCommerce dashboard. Paystack has a recently updated tutorial for how to set up the gateway in WooCommerce. As an alternative to the recommended method, merchants can opt to install the free plugin instead. Paystack is the most widely used payment gateway in Africa, accounting for more than half of all online transactions in Nigeria. More than 60,000 stores use the gateway. In October 2020, it was acquired by Stripe for more than $200M. The gateway can be used by businesses in Nigeria and Ghana and last month it added support for South Africa, after a six-month long pilot program. “Paystack is leading the charge in bringing a world-class payments experience to African merchants,” WooCommerce Director of Business Development Mechiel Couvaras said. “Their product offering, user experience, and expansion plans within Africa were some of the most important factors in considering the partnership. Receiving funding from  Stripe and Visa was also a strong indicator of their potential.” Paystack, like all of WooCommerce’s other payment partners, has a financial arrangement with the e-commerce platform where it pays a percentage of transactions processed. Couvaras said the Paystack partnership is directly with Paystack and separate from WooCommerce’s Stripe partnership. “eCommerce is still very nascent in most African countries, however, Nigeria and South Africa are amongst our fastest growing countries globally,” Couvaras said. When Stripe acquired Paystack, the company noted that African online commerce is growing 21% year-over-year, 75% faster than the global average. WooCommerce is well-positioned to capture some of that growth with Paystack pre-installed as a preferred payment partner. The e-commerce platform is also keeping tabs on other emerging markets, as global market adoption has grown to 8.2% of the Alexa top 10 million websites. Over the past year WooCommerce launched partnerships with Indian payment companies Razorpay and PayU India, as well as Mercado Pago, a Latin American payments company focused on supporting local payment methods across Mexico, Brazil, Argentina, Colombia, Chile, Peru and Uruguay. Like this: Like Loading… [ad_2] Source link

Continue reading

Refreshing Old Twenty* WordPress Themes With Block Patterns – WordPress Tavern

[ad_1] What began as a project in August 2020 has now become a reality. All past Twenty* default WordPress themes now have their own unique block patterns. In recent weeks, Twenty Ten through Twenty Fifteen received updates. Designer Mel Choyce-Dwan kick-started tickets for all previous 10 default themes before the WordPress 5.5 release, the first version to support patterns. Twenty Twenty, Twenty Nineteen, Twenty Seventeen, and Twenty Sixteen each made the cut for that update. However, the remaining default themes were left to languish, at least for a few months and WordPress updates. Jumping back over a decade to update past themes might seem extreme, but all of the default themes are still some of the most popular from the directory. Granted, they had the benefit of being installed directly in WordPress. Still, the current number of active installations means they are worth a small refresh: Twenty Fifteen: 100,000+ Twenty Fourteen: 100,000+ Twenty Thirteen: 70,000+ Twenty Twelve: 100,000+ Twenty Eleven: 100,000+ Twenty Ten: 100,000+ Despite having the lowest installation total, Twenty Thirteen has some of the best pattern designs. The Informational Section and Decorative Gallery patterns stand out the most, but all fit well with the overall theme design. Informational Section Decorative Gallery Twenty Thirteen is also the only remaining default theme that supports wide and full alignments. Its one-column layout affords it more flexibility, and the old design feels fresh again with its new pattern choices. Perhaps they can revive the theme’s lagging numbers relative to the other defaults. The initial pattern designs for the theme included a suite of layouts for post formats, one of the features Twenty Thirteen leaned on. Something similar to the first gallery design landed, but the others were left out. Patterns designed to match post formats. Post formats never garnered widespread support past their launch, and the core development team all but abandoned them, never building atop the feature. However, all of the format-specific patterns might be welcome for those users still running the theme. They would have been a nostalgic nod to the old WordPress, a throwback to yesteryear. If nothing else, maybe they can serve as inspiration for those of us still clinging to that tiny sliver of hope that post formats will make a roaring comeback. These theme-bundled designs highlight how the upcoming pattern directory is not meant to be the only destination for snagging the best layout sections to drop into the block editor. Often, the best choices will be specific to the theme. Much of the flavor of custom design is lost when building for a general audience. What looks good with Twenty Twenty-One may look terrible in another and vice versa. Maybe that will change as block design tools become more robust and how they are used becomes standardized, but for now, at least, the most artistic patterns are those that designers include with their themes. Aside from Twenty Thirteen, Twenty Ten’s new patterns stood out the most. The theme was the first of the new era of yearly themes, and its classic blog design has weathered the years well — just ignore the 12-pixel sidebar font size. Twenty Ten’s new patterns. The three patterns are at home in the theme. The Introduction pattern, which showcases the Image, Heading, and Paragraph blocks, is simple, but it relies on Twenty Ten’s typography for an elegant article intro. The Quote and Alternating image layouts do not try to do too much, simply highlighting the theme’s design. Landing squarely in my favorite-but-most-disappointing category was Twenty Fourteen. The About pattern’s image and text looked elegant and roomy in the editor, but the front-end view painted a different picture. Because the theme lacks wide-alignment support, the photo was scrunched up. The gallery-supported Summary pattern has a lot of potential as a full-width pattern, but it falls short in the theme’s 474-pixel wide content area. About Pattern Summary Pattern There is really no reason why Twenty Fourteen could not support wide and full alignments. It has free space. At least the timeline-esque List pattern is pretty sweet in both the editor and front-end views. I may borrow that for my own projects. List pattern included with Twenty Fourteen. I was not particularly excited over the other patterns, but I am happy to see a little love thrown toward the 600,000 or so users with these themes still active. I am sure many will find something they can use on their own sites. The themes are aging; the wrinkles and weaknesses of their designs are showing. With the site editor looming ahead, it might be time to consider retiring them. That is assuming no one wants to take the reigns and update them for a modern era. Otherwise, they will continue falling behind, remaining a relic of classic WordPress. Like this: Like Loading… [ad_2] Source link

Continue reading
1 … 15 16 17 18 19 20