Craft is a flexible, user-friendly CMS for creating custom digital experiences on the web and beyond.

Created by: Selvin Ortiz ([email protected]) on 2015/03/10 20:43:19 +0000 Votes at time of UserVoice import: 224

Plugin development and the Craft community as a whole would benefit greatly from an officially supported plugin store.

The plugin store would allow us developers to more easily sell/distribute our plugins and more quickly provide bugfixes and updates as well as enable our customers/users to have a single place to manage plugin licenses, request plugin specific support, and possibly have access to plugin docs right within the control panel.

Granted the plugin store is built into the control panel and provides a feature set similar to the one that has been discussed in back channels. Most of which is not public knowledge at this point.

Having websites like straightupcraft.com to discover new plugins and craftpl.us to sell/distribute commercial plugins is a descent start but I feel that an officially supported plugin store built into the control panel would benefit us far beyond the immediate problems it solves and would allow us to be better organized and to be more closely aligned with what a modern CMS should be.

Though some people have said that there are other priorities that should take precedence, I believe that the plugin store should be at the top of the list because formalizing this process would most likely motivate other agencies to invest in Craft plugin development and hopefully we can get some big guns to actually fill the gap that freelances have been unable to fill for so long and finally have fully featured commercial tools for draft/review/approval workflows and calendar/event implementations as well as robust e-commerce solutions we can deploy and that take advantage of Crafts localization, element type API, etc.

Without a formal process, we're going to continue to have quantity in plugins but not as much in the way of quality, continued development, and adequate support.

A plugin store, in my humble opinion, should be high priority on the list.

Description

The "Preview" button will move you from "Current" to a "Draft" , Unlike developers, the content writers focus on one version only. On 3.5, the "Preview" button will move you from "Current" to a "Draft". and when they click "ctrl-S", this will save the draft instead of save the "current".

This makes sense to developers that is familiar with git and branches, but creates a lot of confusions to the content writers.

To content creaters, if they are working on "current", whatever they do should keep them at the "current" version, and ctrl-s should save the changes to "current". (like working on a word doc file) If the content writer wants to create a draft to test changes, they should do it themselves via a "create draft" button. (like duplicate the word doc).

Suggestion:

When you create a new entry is disabled by default. The first edit (create) will create a "Draft 1". All edits are auto-save to the "Draft 1". Clicking "preview" button will save the "Draft 1". To create another "Draft", they should click "Create a new draft" and they get "Draft 2". To publish changes to live, they should click "Publish" button. This should push the changes to live ("current"), and create a "Revision 1" record the current live version.

Created by: Mats Mikkel Rummelhoff ([email protected]) on 2015/03/09 00:12:31 +0000 Votes at time of UserVoice import: 355

Coming from Wordpress and ACF, I miss being able to set up simple conditionals for fields.

An example scenario:

A field layout for the section "Albums" includes a true/false called "Compilation". If unchecked, the layout displays a text input field called "Artist name". If checked, the "Artist" field is hidden and replaced by a Table field called "Artists", where the author is able to enter any number of artists featured on the album.

In ACF, all fieldtypes has a "Conditional logic" checkbox. If checked, the field creator is able to build their conditions for showing or hiding the field, based on any selectable (as in checkbox, radio buttons, dropdowns, true/false etc) "sibling" fields in the same Field Group (or Layout, as it were). You can also apply conditionals to fields inside Repeaters (ACF's version of the Table field) and Flexible Content (Matrix) fields, which works the same way – the conditonal builder UI relies on selectable "sibling" fields in the current context.

In the example scenario, the condition for showing the "Artist" field would be [IF "Compilation" IS NOT EQUAL TO "checked"], and for the "Artists" field it would be the opposite.

Conditionals are not super important in Craft, as we have Entry Types, but I can definitely see use cases where one would be more elegant than the other, and I'm often encountering situations where creating a whole separate entry type just to be able to offer a small amount of flexiblity in the layout just seems a bit overkill. If Craft had conditionals, I'd use Entry Types only when the field layout would be more different than similar across various content types in the same section.

To close, one huge difference between Craft and ACF is obviously that fields in Craft are shared between layouts, whereas fields in ACF are tightly coupled to their group. This means that any conditional logic in Craft would probably have to be applied in the Layout Designer (possibly by adding a "Conditional logic" button to the fields' cogwheel/settings button, which could then load up a conditionals builder in a modal or whatever) and not when creating any individual field.

For Matrix fields, however, it would make sense to be able to add conditionals across block types and their fields in a more similar manner to the ACF way.

Description

In Craft 3, saving an Entry Type's settings (e.g. in order to add a new field to its field layout) triggers a resave of all entries belonging to that section/entry type.

Sometimes a resave is necessary – e.g. if you change the URL format – but if you've a lot of entries, the re-save can be a problem, due to the time and resources it takes to actually resave all of the entries. Also, a lot of the time (more often than not, from my perspective) a resave isn't even needed – such as when you simply re-arrange the fields in the field layout.

It'd be great if

1. There was a config setting to disable the automatic re-save (could/should be true by default, i.e. keeping the current behaviour intact). Developers would then be able to implement their own strategies for dealing with changes to an entry type, whenever a re-save is actually needed.

2. If automatic re-save is enabled (or the config setting isn't implemented), Craft could be smarter about when to actually do it (i.e. changes to the URL format should trigger a re-save; simply re-arranging the fields in the field layout should not).

3. A native feature for manually triggering bulk resaving of entries belonging to a particular section or entry type would be awesome.

Additional info

• Craft version: 3.0.31

Description

Now that Craft has fantastic support for running in a headless mode I’d love to have a built-in way to authenticate users when the front end is disconnected from Craft. For instance, if I’m running the front end on something like Next.js, Nuxt.js or create-react-app.

Additional info

• Craft version: Pro 3.3.17
• PHP version: 7.2
• Database driver & version: MySQL 5.7.5

Created by: Ryan Masuga ([email protected]) on 2016/09/16 16:15:29 +0000 Votes at time of UserVoice import: 83

I'm not a fan of infinite scrolling. I don't think it adds anything to the Craft CP other than more JS. I would at least like the option to select "standard" pagination in the control panel. When I'm looking at members, Assets sources, or channel entries, there are no counts anywhere. I have no idea if our current site has 500 or 5000 members, I have no idea if there are 50 or 500 blog posts, and I have no idea how many images are in Assets source X - and neither does the client. Without pagination, we can't even guess at these numbers. I'm just scrolling, scrolling, and eventually give up.

This would apply to (at least): Asset Sources, Users, and channel entries - anything I would normally have to scroll through infinitely.

So somebody is nagging about the Craft CP again …

Comparing Craft 2 and 3 CPs – I think we have lost quite a bit of friendliness and „softer“ design details. Craft 3 makes better use of available space, but with the narrow head area, the main content area framed by the dark blue main nav and a still dark right details sidebar, it looks more technical and a less welcoming (at least to me).

Here´s a short list of suggestions. I´ve put this together using the great Control Panel CSS plugin (thank you for making this @lindseydiloreto!).

Head area / Details sidebar

The head area would benefit from some extra vertical space I think. Also, there are many different baselines for Site name, user, breadcrumbs, and entry title. Maybe that could be cleaned up so that Site name and user on the left and breadcrumbs and entry title on the right share the same top line and baseline respectively. (Or the user could be moved to the bottom like in Craft 2, which would also make it less busy at the top.)

Also, I am missing the red title and wonder if we can get it back? It´s a small splash of color but makes the header or titles stand out and the CP less monochromatic but richer and more pleasant.

This is my major issue: I am at odds with the position of the revision button right after the title, and the centered Live Preview and Share buttons. All three are jumping around from title to title. I think it would be much cleaner and spacious if Preview and Share sat next to the Save button on the right. As for the Revision button – would that not belong somewhere inside the right details bar next to the various entry dates? I would definitly prefer it there. Also it should not show up at all, if I don´t make revisions available to clients.

Lastly, I find the layout even calmer, if the head area and details sidebar are white for the most part. With the current blue, the sidebar looks like a „read-only“ area on total, when in fact clients are supposed to make edits. The vertical line would be enough separation for me.

Main container

If using the white background, changing the font weight to bold adds attention to active tab.

For input, text area and redactor fields, adopting the 2px border radius from the buttons would make the design a little softer. Also the focus for input and text area is a black outline, for Redactor it is blue. Maybe a blue focus border for all fields would be friendly. (Blue is already the hover color for the tabs.)

Redactor also should use the system typeface to make it look like the original Craft fields.

The matrix button group for adding matrix blocks has a high top margin so it sits too far way from the matrix field label. Setting the margin to 0 looks right and in accordance with the (first) added matrix block.

Finally, to me the asset field type when set to large thumbnails is not ideal. The distance from the image to the label and its file name and the left and right border changes depending on the image orientation, since the thumbnails is loaded in a square 100px box. With only one image loaded, this looks a bit off. Maybe a light grey border would „explain“ what´s going on, or the thumb and asset name could move up for landscape, and assets left for portrait images?

Another question regardiing this field: If the thumbnails are large, the file names are shortened because of the 100px „wide" col. Does the file name then make sense at all, or should it dropped completely and be replaced by two buttons („x" Delete and „i“ Info?). The info could open the image element editor with file name, etc.

Final peanut

The Craft version in black does looks a bit harsh to me. A lighter or darker blue would melt it in more.

What do people think – if this is just me I´ll shut up ;)

And If somebody wants to try the suggestions it easy to do with the free Control Panel CSS plugin and the attached css file. (If you would like to see it with the original light blue header and tabs area you can comment out the white background for „body“ and "#main-container #main #header“.)

craft-cp-modifications.css.zip

Description

Since upgrading to Craft 3.4.1, and upgrading all plugins accordingly, I am getting 504 Gateway Time Out almost all GraphQL requests. Site is running on Docker with all install conditions met. Have even tried setting max_execution_time to 2000 and memory_limit to 512. Have also tried with devMode off and all plugins disabled. Have also removed vendor folder and composer.lock file and reinstalled.

Site responds quickly when docker box is first restarted. But times out in subsequent requests.

Additional info

• Craft version: 3.4.1
• PHP version: 7.4.0
• Database driver & version: MySQL 5.5.5
• Plugins & versions: Control Panel Nav 3.0.0 Feed Me 4.2.0.1 Navigation 1.3.0 Phone Number 1.3.0 Redactor 2.5.0 Redactor Custom Styles 3.0.2 Reverse Relations 1.1.7 Title to Sidebar 1.0.1 Vertical Tabs 1.0.0

Description

Very sporadically I am getting Lock wait timeout exceeded errors from MySQL.

These appear in Craft logs like:

Next yii\db\Exception: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction

and

[error][yii\db\Exception] PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction in /var/www/craft/vendor/yiisoft/yii2/db/Command.php:1302

Running show engine innodb status shows they are consistently from queries on the structureelements table:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2021-09-30 13:49:41 0x14b8
*** (1) TRANSACTION:
TRANSACTION 6366085, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 22 lock struct(s), heap size 1136, 10 row lock(s), undo log entries 8
MySQL thread id 89160, OS thread handle 5260, query id 7402009 10.2.0.62 cswwwuatdbmysql updating
UPDATE `structureelements` SET `lft`=`lft`+2, `dateUpdated`='2021-09-30 13:49:39' WHERE (`lft` >= 884) AND (`root`=1)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 623 page no 20 n bits 1192 index structureelements_root_idx of table `craftcms`.`structureelements` trx id 6366085 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 00000001; asc     ;;
 1: len 4; hex 80000001; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 6365973, ACTIVE 5 sec inserting
mysql tables in use 1, locked 1
335 lock struct(s), heap size 41168, 2975 row lock(s), undo log entries 2044
MySQL thread id 89190, OS thread handle 5304, query id 7403525 10.2.0.62 cswwwuatdbmysql update
INSERT INTO `structureelements` (`structureId`, `dateCreated`, `dateUpdated`, `uid`, `lft`, `rgt`, `level`) VALUES (20875, '2021-09-30 13:49:41', '2021-09-30 13:49:41', '58e60ef1-6f8b-4a5d-9783-cf378111c29d', 1, 2, 0)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 623 page no 20 n bits 1192 index structureelements_root_idx of table `craftcms`.`structureelements` trx id 6365973 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 00000001; asc     ;;
 1: len 4; hex 80000001; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 623 page no 20 n bits 1192 index structureelements_root_idx of table `craftcms`.`structureelements` trx id 6365973 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 00000001; asc     ;;
 1: len 4; hex 80000001; asc     ;;

*** WE ROLL BACK TRANSACTION (1)

The database server is pretty chunky and performs well elsewhere. The innodb_lock_wait_timeout setting was at the 50 second default. I have just dumped to 100 but this feels like a sticking plaster i.e. telling it to wait a bit longer just in case!

https://github.com/craftcms/cms/issues/5872 suggests a large number of revisions could be the issue. I only have about 6k entries and 4k revisions, while there are 57k rows in structureelements.

I'm conscious StackOverflow is awash with useless threads on these errors and the usual reply is "refactor your code to make sure everything is in one transaction" which doesn't seem too useful.

The offending queries seem fairly innocuous to me. The issue is very sporadic — maybe 10 times in 3 months — and always seemingly when a content editor goes to save an entry.

Reckons?

Additional info

• Craft version: 3.7.13
• PHP version: 8.0.1
• Database driver & version: MySQL 5.7.32 (https://azure.microsoft.com/en-us/services/mysql/)

Description

We are having issues with an implementation of Craft 3 in that when the craft command is run on the CLI, there are permissions issues with certain files in compiled_classes.

The command we're running is php craft project-config/sync as the SSH user who manages the deployment.

The error we get is:

DEBUG [8e6acd4b] 	error: fopen(/var/www/vhosts/[website]/releases/20200131085600/storage/runtime/compiled_classes/CustomFieldBehavior.php): failed to open stream: Permission denied

(This is a deployment managed by Capistrano but as far as Craft is concerned, the storage folder is just as normal)

Simply setting 777 on the directory as per the installation guide won't work long term, as when PHP runs via the apache user, it is creating files that only it owns (such as storage/runtime/compiled_classes/CustomFieldBehavior.php with apache:apache 600)

Here are all of the files within that folder:

-rwxrwxrwx+ 1 apache apache 2011 Jan 21 15:43 ContentBehavior.php
-rw-------+ 1 apache apache 5851 Feb  3 09:43 CustomFieldBehavior.php
-rwxrwxrwx+ 1 apache apache  952 Jan 21 15:43 ElementQueryBehavior.php

I've tried using ACLs and that has worked for the most part, but the acl for that one file ends up being this:

# file: CustomFieldBehavior.php
# owner: apache
# group: apache
user::rw-
user:apache:rwx            #effective:---
user:[SSH USER]:rwx        #effective:---
group::rwx            #effective:---
mask::---
other::---

This is the ACL for storage/runtime/compiled_classes/ (note the default parts which sub-files should be inheriting):

# file: .
# owner: apache
# group: apache
user::rwx
user:apache:rwx
user:[SSH USER]:rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:apache:rwx
default:user:[SSH USER]:rwx
default:group::rwx
default:mask::rwx
default:other::rwx

Here's what a "good" ACL looks like on another file in that same folder:

# file: ElementQueryBehavior.php
# owner: apache
# group: apache
user::rwx
user:apache:rwx
user:[SSH USER]:rwx
group::rwx
mask::rwx
other::rwx

We're at a loss as to how we can resolve this, with the CLI user being different from the web user. ACLs seem to be the way to go, but our experience is leaving us wondering.

Steps to reproduce

1. Install craft, user from web.
2. Attempt to run commands from CLI that alter files generated by web user.

Additional info

• Craft version: 3.4.2
• PHP version: 7.2.17
• Database driver & version: MariaDB 10.2.10 (MySQL 5.5.5)
• Plugins & versions: (Likely not relevant but a list can be provided if needed)

Description

Don't know whether i missed something in my setup or that's an issue, but couldn't get a headless preview working for unsaved drafts.

So the default preview for an unsaved draft works fine with a url like

http://temp2.local/en/news/__temp_9hWhjyD2oqL6eaGscUyxndcGZ6gMksJ9cP1X?x-craft-preview=qtdgDQI8ut&token=jIUdZHOcTRKHNeA_zLjgTKoBDd0JWDdY

However trying to get a preview from a simple vue js app via element api fails with

{ "error": { "code": 404, "message": "No element exists that matches the endpoint criteria" } }

The element api url is

http://temp2.local/en/api/v1/entry/__temp_9hWhjyD2oqL6eaGscUyxndcGZ6gMksJ9cP1X?token=jIUdZHOcTRKHNeA_zLjgTKoBDd0JWDdY

The config is

'api/v1/entry/<slug:[^\/]+>' => function($slug) {
    return [
        'elementType' => Entry::class,
        'criteria' => ['slug' => $slug] ,
        'one' => true,
        'pretty' => true,
        'cache' => false,
        'transformer' => new EntryTransformer(),
    ];
},

Once the entry is saved, and a new draft is created, the headless preview for that draft works fine:

http://temp2.local/en/api/v1/entry/headless-preview?token=R2Wp36Lr_Z8Zu7utYDnv6ERNDH9a3zWP gets the correct draft data.

When the source entry is disabled or the post date is set to a future date, the default preview for a new draft works, but the headless version fails again with 404.

Additional info

• Craft version: 3.2.2
• PHP version: 7.2.14
• Database driver & version: MySQL 5.7.14
• Plugins & versions: element-api 2.5.4

What happened?

Description

When using live preview on a page which can scroll horizontally, the page's scrollX is always 0 when live preview refreshes. scrollY is maintained as expected.

Steps to reproduce

1. Set up horizontally scrolling template (minimal example code below) on an entry type which has any field on it (in order to trigger live preview refresh)
2. Edit the entry and enter live preview
3. Scroll to e.g. box 24 at the bottom right
4. Edit a field and observe how when live preview refreshes, scrollY is maintained at the bottom of the page, but scrollX has reset to 0.

Expected behavior

scrollX is maintained as well as scrollY. It looks like the code is attempting to restore scrollX: https://github.com/craftcms/cms/blob/2eac9249964ccc553bf841c79b9ee44d58f16b61/src/web/assets/cp/src/js/LivePreview.js#L402-L409

Actual behavior

scrollX is ignored, scrollY is maintained.

Example template code:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Craft Test</title>
    <style>
      html {
        overflow-x: auto;
        font: 20px/1.2 sans-serif;
      }
      .boxes {
        display: flex;
        flex-wrap: wrap;
        width: 4000px;
      }
      .box {
        width: 500px;
        height: 75vh;
        background: #eee;
        border: 5px solid #fff;
        padding: 20px;
        flex-shrink: 0;
        box-sizing: border-box;
      }
    </style>
</head>
<body>

  <div class="boxes">
    {% for i in 1..24 %}
      <div class="box">Box {{ i }}</div>
    {% endfor %}
  </div>

</body>
</html>

Browser

Google Chrome 108.0.5359.124 (Official Build) (arm64) Reproducible with all extensions disabled MacOS Ventura 13.0.1

Craft CMS version

4.3.6

PHP version

8.0.8

Operating system and version

MAMP Pro, Darwin 22.1.0

Database type and version

MySQL 5.7.34

Image driver and version

ImageMagick 6.9.6-2

Installed plugins and versions

• None

Bumps json5 from 1.0.1 to 1.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

In the CP, for several sections (all of which are structures), the cp js fails to load beyond installHook.js, so edit page functionality is inoperable.

Spent several days trying to track down why this would be, have cleared all caches, resaved all entries, repaired section structures, reinstall craft, everything I can think of. Can't see what the offending entry types have in common in terms of fields or section settings, that other sections which do load don't have.

If I create a new entry within any of these sections, even then the js doesn't load.

There are no errors in the console. No unexpected behaviours on the frontend.

The db has been migrated up from circa Craft 2.5 but latest upgrade to v4.x has resulted in this problem. As I've only just noticed it (having been building on 4.x locally for last few weeks) I can't be sure the upgrade caused the problem, but it may have done.

I have also tried the same DB on a remote staging env (on a clean install of craft) and same problem there too.

Wondering if anyone can help?

Craft CMS version

4.3.5

PHP version

8.1.11

Operating system and version

Linux 5.15.49-linuxkit

Database type and version

MariaDB 10.4

Image driver and version

Imagick 3.6.0 (ImageMagick 6.9.11-60)

Installed plugins and versions

• "clubstudioltd/craft-asset-rev": "^7.0",
• "craftcms/aws-s3": "^2.0",

• "craftcms/cms": "4.3.5",
  

• "craftcms/mailgun": "^3.0.0",
  

• "craftcms/redactor": "^3.0.2",
  

• "enupal/stripe": "^5.0",
  

• "jamesedmonston/graphql-authentication": "^2.1",
  

• "kinoli/groupie": "dev-master#e7abdf81a185fa614b9d6385dc587fd994f111f3 as 2.0.0",
  

• "mmikkel/retcon": "^2.5",
  

• "nystudio107/craft-cookies": "^4.0",
  

• "nystudio107/craft-seomatic": "4.0.16",
  

• "nystudio107/craft-vite": "^4.0",
  

• "ostark/craft-async-queue": "^3.1",
  

• "putyourlightson/craft-campaign": "dev-develop as 2.3.1",
  

• "spicyweb/craft-embedded-assets": "^3.0",
  

• "spicyweb/craft-quick-field": "^2.0",
  

• "topshelfcraft/wordsmith": "4.2.0",
  

• "verbb/comments": "^2.0",
  

• "verbb/field-manager": "^3.0",
  

• "verbb/image-resizer": "^3.0",
  

• "verbb/super-table": "3.0.7",
  

• "vlucas/phpdotenv": "^3.4.0"
  

Currently, it's only possible to define custom GQL directives statically, by providing a class name, on which Craft expects to invoke Directive::create().

But what if we want to generate custom directives dynamically?

• We will need the ability to register already-instantiated Directive instances in addition to static class names.
• And, we will need to move apply() into the instance context, to involve instance-specific behavior, rather than just static logic.

What happened?

Description

I thought that maybe this update would fix the issue, but we're still getting data loss in a matrix field if the entry is saved too quickly. On an already published entry, if I add a block to the matrix and hit cmd+s before the field revision gets autosaved (before the blue border appears to the left), I get unexpected data loss in the matrix field.

https://user-images.githubusercontent.com/1458917/207673772-0e9dcd87-e700-4145-ac52-a2545635a97b.mov

Steps to reproduce

1. Create matrix field with one block (I don't think it matters which fields are added the block, but we have one user field and one dropdown field)
2. Add it to a section
3. Create an entry in the section and add a matrix block or two, hit save.
4. Return to the newly created entry
5. Add a new block to the matrix and hit save immediately
6. The newly refreshed page will have missing matrix rows.

Expected behavior

The matrix field should have all data still intact.

Actual behavior

The matrix field is completely stripped of data.

Craft CMS version

3.7.61

PHP version

7.4.3

Operating system and version

Linux 5.4.0-126

Database type and version

MySQL 8.0.31

Image driver and version

Imagick 3.4.4 (ImageMagick 6.9.10-23)

Installed plugins and versions

Amazon S3 1.3.0 Freeform 3.13.2 Imager X v3.5.5 Linkit 1.1.12.1 Navigation 1.4.24 Notifier 0.9.5 Postmark 2.1.0 Redactor 2.10.4 SEO 3.4.26 Sprig 1.13.0 Sprout Fields 3.8.5 Super Table 2.7.1 Wordsmith 3.3.0.1