[ad_1] Security Review Lead Chris Christoff has announced two new changes for the WordPress Plugin Directory, effective from October 1, 2024. These changes aim to enhance plugin directory security and promote best practices among plugin developers. Mandatory Two-Factor Authentication As of October 1, 2024, all plugin owners and committers must enable Two-Factor Authentication (2FA) to submit new plugins to the WordPress Plugin Directory. This change was announced by Automattic-sponsored developer Dion Hulse last month. Plugin owners are encouraged to enable 2FA, review committers’ access levels, and use additional security features like the SVN password option and Release Confirmation. Detailed guides on Configuring Two-Factor Authentication and Keeping Your Plugin Committer Accounts Secure are also available. Plugin Check Tool From now on, any new plugin submitted to the Plugin Directory will first go through a pre-submission check using the Plugin Check tool. If any errors are found, the submission will be blocked until they are fixed. This new step aims to reduce the review queue by enabling plugin authors to catch common issues before submitting their plugins for manual review. Plugin Check helps by identifying frequent issues, such as mismatched versions between the plugin header and the readme.txt file, incorrect text domains, and erroneous “Tested To” values in the readme. Although Plugin Check adds a layer of automation, it will not replace the manual review of plugins. David Perez from the Plugin Review Team recommended making Plugin Check a part of the development workflow as “In addition to things relevant for the review process, the tool flags violations or concerns around plugin development best practices, from basic requirements like correct usage of internationalization functions to accessibility, performance, and security best practices. It does so using both static checks using PHP_CodeSniffer and dynamic checks, where it actually activates your plugin to test it “live”.” The Plugins Team is working to expand Plugin Check’s coverage to existing plugins. A roadmap detailing this broader application will be released in the coming months. Contributors can help improve the tool via its GitHub Repo. The WordPress community has responded positively to these updates. Josepha Haden Chomphosy tweeted “This was years in the making and is a huge deal. Congratulations (and big thanks) to everyone who contributed!” These two measures are expected to help the WordPress Plugin Team improve the security of the platform while reducing the backlog of plugins awaiting approval. [ad_2] Source link
Continue readingTag Archives: plugin
An Easy to Use and Fully Loaded Membership Plugin
[ad_1] Building a membership website is a fantastic business idea. You can earn recurring income, enjoy the freedom to create content as you wish, and commit to your user base with value products and services. As this Paid Memberships Pro review will show, there are plugins that can do the job, and then some. That functionality can also help with other business models too, such as creating customer email lists, and building a community. I have to do both of these as part of my relationship with WordPress, so I’m excited to take this plugin for a spin. Throughout this Paid Memberships Pro review, I’ll look at why the features, functionality, interface, and pricing are all stellar. By the end, you’ll know just why I’m a fan, along with thousands of other users! Introducing Paid Memberships Pro Paid Memberships Pro does what it says on the tin. It’s a WordPress membership plugin that lets you sign up users to access your website’s content. The plugin focuses on facilitating user memberships, but its feature set has a lot of scope. As you’ll understand, that functionality can work for many different types of site that center around curating users and building a community ‘hub’. Speaking of which, here’s what Paid Memberships Pro offers in a nutshell: Content restriction and drip feeding for the whole site, and on a page-by-page basis. The ability to set up groups and member directories, to help you build a community with your site. Plenty of user management options, tier creation settings, and administration tools. Multiple payment options, including account pauses and proration. This isn’t everything the plugin can offer, but I’ll show you throughout the rest of this Paid Memberships Pro review what the plugin can do. DOWNLOAD Paid Memberships Pro Paid Memberships Pro Review: The Plugin’s Feature, Functionality, and Pricing Rather than simply tour the dashboard and run through the feature set, I want to explore what Paid Memberships Pro is like on a day-to-day basis. As such, I’ll work within the dashboard, set the plugin up, add memberships tiers, and look into extending the functionality of the plugin. Of course, to follow along, you’ll need your own copy of Paid Memberships Pro. Let’s start with how much the plugin costs. Pricing While there’s a free version of Paid Memberships Pro on the WordPress Plugin Directory, that’s not my focus here. Instead, I’m looking at the three premium tiers on offer. These will bundle in extras to the core plugin based on the plan you choose: Standard ($347 per year). This gives you a single-site license, more than 20 add-ons (more of which later), and functionality such as customization recipes, tracking for affiliates, e-commerce, and analytics, along with plenty more. Plus ($597 per year). While two site licenses seems ‘ungenerous’, I can’t deny the functionality you get in return. This tier comes with the full feature set of Paid Memberships Pro, which includes over 30 add-ons, pro-rata pricing options, variable pricing, and much more. Enterprise (over $5,000 per year). The plugin’s functionality is here in full too, but includes 50 site licenses, hosting, and a more personalized experience for your needs. For instance, there is telephone support, consultancy, onsite visits, and more. For most, the Plus plan will give you everything Paid Membership Pro has in the box, but you’ll pay a hefty price in return. However, each purchase comes with a 100-Day, 100 percent money-back guarantee. What’s more, there are regular sales on offer, which sometimes gives you 50 percent off of the typical price. New User Onboarding Once you complete the installation process, you’ll begin with an onboarding wizard. This asks you to fill in a number of fields across five different pages. There are a few key fields to discuss here: General Info. You’ll want to make sure the plugin generates the required pages to help build your site. Fortunately, this is an active checkbox by default – but make sure to take a second look before you continue. Also, check the box to indicate whether you will take payments on your site, and enter your license key to claim your extra functionality, support, and updates. Memberships. It’s up to you whether you let the plugin create membership levels for you at this screen. If you are new to the plugin, I’d recommend this so you can see the ‘optimal’ method of doing this. The final screen – All Set! – lets you know your site is ready, and offers up a helpful guide on building the type of membership site you chose from the General Info screen. You’ll also find some recommended add-ons, which we’ll get into later. Before that, I want to cover the rest of the typical process you’ll take to create your membership site. The User Interface (UI) and Experience The Memberships > Dashboard screen within WordPress is the hub for everything you do with Paid Memberships Pro: There’s a lot to get through here, and I won’t cover it all. However, there are seven top-level sections of settings: Dashboard. This gives you quick links to common pages, some analytics and reporting, along with links to social media and documentation. Members. Here, you can create, add, manage, and delete members of your site. Orders. In this context, “orders” means those who purchase a membership. If you only offer premium memberships, this will essentially show your current paying set of members. Reports. This screen shows the same reporting as on the Dashboard. You can see your active members, sales, revenue, visits, logins, and much more here. Settings. This is a collection of many screens that cover options for membership levels, payment gateways, security, design, and a lot more. Add Ons. You can install any Paid Memberships Pro add-on you have access to here. It looks a lot like the WordPress Plugin Directory dashboard, which makes it straightforward to use. License. This is where you’ll input and view your plugin licensing information. You should take a look at the setup
Continue readingWordPress.org Introduces New Security Measures for Plugin and Theme Authors – WP Tavern
[ad_1] Starting October 1st, 2024, WordPress.org will roll out new security measures aimed at enhancing the safety of accounts with commit access to plugins and themes. This was announced by the Automattic-sponsored developer Dion Hulse. Mandatory Two-Factor Authentication Beginning next month, WordPress.org will make two-factor authentication (2FA) mandatory for all plugin and theme authors. Authors can configure 2FA by visiting their WordPress.org profiles, and the platform has already started prompting them to do so. Dion Hulse emphasized the importance of securely storing backup codes, as losing access to both 2FA methods and backup codes could complicate account recovery. SVN Passwords for Commit Access WordPress.org will also introduce SVN passwords for committing changes to plugins and themes. This feature separates commit access from the main WordPress.org account credentials, offering an extra layer of security. Authors can generate SVN passwords through their profiles, ensuring that their main account passwords are protected. Those using deployment scripts, like GitHub Actions, will need to update their stored passwords with these new SVN credentials. For those wondering why the Plugin Review Team is not using 2FA with SVN, Dion explained, “Due to technical limitations, 2FA cannot be applied to our existing code repositories, that’s why we’ve chosen to secure WordPress.org code through a combination of account-level two-factor authentication, high-entropy SVN passwords, and other deploy-time security features (such as Release Confirmations).” For more information, authors can refer to the guides on Configuring Two-Factor Authentication and Subversion Access and Chris Christoff’s post on Keeping Your Plugin Committer Accounts Secure Community Reaction The community has reacted positively to these changes, with some expressing that these updates were long overdue. “At least we were earlier than someone stepping on Mars, ” joked developer Toma Todua. Recently, the WordPress Plugin Team has ramped up efforts to enhance platform security. In June, they temporarily halted plugin releases and forced all plugin authors to reset their passwords after five WordPress.org user accounts were compromised. [ad_2] Source link
Continue readingRemote Code Execution Vulnerability Patched in WPML WordPress Plugin – WP Tavern
[ad_1] The popular WordPress Multilingual plugin, WPML, which is installed on over 1,000,000 websites, has patched a Remote Code Execution (RCE) vulnerability (CVE-2024-6386) that researchers have classified as “Critical,” with a CVSS score of 9.9. Users are strongly advised to update their websites to the patched version, WPML 4.6.13. Security researcher Mat Rollings (stealthcopter) discovered and reported the vulnerability through the Wordfence Bug Bounty program, earning a bounty of $1,639. Wordfence’s István Márton explained: “The WPML plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 4.6.12 via Twig Server-Side Template Injection. This is due to missing input validation and sanitization on the render function. This makes it possible for authenticated attackers, with Contributor-level access and above, to execute code on the server.” Matt Rollings dubbed this vulnerability “a classic example of the dangers of improper input sanitization in templating engines” and has shared more technical details about this vulnerability on his blog. In the past eight days, researchers have earned $21,037 as bounties for reporting three critical plugin vulnerabilities: GiveWP, LiteSpeed Cache, and WPML. [ad_2] Source link
Continue readingGutenberg 19.1 Introduces Plugin Template Registration API – WP Tavern
[ad_1] Gutenberg 19.1 has arrived, introducing the eagerly anticipated plugin template registration API and updates to image caption styles. This Gutenberg version will be later incorporated into WordPress 6.7. The highlight of this release is the plugin template registration API. It addresses a long-standing issue developers have faced with conflicts between plugins and themes, particularly when dealing with custom post types, taxonomies, or virtual pages. This new feature allows developers to register block templates directly within their plugins, providing fully customizable default content layouts. Till now, developers had to use multiple filters to register templates. By building on the Gutenberg block system, this update makes it easier for themes and users to adapt and personalize templates according to their design and functional needs. Justin Tadlock has published a detailed tutorial on this feature on the Developer Blog and will host a Developer Hours Session with Nick Diego on September 10, 2024. This release also tones down the intensity of the caption background, improving the image caption styles. Other notable changes in this version include: Improved data view extensibility Better defaults for the zoom out view Added border support for core blocks Applied elevation scale to Modal, Popover, and Snackbar components. Fixed wp-config anchors to make wp-env compatible with WordPress versions older than 5.4. The community’s response has been enthusiastic, with feedback such as “Really like this feature”, “Great one, that I am looking for !” and “Literally the greatest news I’ve heard in years (and I had a baby last year)” [ad_2] Source link
Continue reading8 Mistakes I Made When Building a WordPress Plugin With AI
[ad_1] Had I planned it out ahead of time, I would’ve went with the tabbed layout that I eventually used, right from the beginning. The overall process would have gone much smoother. Here’s what I think works better Once you decide on what you want your plugin to do on a broad-level, find existing plugins that do the same thing or that have some overlap. Install them on a dummy site using TasteWP and use them. But don’t just use them like a regular user. Use them like a UX researcher would use them. Make careful notes on how different things work. What do you like? What would you do different? After you perform this plugin testing, organize your notes. Then put together a detailed description of your prototype. Ask yourself how users will interact with it. Will they use shortcodes? Will they add extra blocks inside the block editor? Will there be a settings area on the back end? Cover all your bases. Consider using wireframes to visually map out how users will navigate their way around your plugin. You can get free wireframes over at Figma. When you finish the above, use your detailed description and possibly any wireframes you create, to give your first prompt to ChatGPT. My recommendation for the prompt is to start small and gradually build. This way you can more easily isolate and fix any bugs that come up. Using my plugin as an example, if I was to do it all over again, I’d first give GPT a broad overview of what I want to do. I’d also mention the tools and scripts I want to use. Then I would begin building only the first effect along with the corresponding area for it on the back end. I’d test it to make sure it works. If all was well, I’d add the next effect, and so on. Mistake #2: Ignored WordPress coding standards at the beginning Another big mistake I made was that I didn’t realize how big of a gap there is between simply building a plugin that works and building a plugin that is worthy of submission to the WordPress repository. You might be surprised, but going from zero to functioning plugin is much easier and faster than going from functioning plugin to well-coded plugin. To put this in real-number terms: It only took me about two or three days to build a functioning plugin, but it took me another seven weeks of work before I got it to a point where I was able to submit it to the WordPress repository for consideration. Even if your ultimate goal is not to submit your plugin and you only want it for yourself or a client’s website, you should still follow coding best practices. This will ensure that your plugin doesn’t cause other things to break on your site and doesn’t put an unnecessary strain on your site’s resources. Here’s what I think works better Make sure you tell ChatGPT (or Claude) right from the beginning that whatever code it generates should follow WordPress coding standards. If you’re planning on submitting your plugin to the WordPress repository, then for good measure, also add that any indentations should be done using tabs and not spaces. GPT has a tendency to default to spaces, but this goes against the coding standards. If you don’t nip it in the bud right from the get go, then you’ll have to deal with it later when you do your linting. Might as well do it correctly from the start. Mistake #3: Allowed GPT to constantly regenerate entire code files One thing you might be tempted to do when you have very little experience working with code is to ask ChatGPT to regenerate entire code files when you’re debugging. I was guilty of this, until I realized it was getting me nowhere. It’s not necessarily an issue if you’re dealing with a relatively small JavaScript file that’s 50 to a 100 lines long. However, as your plugin gets more complex and your main PHP file starts growing considerably, then it becomes highly problematic. For one, it takes GPT some time to generate that code. For example, let’s say you have a bug in a file that contains 800 lines of code. Now imagine the actual problem is found on only one of those 800 lines. Does it make sense to sit in front of your monitor for five minutes, watching GPT regenerate 799 lines that it doesn’t need to? No, it doesn’t. And here’s the other problem: As the length of your code grows, ChatGPT’s memory worsens. What ends up happening if you allow it to regenerate very long sections of code, is that it won’t only tweak the problematic lines you’re trying to debug, but it’ll also accidentally change other lines. So now you might fix the error you wanted to fix, but you’ll be stuck with some new error(s). If you continue going about it the same way, it will leave you in an endless loop of debugging. You’ll feel like you’re trapped in the Matrix. Neo won’t be coming to save you though. You must save yourself. Here’s what I think works better When you’re debugging, make sure to include very specific instructions to ChatGPT in your prompts to keep it laser-focused. After some trial and error, I found that telling it to do the following worked well: Please do not regenerate the entire file for me. Analyze and isolate the specific lines of code that you believe are causing the problem and show them to me. Explain what specifically about those lines you think might be the issue. Then explain how you are going to change the lines and what you expect the outcome to be as a result of the changes. Finally, please give me the updated lines in a code snippet so I can copy and paste them. Mistake #4: Used plain vanilla CSS instead of BEM CSS If there’s
Continue readingPlugin Dependencies Feature Plugin Now Ready for Testing – WP Tavern
[ad_1] For more than a decade, WordPress developers have been discussing how core can support plugins that require one or more other plugins in order to work. Having a standardized way of managing plugin dependencies would be a useful and time-saving feature for developers, who currently have to roll their own solutions for this. “The situation there is a lot like the relationship between parent and child themes,” project lead Andy Fragen said in February when introducing the idea for the feature plugin. “Without their relationships to the bigger plugin, those dependent plugins can do very little. Every plugin developer is on their own to code a solution to resolve the issue. The single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins.” After nine months of discussion and development, the Plugin Dependencies feature plugin is now ready for testing. It allows plugin authors to specify any WordPress.org-hosted plugin(s) that are required for their plugins to function. A plugin that has dependencies can be identified by adding a “Requires Plugins” header to the docblock of the main plugin file. Plugin authors can specify as many dependencies as necessary in a comma-separated list of plugin slugs. How does it work? Site owners will get an admin notice if there are dependencies they need to install. The plugin card will be updated to display the Requires and Required by information on the Plugins screen. Fragen outlined how the community can test the new core support for handling plugin dependencies. You do not have to be a developer to participate in testing this new feature. It involves installing test plugin files and confirming admin notices appear and disappear at the right times. Testers who are comfortable editing plugin files can try adding dependencies, adding a dependency for non-WordPress.org plugins, and other more advanced tests. Version control is not part of this project, so developers will not be able to specify a minimum required version, for example. “Version control is out of scope for the feature as described in the original Make post referenced above,” Fragen said in response to a question on the feature plugin. “As the majority of the dependencies come from the dot org repository, the most current versions will be installed. “Specifically, WordPress should automatically prompt the user to update to the current version and may use auto-updates as well.” Testing will be open until December 1, 2022. Anyone who wants to be part of moving this long-awaited feature towards a possible inclusion in core can report issues to the WP Plugin Dependencies plugin’s repository. [ad_2] Source link
Continue readingJetpack Social Plugin Adds Paid Plan, Free Users Now Limited to 30 Shares per Month – WP Tavern
[ad_1] Jetpack has announced changes to its Jetpack Social plugin that may impact publishers who frequently share across social media networks. Previously, users could share an unlimited number of posts automatically via their connected social media accounts. Jetpack is shuffling its monetization strategy for this extension and has capped social sharing at 30 shares per month for the free tier. A new paid plan offers 1,000 shares and re-shares per month, starting at $1/month for the first month and is $10/month thereafter. As a concession, Jetpack is rolling the social previews and re-sharing into the free plan. With Jetpack Social, if a post is automatically shared to Twitter, Facebook, and LinkedIn, that counts as three shares. It’s easy to see how quickly these shares can rack up to where even a casual blogger might require a paid plan. Publishers that are used to being able to automatically share all their posts for free should be aware this change that limits them to to 30 shares per month. I would not be surprised to see some users switch to another social sharing plugin, as many others offer far more social networks and don’t limit the number of times users can share. Instead they opt to restrict re-sharing, scheduling, or the ability to connect multiple accounts per social network. Jetpack Social has a new team behind it focused on making the product better. In 2021, Automattic acquired the Social Image Generator plugin with plans to integrate it into Jetpack’s social media tools. This may make the product more compelling, since it currently doesn’t stand up well to the myriad of free sharing plugins out there. Jetpack only supports four social networks, but the team is working on expanding the plugin’s capabilities. The plugin’s development team also accepts feature suggestions on its GitHub repository. Version 1.4.0 of the Jetpack Social plugin moved the share limits code to the Publicize package and added a meter to show users how many shares they have remaining. Users on the free plan should notice these changes in their dashboards. [ad_2] Source link
Continue readingDiscussion on Replacing Plugin Active Install Growth Data Continues Behind Closed Doors – WP Tavern
[ad_1] Earlier this month WordPress.org meta contributors removed the active install growth chart from plugins, sending plugin developers who relied on this data into a state of dismay and outrage. The commit cited “insufficient data obfuscation” but there was no clear communication about when and where this decision had been made. Developers demanded more transparency around the charts’ removal but received no clear answers. Multiple opportunities to communicate the details behind the decision were deliberately forgone, as speculation mounted. Several contributors not directly involved in the conversations prematurely insisted it was removed due to a security or privacy concern, but Samuel Otto Wood has unequivocally confirmed that it was neither of these things. In a recent appearance on the WPwatercooler podcast, Wood elaborated on the decision, which he says was made in May through private channels via Slack DMs in a discussion initiated by Matt Mullenweg. “The reason is really quite simple,” Wood said. “It was removed because by and large, nobody was using them. Nobody was using the chart itself. By and large, the chart was not useful to the majority, and it didn’t really fit the purpose we had for it, that we had in mind when we implemented it.” Wood said the active growth chart was intended to just show growth or decline of a plugin on a weekly basis, but the data wasn’t working as intended: People wanted that feedback on whether plugin’s growing, whether it’s shrinking, et cetera. And that’s valuable information for developers to have, it’s valuable information users to know. But it really wasn’t working as that. The data that it provided was a percentage based data, and it was a very weak percentage based data. So by and large, the majority of use of that data was people scraping the data and using it to work backwards to the exact quote, exact numbers That was entirely the problem was that people were largely using it to get those numbers. Now, that’s not itself bad, but a, the reverse math didn’t work. It was wrong for a number of reasons, mainly because we were doing such a way obfuscating the data in such a way that it made that number wrong. Second, Actually, it’s kind of funny. It actually always gave numbers a bit too high, so it was giving people the wrong impression. Third, it really, people trusted it as an active number, as a number of active cells to the point where, to the point where they, they relied on it to make decisions and things like that. It was not a good idea. Although Otto was not involved in working on the project at the time, he was privy to the discussion and relayed some of the details: I read through all that discussion and we worked, they worked on it for a long, Scott and several people tried various things before removing it. They adjusted the values, they adjusted numbers. They, they went through a ridiculous amount of iteration and in the end, none of it worked. People were still using it even though it was giving them basically garbage. So finally removing it was the only thing to do. We did have a plan for replacing it. We just didn’t have a plan for replacing it immediately. Nevertheless, giving them active install count numbers that are wrong is more harmful, we felt, to both users and developers interests than simply not giving them at all. So that’s why it was removed. The concern podcast host Sé Reed and guest Matt Cromwell highlighted was that the decision was communicated in such a way that it suggested it was security related. Since it was not a sensitive security or privacy issue, Reed asked why was it handled in a private chat instead of the meta channel when the decision had such a profound impact on developers being able to track the trajectory of their plugins. Since the inaccuracy of the charts was well-known to those more intimately acquainted with the problem, Wood said its removal was “not quite the big deal” that everyone else ended up perceiving it to be. They did not anticipate the firestorm the charts’ removal would create in the trac ticket where developers were pleading to have them restored. “The physical visual chart itself is not so instrumental to the way I operate things,” GiveWP founder Matt Cromwell said. “But it’s the act of removing it without any conversation whatsoever. “And what does that mean for the long run of data about plugins on.org and the viability of their, of us, continuing to have them? That’s the real question. It’s an indicator of an underlying problem that isn’t getting better.” This incident has sparked discussions about what kind of partnership plugin developers should expect from WordPress.org, and whether it’s time they looked for support from one another instead of the platform, as Eric Karkovack suggested on The WP Minute. In light of plugin developers losing more valuable data that hasn’t been replaced, Alex Denning, managing director of Ellipsis, a digital marketing agency, makes the case that WordPress.org is ineffective for plugin distribution in 2022. He contends that new WordPress plugins are not passing the 100k, 500k , or 1m+ install thresholds and the directory isn’t giving plugins organic reach. The focus of the ticket has changed from calling on WordPress.org to bring back the active growth charts to be more about brainstorming helpful plugin stats and insights that plugin developers would like to see. It is still receiving angry and frustrated comments from developers who believe the data should belong to the community. “I cannot emphasize enough that conversations about what to replace the active growth chart with should be happening in a public Slack channel or on a Trac ticket,” Equalize Digital CEO Amber Hinds said. “This data should belong to the community and the community should be able to participate in deciding how (or not) to display it.” The reasons that purportedly necessitate obfuscation have
Continue readingNew Missing Menu Items Plugin Adds Site Building Links to WordPress Admin – WP Tavern
[ad_1] If you are going all in on building sites with the new full-site editing (FSE) experience, then you may have noticed a lack of menu items that will deliver you directly to the tools you need to use. It may be because the Site Editor is still in beta, or because WordPress leadership may still be discussing whether to rename FSE. Perhaps it’s better that users don’t blindly stumble into FSE templates from the main admin menu, but some of these site building features are buried away with no quick access. For example, you are three clicks deep before arriving at Template Parts. Managing reusable blocks is also a tucked away on a separate screen that can be accessed through the post editor but sends you to a new page. If you’re using the block editor, and reusable blocks Do yourself a favor cut and paste this at the end of your website: /wp-admin/edit.php?post_type=wp_block Then bookmark it. — Ben LayerWP & WPDeals.email (@benswrite) October 26, 2022 When LayerWP founder Ben Townsend brought attention to this in a tweet, Roy Sivan responded with a link to a new free plugin that creates quicker access to these menus. Missing Menu Items expands the admin menu with links to reusable blocks, navigation menus, templates, and template parts, so they are all one click away. It adds them to the Appearance menu under the Editor (beta) link: If you are regularly working with Reusable blocks or editing navigation and templates, this plugin will save you some time and help you zip around the editor faster. Missing Menu Items was made by Easily Amused, the creators of Block Styles, a commercial plugin that lets users further customize core blocks with unique styles and boasts “fully responsive block-level design control.” The team will be adding more useful menu links and admin improvements in future releases. Users can contact the development team with menu item requests and they will consider them. Missing Menu Items is available on WordPress.org. Direct support is available for those who have purchased a BlockStyles membership, and community support can be found in the plugin’s forums on the directory. [ad_2] Source link
Continue reading