Weekly update – 11 July 2024

[Ivan Gretsky]

Hmm. As far as I understand, none of the proposed goes straight into next major version roadmap. Or am I wrong?

@ryan, please direct us. Should we write more proposals? Which direction should we move?

[cb2004]

@ryan reading your reply makes me realise you are such a master of your craft, but you can't take all this on by yourself to grow the project. Rather than the community telling you what they want, tell us how we can help you.

 

 

[David Karich]

7 minutes ago, Ivan Gretsky said:

Hmm. As far as I understand, none of the proposed goes straight into next major version roadmap. Or am I wrong?

@ryan, please direct us. Should we write more proposals? Which direction should we move?

Unfortunately, that's how I understood it and I didn't understand it. Actually, all the real gamechanger proposals were rejected, especially the ones that so many people have been asking for years. At its core, PW is obviously tied to what Ryan needs it for, not the community.

[ryan]

@Ivan Gretsky @cb2004 @David Karich Sorry, I must not have written it very well. I'm tired, but wired from coffee at the same time, maybe not a good combination. In any case, I'm enthusiastic about most of the suggestions, even if I can't implement them all. I've updated the original post to just summarize the main points instead. 

[adrian]

With huge amounts of gratitude for everything you do to make PW as great as it is:

I know this is not in the intended spirit of this thread, so apologies for that, but honestly what I would most like to see is fixing all of the current Github Issues before anything new is implemented. I personally still have 49 open issues, many of which require ugly hook workarounds, some result in things being broken for site editors, and others are inconsistencies in the API which continue to trip me up. I am honestly struggling to put energy into thinking of shiny new feature ideas with these things always impacting my workflow.

 

[Juergen]

I would like to see SEO support integrated into PW by default. I know that there is the SEO Maestro module, which is fabulous, but I think every CMS should have a good SEO support by default.

So it would be great if a new tab will be added to the pages like this:

In addition to this, there should be a new property inside the configuration file to disable/enable the tab globally in the way like this.

$config->seo = false; // or true

And in the settings of the page, there could be a checkbox to enable/disable the SEO tab per page.

The content of the SEO tab could be as it is in the SEO Maestro module.

[szabesz]

9 hours ago, ryan said:

• Don't agree that Page objects need more initialization methods, but let's duke it out. ?

I've seen hooks added by Page objects as a reason for more, but hooks really don't belong in Page objects. There's no issue hooking to a method in a Page object, that's just fine. But Page objects preferably shouldn't themselves add hooks, or have methods that get called to hook into something outside of them. That's because that addHook() or hook implementation method gets added for every single (or multiple) page instance (whether Page or custom Page class), ensuring unnecessary duplication and overhead. Stuff like this ideally doesn't belong in multi-instance objects. This is one reason why modules that add hooks are almost always "singular" in their module info definition, ensuring no more than one instance of the module can be instantiated.

I do not think anyone suggested having "more" initialization methods. Instead, it would be nice to see fewer of them while still being able to initialize everything necessary. Most importantly, the documentation could be extended to show real-life examples of how to use Custom Page classes, including implementing some form of abstracted page request handling (both get and post) without having to use if/else trees at the top of template files.

Regarding adding hooks, I use a static method, which should not incur any overhead. I explain it in this post of mine:

Quote:

/**
 * ... page specific hooks. This method is called from site/init.php from my custom loop 
 * that runs for each frontend template based page.
 * if (in_array($templateName, config()->noneFrontendTemplates)) {
    * if ($templateName === "user") call_user_func_array("{$namespace}{$className}::initiate", []); // UserPage needs special treatment.
    * continue;
 * }
 * if (class_exists($namespace . $className)) call_user_func_array("{$namespace}{$className}::initiate", []); // Page classes register hooks in their initiate() method this way.
 */
public static function initiate() {
    parent::initiate();

    wire()->addHookBefore("Pages::saveReady(template=product)", function ($event) {

... more hooks go here ....

Having the code of hooks in the same file as the custom page class is a productivity booster for me. After all, in those hooks, the object we deal with is (mostly) a page object of that type. I would be happy to put that code in some other equally well-organized "spot" but putting hundreds of hooks directly into init.php and similar files is a big mess in my opinion.

 

Edited July 20 by szabesz
typo

[Laksone]

Just sharing my personal thoughts and what would be incredibly useful for a lot of my projects...:

• Very basic page builder functionality / WYSIWYG
  Especially something to build basic layouts with sections, rows, columns.
  I know there are third party modules and it can be achieved with repeater matrix but it get's unintuitiv very fast.
  That's actually the main reason to not use processwire for some of my projects.?
  
  
   
• Additional text fields for images fields
  alt text, title and caption is something that is actually constantly needed and i personally think that it could be the default (instead of setting up custom fields)
• Native .avif format support
  The .avif format would be a great addition and has a better compression compared to .webp
• full nginx support
  Have already hosted a projects without any issues but as far as i know it is not fully supported?!
• field type "date multiple"
  I guess that's a pretty specific one, but would be really helpful to me so i share it anyways.
  
  

[Jan Romero]

5 hours ago, adrian said:

I would most like to see is fixing all of the current Github Issues before anything new is implemented.

Full ack. I’ve long appreciated and admired the tasteful restraint with which Ryan has been steering the project all these years, but even so, PW has accumulated some features/concepts that could still use some love. The custom page classes being one hotly discussed example recently.

A lot of the suggestions here would make for great third-party modules. If we want more module developers and more core contributors, an official test suite may be helpful, as would better docs and more developer relations like this (also possibly someone deranged spamming memes on twitter every 10 minutes). Obviously I say this with two hearts beating in my chest, because we all know the failure modes of playing these engagement-chasing games and of large communities in general. 

Regarding database abstraction, to be a little flippant, if I wanted to pay for or manage that kind of hosting, I would be building on ASP.Net Core and not use an insane language where 0 == null. I’m here because PW runs on little shared hosting plans for less than a cappuccino a month, I think a lot of us are, and as much as that sort of thing is derided and reported dead, it’s an okay niche to serve.

(No hate here, I love Carson Gross, .Net, PHP and everything)

 

45 minutes ago, Laksone said:

field type "date multiple"
I guess that's a pretty specific one, but would be really helpful to me so i share it anyways.

It’s an absolute travesty that this sort of thing isn’t a browser feature. At least give us date ranges already.

[Pete]

12 hours ago, ryan said:

Thank you for all of the feedback! 

• Would enjoy building an asset manager but since my clients don't need it, I could only build it by self funding it. I don't have the ability to self fund it yet. 

It's actually sort of on the list for the projects we work on together Ryan, just I think the client is talking to me about it rather than give you another chunk of work to think about. Might be worth us discussing it next week.

[ceberlin]

I lost 85% of our clients to WordPress due to page builders like Elementor. They aren't concerned with code clutter, page speed and SEO disadvantages. I would love some offerings in that direction, I am aware that this maybe will open Pandora's box.

Some praise here for ProcessWire: ProcessWire is unbeatable for websites that almost work as applications. We coded the whole backend office management for our web design firm with ProcessWire including tons of SEO-, Data protection-monitoring- and wp-plugin-updates-montitoring crawlers and checkers: We kind of remote control WordPress from ProcessWire. Clients can log in and see everything they booked at a glance, and can order things directly from ProcessWire, and it is directly connected to the invoicing app. This is a unique system, 10 years of work in it and now makes the entire company manageable by a minimal team, unthinkable without ProcessWire.

Thinks I would like in PW4 are things I am used to from WordPress,

• a full switch to utf8mb4,
• those needed GDPR utilities out of the box,
• modules can be "deactivated" leaving the settings intact, and "removed" to make troubleshooting modules compatibility issues much easier.
• Some image optimization capabilities would be great, the existing 3rd party modules do not meet our expectations yet.
• Also a good monitoring/curation of outdated/abandoned modules, with supplied warnings, would be great; there are a lot of those old modules, unfortunately.

[Macrura]

Quote

This is likely more of a pro module type of thing, but I feel one area that ProcessWire is lacking from other comparable offerings out there is a site theme that is extendable and customizable from the admin backend. Tying a site-profile to the architecture of the site makes sense due to how PW is built, but being unable to switch a theme (even if temporary, to preview what the same content on a site might look like under a different skin), stylistically, after a site-profile is chosen is a little lacking. Even as a developer I like the ability to change things up now and then, but we don't really have a built-in way (that I'm aware of) a way to alter the frontend CSS via the backend using a known definition of basic templating to create themes. We can create one-off site-profiles, but not reusable themes.

I have a fairly decent but rudimentary theme engine that I use; the structure is templates/themes/[name-of-theme]. This has worked well especially in redesigning existing live sites; or as a way to test out how things look with different CSS; or to upgrade a commercial HTML template.

The theme engine also allows file override where the templates/views/some-view.php to be overridden by templates/themes/[name-of-theme]/views/some-view.php ; it's a wrapper for render, like wireRenderFile, so $theme->renderView('name-of-view), and $theme->renderPartial('name-of-partial'), would look in the current active theme for the file and if existing use that, and if not then use the one in templates/views or templates/partials.

i can switch the theme in my _init, which means i can e.g. clone a theme, then have it switch to a development version for me as a user, or by role. Like templates/themes/company vs. templates/themes/company-dev

The structure of the theme folder has stuff like _main.php (the main markup for the page), views, partials, assets, as well as theme specific functions, and a theme init where settings are configured.

[d'Hinnisdaël]

I tend to agree with some of the previous posts: ProcessWire is doing a lot of things right, but it feels like there's some catching up to do in terms of open issues and general level of polish. Some of these are making ProcessWire look a bit long in the tooth compared to other CMSs — catching up with the ecosystem here would be a great signal that it's a mature and stable project keeping up with the times.

• Full composer installation: all core files living inside /vendor, any user files and modules outside of it
• Automated test suite: at least for the critical parts like the selector engine and php version compatibility
• Extend image format support: WEBP, AVIF, JPEG2000, etc as input and output formats, as well extensibility for future formats without major architectural changes
• Semantic versioning: there's currently no way of knowing if an upgrade brings bug fixes or new features (and possibly new bugs), they're all patch releases lately
• Environment variables: read config from .env files to avoid editing/overwriting config files for each environment
• nginx support: Apache is showing its age somewhat, and a lot of deployment solutions target nginx by default

[szabesz]

55 minutes ago, d'Hinnisdaël said:

Semantic versioning: there's currently no way of knowing if an upgrade brings bug fixes or new features (and possibly new bugs), they're all patch releases lately

I'd like to highlight this because it only requires willingness and nothing more, but it would streamline upgrading efforts significantly. Enforcing it on 3rd party modules would also be welcome.

See: https://semver.org/

The current versioning chaos is a drawback for sure.

[teppo]

On 7/18/2024 at 1:08 PM, psy said:

Pagegrid and RockPageBuilder modules are leading the way to solve this issue. Kudos to both developers BUT the modules are premium while a WP site gives customers basic WYSIWG page editing out of the box.

My vote is to overhaul the admin UI/UX to make editing pages more WYSIWIG. 

 

10 hours ago, Laksone said:

• Very basic page builder functionality / WYSIWYG
  Especially something to build basic layouts with sections, rows, columns.
  I know there are third party modules and it can be achieved with repeater matrix but it get's unintuitiv very fast.
  That's actually the main reason to not use processwire for some of my projects.?

 

7 hours ago, ceberlin said:

I lost 85% of our clients to WordPress due to page builders like Elementor. They aren't concerned with code clutter, page speed and SEO disadvantages. I would love some offerings in that direction, I am aware that this maybe will open Pandora's box.

I'd love to suggest other things as well, but for now I'll just say that this is also my experience. Sorry in advance if this turns into a rant, but I feel that this is an important topic ?

Past few years we've shifted our focus so that now we mainly use ProcessWire for sites with heavy focus on application like features and structured content, while "regular websites" are more often built with WordPress. There are cases where ProcessWire is stronger, and it can be used to build flexible, content block based sites using something like Repeater Matrix, but to be fair Gutenberg (which I/we use solely, no other page builders) is on another level when it comes to built-in flexibility and WYSIWYG. With one exception: you can't have multiple "Gutenberg fields" on single page, which can, in fact, be a pretty big bummer in some cases; and that could also be a potential benefit if we did have some sort of block builder in the core.

(... and if ProcessWire, on a core level, wants to focus more on directory / application type sites, there's nothing wrong in that either. It just means that we, as a group of ProcessWire developers and enthusiasts, will be "losing" a large — and likely increasing — amount of potential clients and projects for other systems.)

The work done by Bernhard and jploch is fantastic, but for me the biggest question mark is probably that these are not core features, meaning that they are not something that is "officially supported" by the core / core team. They are also not free / open source software, which means that the community directly participating in their development is not really an option, in my opinion. I'm not sure what the best solution, especially since this is clearly not a common need/requirement for Ryan, but I do hope that we could eventually have some level of support for this at the core — even if it's not "full-featured", but rather a framework that can be expanded / built on top of.

Using Gutenberg as an example: I don't have a real figure, but I can tell that a team has worked on it for many years now, and continues to do it on a daily basis. It's not realistic to assume that a single developer could truly compete with that. And one thing I've learned about page/block builders is that there's a lot of nuance and the architecture is a major question that could make or break it, so doing it without solid understanding of what the results of each choice is way down the pipeline would be a huge gamble.

(In case of Gutenberg the architecture is a hot mess: there are no dedicated data structures, and they keep changing and breaking internal code all the time. But, again, they have enough resources to handle that, and the project has so much momentum that while developers may complain, eventually they'll have to go with the flow.)

As for Ryan's point about preferring to "avoid features that blur the line between content and style or front-end and admin", which I assume was related to this request (to some extent at least), I'm sure there are ways to handle content block GUI in the admin without putting too much focus on how they look like on the front-end. E.g. tje editing interface could be more like a wireframe with some similar structure than "the final product". Front-end editing is an option, but... I must admit that I like the "middle ground" that Gutenberg has, where you're still editing content in the admin. Obviously introducing front-end styles for the content in admin is not a nobrainer, which is why many sites — in my experience — won't even aim for fully stylized (custom) blocks in the admin.

WYSIWYG is a big topic in itself ?

[d'Hinnisdaël]

2 hours ago, teppo said:

As for Ryan's point about preferring to "avoid features that blur the line between content and style or front-end and admin", which I assume was related to this request (to some extent at least), I'm sure there are ways to handle content block GUI in the admin without putting too much focus on how they look like on the front-end. E.g. tje editing interface could be more like a wireframe with some similar structure than "the final product". Front-end editing is an option, but... I must admit that I like the "middle ground" that Gutenberg has, where you're still editing content in the admin. Obviously introducing front-end styles for the content in admin is not a nobrainer, which is why many sites — in my experience — won't even aim for fully stylized (custom) blocks in the admin.

That's a perfectly reasonable position to take as a CMS. The editing experiencing itself doesn't need to resemble the viewing experience — most of our clients are perfectly happy with a well-implemented split-screen, where they edit the page blocks on the left, and get a live preview on the right. As long as changes mirror instantly without a hard reload, they get what they want. This would be already be amazing to have in the core. I remember this being part of ProDrafts, but it wasn't worth the investment just for that feature alone if you're not using the drafts feature as well.

[szabesz]

8 hours ago, d'Hinnisdaël said:

most of our clients are perfectly happy with a well-implemented split-screen, where they edit the page blocks on the left, and get a live preview on the right.

I second this.

[adrian]

@ryan - can I also kindly suggest that Profields Table needs some love. There are lots of weird bugs as well as some things that I think would really improve the experience. In my eyes this is THE banner profield that really demonstrates what PW can do, but is not quite working as it should. eg (in no particular order):

 

 

 

 

https://github.com/processwire/processwire-issues/issues/1947

 

[MrSnoozles]

On 7/20/2024 at 7:21 AM, Juergen said:

I would like to see SEO support integrated into PW by default.

I'm so happy it comes as a very good module instead of being integrated by default. We're using PW to build internal tools as well, where SEO settings do not make sense.

 

On 7/20/2024 at 6:54 PM, d'Hinnisdaël said:

• Full composer installation: all core files living inside /vendor, any user files and modules outside of it
• Automated test suite: at least for the critical parts like the selector engine and php version compatibility
• Extend image format support: WEBP, AVIF, JPEG2000, etc as input and output formats, as well extensibility for future formats without major architectural changes
• Semantic versioning: there's currently no way of knowing if an upgrade brings bug fixes or new features (and possibly new bugs), they're all patch releases lately
• Environment variables: read config from .env files to avoid editing/overwriting config files for each environment
• nginx support: Apache is showing its age somewhat, and a lot of deployment solutions target nginx by default

Love this list, couldn't have formulated it better ♥ As for composer installation: This does not mean that an installation of ProcessWire has to get more technical. It could still be downloaded as a zip file and extracted. The only differences would be that instead of site&wire directories, you would have site&vendor directories. Also it would be possible to install a new ProcessWire instance directly from composer, as opposed to going to the website, finding the download page and downloading & extracting the zip archive. And it would appear a bit more professional, imo. I just see advantages here.

Edited July 22 by MrSnoozles

[Jan Romero]

9 hours ago, adrian said:

@ryan - can I also kindly suggest that Profields Table needs some love. There are lots of weird bugs as well as some things that I think would really improve the experience. In my eyes this is THE banner profield that really demonstrates what PW can do, but is not quite working as it should. eg (in no particular order):

I don’t have access to those threads, but I have bought ProFields several times and one Table-adjacent thing I’d enjoy would be docs/improvements for paginated FieldtypeMultis. I know there is some support for this in the core but I’m not sure it’s meant as a public API. AFAIK it’s currently only used by Profields Table. In particular I’m not a fan of it using the global pagination by default. I seem to remember some ugly hacks to be required to get independent pagination per field.

Edited July 22 by Jan Romero

[ryan]

@szabesz

Quote

I do not think anyone suggested having "more" initialization methods. Instead, it would be nice to see fewer of them while still being able to initialize everything necessary. 

I think the phrase "everything necessary" might be worth considering here. A class ideally just has one responsibility. Page instances are there to provide an interface to one page's content and be swapped in and out of memory on demand. When there are things like hooks going into a Page, that changes the role completely. If you start doing this a lot on a large site then it may affect scalability. Maybe it's fine for one individual installation or another, however. 

In your case, this isn't an issue, as you've solved that concern with a static method. I think that's okay for an individual installation, but it wouldn't be okay for PW to suggest for everyone because it's not multi-instance safe. The core avoids also static methods when possible because they are disconnected from any instance of the class. When there are static methods, it's always worth looking closer if it's worth the convenience (sometimes it is) or if they would be better off somewhere else. 

Using hooks in your /site/init.php, /site/ready.php or /site/templates/admin.php (when appropriate) is a safe strategy, but I agree it's not great if you have a ton of them. At that point it might be good to have an autoload Module, or to start including your own files from one of the previously mentioned ones. But if you find it beneficial to use /site/classes/YourPageClass.php then also consider a separate class (ProductPageTools.php?). Rather than having a static method, you can have a static variable in your ProductPage class that refers to that instance, but there will only ever be one of them, and it will be multi instance safe. 

Page classes already do this for a lot of things, delegating to other classes (PageTraversal, PageValues, PageProperties, etc.) for code that can be shared among all Page classes. There's only ever one instance of those classes, no matter how many Page class instances there are. And they are all multi-instance safe. This also keeps the memory requirements of the Page classes very low, since the Page class has very little code itself, and mostly delegates to other classes where the same single instance operates on all Page classes. 

class ProductPage extends Page {
  static private $tools = null;
  public function wired() {
    parent::wired();
    if(self::$tools === null) self::$tools = $this->wire(new ProductPageTools());
  } 
}

class ProductPageTools extends Wire {
  public function wired() {
    parent::wired();
    $this->wire()->pages->addHook('saveReady(template=product)', $this, 'hookSaveReady'); 
  } 
  public function hookSaveReady(HookEvent $e) {
    // ...
  }
}

Maybe you have a method with a lot of code that you want to be callable from ProductPage (any number of instances) but maintain in ProductPageTools (only ever one instance). This is how the core delegates to other classes and limits the scale and scope of classes that may have many instances. 

class ProductPage extends Page {
  // ...
  public function foo() {
    return self::$tools->foo($this);
  }
}

class ProductPageTools extends Wire {
  // ... 
  public function foo(Page $page) {
    $result = '';
    // A whole bunch of code to generate $result from $page
    return $result;   
  }
}

If the strategy you are using now works well for you then I'm not suggesting you change it. But just wanted to point out the strategy I'd suggest as a scalable and multi-instance safe one that also maintains separation of concerns and keeps the Page class from becoming complex or heavy. 

[ryan]

Quote

can I also kindly suggest that Profields Table needs some love. There are lots of weird bugs as well as some things that I think would really improve the experience. In my eyes this is THE banner profield that really demonstrates what PW can do, but is not quite working as it should. eg (in no particular order):

ProFields Table gets a ton of love, perhaps the most of any module I develop currently, as I work with in every single day. I looked at all of the threads you linked. The first linked thread has been waiting for your reply for awhile, and the last one is already in the GitHub queue. In the others, I'm seeing feature requests as well as some back-and-forth between us about one behavior or another, but none appear to be actual bugs. If you disagree on one or another, drop a reply to bump it in the relevant thread.

I try to focus on features that will benefit the largest audience. Following that I do try to add support for new selector features and things of the sort you've mentioned. Sometimes folks ask for things that might take more time than I have to implement and might only be used by one person, so I have to be selective in what gets added when, whether in Table, the core or any other modules. Generally if someone needs one particular feature and it won't take a lot of time to implement then I do try to implement when the request comes in. If I've not yet implemented something you want then it's more than likely just a matter of not having the time to do it immediately. That doesn't mean I don't love you, it just means I'm working within the resources I have. 

[ryan]

Quote

I lost 85% of our clients to WordPress due to page builders like Elementor. They aren't concerned with code clutter, page speed and SEO disadvantages. I would love some offerings in that direction, I am aware that this maybe will open Pandora's box.

Elementor is not part of Wordpress, but a plugin developed by someone else to run in WordPress. Maybe this is an opportunity for someone in ProcessWire. And there are already RockPageBuilder and PageGRID in ProcessWire to consider as well. 

The dominance of WordPress has always been the case, and it will likely continue to be the case. ProcessWire is unique and has always been something completely different from WordPress. The CMS projects that are trying to mirror WordPress never seem to last long because, if you want something like WordPress, then why not just use WordPress? Though I don't know anyone that really knows both well who prefers to develop in WordPress. Instead, WordPress dominance is largely a matter of name familiarity with clients, which is completely understandable. But there are also several things it genuinely does well, and I always believe in using the best tool for the job. If the types of projects you work on are a good match for WordPress, then great, but I hope you also have projects that are a good match for ProcessWire as well.  

Quote

a full switch to utf8mb4

ProcessWire fully supports it. Many (most?) of us is have used exclusively on new installations for years. 

Quote

those needed GDPR utilities out of the box,

I don't know what those are.  it sounds like another opportunity for modules. But more info needed. 

Quote

modules can be "deactivated" leaving the settings intact, and "removed" to make troubleshooting modules compatibility issues much easier.

Good idea. This is something I think I can do. 

Quote

Some image optimization capabilities would be great, the existing 3rd party modules do not meet our expectations yet.

Can you describe further?

Quote

Also a good monitoring/curation of outdated/abandoned modules, with supplied warnings, would be great; there are a lot of those old modules, unfortunately.

In the majority of cases, older modules will still work fine. I'm not aware of anything in the modules directory that does not work, but if any become apparent I will remove them. Maybe it would be a good community effort to identify modules that could be removed from the directory. 

Quote

Full composer installation: all core files living inside /vendor, any user files and modules outside of it

I think this might turn off as many people as it turns on. I know I wouldn't like it. But if it can be automated as an installation option then sure, why not.

Quote

Extend image format support: WEBP, AVIF, JPEG2000, etc as input and output formats, as well extensibility for future formats without major architectural changes

ProcessWire already supports WEBP and has for awhile. I was working on core AVIF support, but Robin S. released an AVIF module so I put mine on the back burner. And this may be the sort of thing that is better as a module, or maybe it'll be better in the core at some point, I'm not sure. 

Quote

Semantic versioning: there's currently no way of knowing if an upgrade brings bug fixes or new features (and possibly new bugs), they're all patch releases lately

Right now we don't build core versions in a way that breaks things from one to another. At least not in a way that is known at the time of assigning a version number. When that changes, I think we'll want to adopt semantic versioning, and maybe that's a part of 4.x. Maybe it would benefit 3rd party modules more in the shorter term, so it's worth looking at there first. 

Quote

Environment variables: read config from .env files to avoid editing/overwriting config files for each environment

Sounds interesting but I need more details. 

Quote

nginx support: Apache is showing its age somewhat, and a lot of deployment solutions target nginx by default

If there's anyone that is an nginx expert that wants to step up to have this responsibility I'd welcome it. I've mentioned this before too, but nobody has stepped up. I'm not an nginx expert so don't feel qualified to support it on my own. 

Quote

The current versioning chaos is a drawback for sure.

For real? This is the first I've heard of any chaos.

Quote

The editing experiencing itself doesn't need to resemble the viewing experience — most of our clients are perfectly happy with a well-implemented split-screen, where they edit the page blocks on the left, and get a live preview on the right.

Good to hear. We do have the PageAutosave module which does Live Preview even better than ProDrafts. This module is available in ProDevTools or ProDrafts boards, but maybe it can have a wider release. 

Quote

I would like to see SEO support integrated into PW by default. I know that there is the SEO Maestro module, which is fabulous, but I think every CMS should have a good SEO support by default.

This is exactly the sort of thing that PW is great at supporting already. But I have been exploring building an everything-SEO module here, as it's something I'd like to use and support, but just not as part of the core. The hard-core SEO experts will still want to do their own SEO stuff like they do now, but for those that want something they can turn-key and have it all ready, a module is ideal. I'll very likely be building one within the next year hopefully. 

[adrian]

@ryan - I have responded again to the ones that I think I bugs that still need fixing. You are right that some are feature requests - my point being that I think these are really useful requests that others would also benefit from. Of course it's up to you to decide if you agree, but obviously we are all going to push for things that we'd personally like to see.

[ryan]

Quote

I don’t have access to those threads, but I have bought ProFields several times and one Table-adjacent thing I’d enjoy would be docs/improvements for paginated FieldtypeMultis. I know there is some support for this in the core but I’m not sure it’s meant as a public API. AFAIK it’s currently only used by Profields Table. In particular I’m not a fan of it using the global pagination by default. I seem to remember some ugly hacks to be required to get independent pagination per field.

@Jan Romero No hacks are necessary and it's actually much simpler than I think you might realize. The row pagination essentially works the same as with pages, and you can override the current pagination in the same way (via start and limit). The only difference is where you call it from. Why don't you open a topic in the ProFields Table support board? I'm happy to answer any questions you have.