Weekly update – 11 July 2024

[bernhard]

@ryan thank you for your reply on my last post.

11 hours ago, ryan said:

class MyPage extends Page {
  static private $ready = false;
  public function wired() {
    parent::wired();
    if(!self::$ready) {
      // your init code... 
      self::$ready = true;
    }
  }
}

I have to think about everything that has been said, but I have to mention here that

1. this might not be trivial for someone new to OOP where everything that he/she wants to do is add a hook
2. this will only work if you have at least one instance of that pageclass loaded. So if there is no page loaded (or no page exists) yet with that template then hooks will not be added and therefore some important features might not work and you'll get unexpected results.

I understand what you said about why you don't want to have them in the pageclass itself, but I still think PW could make it easier to guide/support the user (that might be totally new to OOP) in how or where to attach hooks that are "related to" (whatever that means) the pageclass. Similar to what we have with /site/ready.php and /site/init.php, which is really trivial. ? 

@FireWire fully agree!

[ryan]

Quote

So to elaborate on what I stated originally, I think demonstrating how you would approach some of these advanced techniques natively in PW (showing that a feature request to make it "nicer" is not necessary / technically problematic) in a real working app would be very helpful. 

@Jonathan Lahijani I'd need specific examples to respond to or questions to answer. 

Quote

I believe you attempted this with the site-invoices profile and building it out further with more web-application-y type techniques would really be great.

This is a fully built out profile. I think some might expect that I would classify/objectify everything, but I don't do that unless there's a strong reason for doing so. I use classes when there's an OO reason for doing so, and rarely is "group of related functions" one of those reasons, unless for sharing and extending. 

Using custom page classes or OOP is not at all necessary for most installations. It's only when you get into building larger applications that you might benefit from these things. And even then, it's not technically necessary. 

One good reason to use custom Page classes is just to have a documented or enforceable type, with no need to have any code in the actual class: 

/**
 * @property string $title
 * @property float $price
 * @property PageArray|CategoryPage[] $categories
 * @property string $body
 * @property Pageimages $photos
 */
class ProductPage extends Page {}

If you add something to the class, it might be to add an API for the type's content that reduces the redundant code you'd need when outputting it. 

class ProductPage extends Page {
  /**
   * Get featured photo for product
   *
   * @return Pageimage|null
   *
   */
  public function featuredPhoto() {
    $photos = $this->photos;
    if($photos->count()) return $photos->first();
    foreach($this->categories as $category) {
      $photo = $category->photos->first();
      if($photo) break;
    }
    return $photo;
  }
}

 

Quote

It would be nice if there was a platform integrated into the PW site to list/promote and maybe even buy commercial modules

I'd like that too. Maybe "buy" is a longer term goal, but shorter term I'd be interested in suggestions for how best to help promote others modules. 

Quote

...this might not be trivial for someone new to OOP where everything that he/she wants to do is add a hook

@bernhard There's no need to use OOP in ProcessWire, especially for someone new to it. ProcessWire does all the work to make sure that by the time your template file is called, you are output ready. So it's only once you get to be more advanced that you might then start using hooks, and you might never use OOP. If someone wants to add a hook, the most reliable place for that is the /site/ready.php file, or in some file that you include from it (conditionally or otherwise), and that's what I'd recommend.

Quote

this will only work if you have at least one instance of that pageclass loaded. So if there is no page loaded (or no page exists) yet with that template then hooks will not be added and therefore some important features might not work and you'll get unexpected results.

ProcessWire wouldn't even load your ProductPage.php file if no instance was created. But even if it did, why would there be a need for any hooks related to page class "ProductPage" if no page of the type is ever loaded? Maybe I'm missing something. 

You already know I'm skeptical of hooks being added by Page objects, but now we're talking about hooks that aren't even related to the page class being within it? ? If there are, they still wouldn't be called unless something triggered PW to load the ProductPage.php file. And the primarily reason it would load the file is to create an instance of the class. 

Quote

I still think PW could make it easier to guide/support the user (that might be totally new to OOP) in how or where to attach hooks that are "related to" (whatever that means) the pageclass. 

That makes sense. For most I'd suggest this:

$wire->addHook('Pages::saveReady(template=product)', function($e) {
  // ... 
}); 

Or this if you are using custom page classes, and want to capture ProductPage and any other types that inherit from it: 

$wire->addHook('Pages::saveReady(<ProductPage>)', function($e) {
  // ... 
}); 

If conditional for the requested $page, then wrap the call in an if()

if($page->template->name === 'product') {
  $wire->addHook(...);
}

If you need to hook the same method for multiple types, it can be more efficient to capture them all with one hook. Maybe you want it to call a saveReady() method on any custom Page classes that have added it. Since you wanted hook type code in the Page class, here's how you could do it without having hooks going into the Page class: 

$pages->addHook('saveReady', function($e) {
  $page = $e->arguments(0);
  if(method_exists($page, 'saveReady') $page->saveReady(); 
}); 

Rather than more initialization methods, if you needed hook-related implementation in the custom Page class, the above is the sort of thing that I think would be better. At this point, it's only about being "ready to save THIS instance of the page" which I'd have no concerns about. I could even see the core supporting this so that you could just add a saveReady() or saved() method to the custom Page class, and neither you or the core would even need to use hooks.

But back to hooks, if you don't want to load up your /site/ready.php with code, maybe just use ready.php as the gatekeeper and organize them how you want. If you only need hooks for the admin, maybe put them in /site/templates/admin.php. If you want to maintain groups of hooks dedicated one type or another, put them in another file that you include from your ready.php file: 

include('./hooks/product.php'); 

I understand you like to maintain these things in or alongside your Page class files. Your MyCustomPage.php class file is one that might be suitable because those hooks won't get added unless an instance of the class is created, or something does a class_exists('ProcessWire\ProductPage'). I think you did something like the following in an earlier example, and it's just fine because it's independent of any instance and doesn't add pointers into any specific instance, and will only ever get added once: 

class ProductPage extends Page {}
$wire->addHook(...);

Or maybe you want the hooks in a separate related but dedicated file. It would have the same benefits as the previous example, but isolated to a separate file: 

class ProductPage extends Page {
  public function wired() {
    require_once(__DIR__ . '/ProductPageHooks.php'); 
    parent::wired();
  }
}

Maybe you want to do it for all classes that extend BasePage.php. Or you could use a trait, but here's an example using inheritance: 

// site/classes/BasePage.php
class BasePage extends Page {
  public function wired() {
    parent::wired();
    $f = __DIR__ . '/' . $this->className() . 'Hooks.php';
    if(file_exists($f)) require_once($f);
  }
}

// /site/classes/ProductPage.php
class ProductPage extends BasePage {}

 

Quote

Similar to what we have with /site/ready.php and /site/init.php, which is really trivial.

The word "trivial" means "of little value or importance" and I wouldn't agree with that classification of these files. But I think you might (?) mean that it's really "basic/simple" (which is meaning I think of sometimes too), and that's actually the goal of it, so I would agree with that classification. 
 

[cwsoft]

@ryanThank you very much for the code examples you provided for possible hook options related to PageClasses. Personally like the idea of including a page related hook file following the naming convention concept of PageClasses like PageNameHook.php. Will try some of those concepts soon in a real world project I am working on right now.

[ryan]

Quote

Assuming one were to take this approach, what is the proper/recommended way to load the ProductPageTools.php class file?

@Jonathan Lahijani  Preferably use require_once() or include_once(). But if you prefer autoloading, you could add this in your /site/init.php if you wanted to autoload any classes in /site/classes/ that ended with "PageHooks": 

$classLoader->addSuffix('PageHooks', $config->paths->classes);

ProcessWire's class autoloader is more efficient than most, but if you already know a file exists and where it is, I prefer to require_once(). It's more efficient and more clear, nothing hunting for files behind the scenes. There's a reason why this file exists in ProcessWire, even though all of those classes could likely load without it. It makes the boot faster. Class autoloading is obviously necessary for many cases, especially if working with other libraries. But for a case like the one mentioned here, skip the autoloading unless you feel you need it. 

 

[poljpocket]

Hi all. Reading through the discussion about page classes, I have to add my two cents.

I feel like we are mixing concepts here. We are talking about OOP concepts where the request arises to extend page classes' capabilities to better allow for separation of concerns. Many OOP concepts stem from or are just a fancy form of the MVC pattern. I strongly believe ProcessWire follows such a form too. Whereas the core handles MC and it's API provides endpoints for the V in Model-View-Controller and hooks for extending and altering the C part.

So to really allow for separation of concerns, page classes aren't the right place to start off. A page is just the representation of an entity, a line in the database. Instances of said class that is. And thus Page and page classes belong to the Model part of ProcessWire. And this is exactly where my motivation to side with @ryan and his general scepticism of page class init and ready methods comes from. So it makes sense to add virtual properties or basic relationships to the page class. But the model should never contain business logic which acts outside of the lifecycle of the entity.

Having made my point so far, I think Ryan's second to add a new class file to act as a controller (by using the ProcessWire's hooks) makes a lot of sense. And exactly that is why I believe, ProcessWire already offers a very good way to enforce MVC patterns and true separation of concerns. It offers a good API without forcing everyone to use the same architectural patterns so many other systems do.

Edited July 26 by poljpocket

[szabesz]

18 minutes ago, poljpocket said:

Model-View-Controller

And where is the separation of the View and the Controller when the example is this:
https://github.com/processwire/site-invoices/blob/main/templates/home.php
? How about implementing a faceted navigation like that in a template file?

We have the Model for the frontend in the form of the Page class, which is fine. We also have the View for the frontend in the form of the template file, which is also fine. What I am missing is the "official support" for the Controller. If the other two components are already in place, I believe it is reasonable to request the third one so that we do not have to invent our own if we prefer not to.

[d'Hinnisdaël]

@poljpocket Very true. From that perspective, it definitely makes sense to keep page classes lean und encourage proper separation of concerns. All frameworks have their conventions around distributing functionality. In Laravel, display logic might go into a ProductPresenter, admin form business logic into a ProductAdminController. In ProcessWire, we have ProductClass for display logic and ProductModule for business logic. That might not be for everybody, but it's more of a guiding principle than a hard requirement.

[d'Hinnisdaël]

4 minutes ago, szabesz said:

We have the Model for the frontend in the form of the Page class, which is fine. We also have the View for the frontend in the form of the template file, which is also fine. What I am missing is the "official support" for the Controller. If the other two components are already in place, I believe it is reasonable to request the third one so that we do not have to invent our own if we prefer not to.

The cleanest way to do this currently is handling the request and preparing data inside /site/templates/home.php (controller) and then including a view from /site/templates/views/home.php. Using modules such as TemplateEngineFactory, this becomes the default. Prepare data in a PHP file, then render a Twig/Smarty/Latte view. It's certainly not as clean as having a proper controller class pattern available, that's for sure, but it's a pattern that works across projects of all sizes (at least in my experience).

[szabesz]

14 minutes ago, d'Hinnisdaël said:

The cleanest way to do this currently is handling the request and preparing data inside /site/templates/home.php (controller) and then including a view from /site/templates/views/home.php. Using modules such as TemplateEngineFactory, this becomes the default. Prepare data in a PHP file, then render a Twig/Smarty/Latte view. It's certainly not as clean as having a proper controller class pattern available, that's for sure, but it's a pattern that works across projects of all sizes (at least in my experience).

...meaning one solution is to utilize the template files (originally meant to be the view) as controllers and provide the view through a 3rd-party module or a similar custom solution that one implements.

While that is a working solution for sure, it highlights the fact that MVC for the frontend is somewhat overlooked by ProcessWire, not guiding newcomers into recommended patterns and/or best practices.

I think even beginners in PHP should be pointed in a direction that encourages learning best practices and design patterns that will help them become good developers, instead of recommending the "direct output" because that will be enough for their first few small projects.

Edited July 26 by szabesz
typo

[dotnetic]

ProcessWire Improvement Suggestions

I’m pleased to see ideas being gathered to improve ProcessWire, and as a loyal user and contributor since 2014, I'd like to share my list and thoughts on the matter.

Over the past few years, there has been a lack of clarity on whether requests and ideas will be implemented, and if so, when. Requests and issues often remain open for years without updates. I'll address how this can be optimized.

There is also no clear way to influence these decisions.

Years ago, we introduced the idea that thumbs-ups in the Requests Repo should mark the importance of requests. However, there's still no way to know if any of these points will be implemented. My idea for the future is as follows:

Increase Community Involvement and Establish a Fixed Release Cycle

Optimize Integration of Requests

It could be beneficial to review which GitHub issues have the most thumbs-ups within a set period (e.g., quarterly or biannually) and then fix or implement them.

If there are too many features or if requests have the same number of thumbs-ups, a poll could be conducted in the forum to see what the community wants implemented first.

Introduce New Status Labels for Requests

• Under consideration
• In Progress
• Completed

Faster Closure of Issues

When a request is integrated, it should be closed immediately rather than marked as “completed.” Often, the requester doesn’t provide feedback or forgets to close the issue (which has happened to me as well). If something doesn’t work, the issue can be reopened.

Automatically Close Stale Issues

There is a stale action for GitHub that automatically closes issues after a period of inactivity. The issue creator can reopen it by responding.

Better Definition of ProcessWire’s Target Audience

The target audience for ProcessWire is not clearly defined. This makes it difficult to determine which features are truly necessary.

Developers will likely have different requirements compared to someone looking to create a website quickly and cheaply.

Developers eventually hand over the website to a client, who then manages the content themselves.

Non-developers struggle to know which modules exist to manage their website. The module installation process is cumbersome, which is why I developed the ModuleManager2 years ago (link). Despite user interest, it hasn’t been widely used. There was a discussion that module installation directly through ProcessWire was rejected for security reasons (though my module only uses core methods). Integrated module management, similar to systems like WordPress, Prestashop, or Shopware, would simplify module discovery, installation, and maintenance.

Discovery Process

The discovery process is beneficial for all users, including power users. Sometimes I can’t remember a module’s name, but with MM2, I can search for a term in the description and find the corresponding module.

Security is a concern, but I believe it’s possible to implement this in a secure way.

PHP 8 and Named Arguments

Finally, PHP 8 and named arguments will greatly assist in module development.

Easier Customization of the Admin Theme

Custom Navigation

It's cumbersome to change the navigation or create a completely custom one without creating a new admin theme. This has been mentioned before (insert link). This is usually only necessary when developing custom software with ProcessWire.

• It would be helpful to create menu items that link to modules or specific actions within those modules, or simply a URL path.
• Introduce a dark mode (toggle switch). A quick solution is with one line of CSS: nightowl, but an integrated dark mode would be better.

Global Media Manager

A global media manager is a great idea, especially for certain assets like logos or seals used across multiple pages. While it’s possible to create a page and field to source these images, it’s not user-friendly for newcomers.

For instance, I have a client with 30 product pages that require seals to be updated annually. A central management point would simplify this process. I’ve implemented this for my client, but it’s challenging for those accustomed to systems like WordPress and conceptually difficult to grasp.

Aligning with Conventions from Other Frameworks

Environment Configuration

A .env file to store database connections, httpHosts, etc., which are read by site/config.php and site/config-dev.php.

The config-dev.php file should include config.php and allow properties to be modified/overridden. This is how I and others currently do it (insert reference).

Automated Deployments and Module Updates

Composer is a stable package manager for PHP and a convention widely used in the PHP community, making automated deployments and updates easier.

Built-In SEO

Built-in rudimentary SEO would be a significant plus for websites. During installation, users could choose between a website or custom software without a frontend. If they choose a website, either ProcessWire-Core-SEO or the SEOMaestro module could be selected for installation.

Lack of Visibility on ProcessWire Adoption

There is no clear overview of how widely ProcessWire is adopted, such as the number of installations. This lack of visibility can make it difficult to gauge the platform's popularity and growth.

Absence of a Marketplace Ecosystem

The absence of a marketplace ecosystem makes it uncertain for module developers like Bernhard or myself to determine whether and how much money can be made from developing modules for ProcessWire.

Other systems like Kirby, Statamic, and WordPress have a store that can be accessed directly through the admin interface. These stores also include license management, making it easier for developers to monetize their work and for users to manage their purchases.

Proposed Marketplace and Revenue Sharing

One idea could be to introduce a marketplace for ProcessWire, where a portion of the revenue from sales is reinvested into the development of ProcessWire. However, this is not a necessity and should be a point of discussion, considering the controversies seen with Epic or the Apple Store.

[wbmnfktr]

1 minute ago, szabesz said:

I think even beginners in PHP should be pointed in a direction that encourages learning best practices and design patterns that will help them become good developers, instead of recommending the "direct output" because that will be enough for their first few small projects.

As a default? Big NOPE from me.

The super easy way and low barrier to enter the world of ProcessWire was one of the main reasons I gave it more than a quick look, did all the tutorials, read the docs, read the forum, ... and stayed.

I tried a lot of CMSs back then and because ProcessWire had this "direct output"-way of achieving a lot without needing to know much about PHP or programming in general was the biggest PLUS ever.

if/else/echo/foreach is almost everything you need to know to get up and running - and this quite far. Easier than anything.

Easier than the Wordpress-loop, Silverstripe's way of doing things, or Drupal and Typo3.

Such a delight and super fun to learn something new, a new CMS.

 

Sorry for interrupting this great discussion.

[poljpocket]

@wbmnfktr was just a minute faster, but I feel exactly the same way: I have to say I am using ProcessWire exactly because it doesn't force me into a direction and/or into a form of "best practice".

But nevertheless I think there is already a lot of controller in the ProcessWire core. What you @szabesz want I think is a way to create your own controller manifested as a class and tightly integrated in the request lifecycle. But can't you already do that? That is the beauty of ProcessWire. You can alter anything I can think of with hooks. They will allow you to create a fully-fledged controller system if you want to. But again, I feel like ProcessWire handles most of the controller stuff one would ever need.

[ryan]

Quote

And where is the separation of the View and the Controller when the example is this:

Output logic is a part of the view. When I build a site profile to share with others my primary goal is to make it as simple and easy-to-follow as possible. For most websites powered by ProcessWire the template files are the views, and that's where I think most should start too, as it's very simple. As needs grow, many will naturally isolate the views to reusable files separate from the template files when it makes sense (like that parts directory in the invoice profile). But I think it's good for PW to be less opinionated about that because people may be using different template engines, different output strategies (direct, delayed, markup regions), etc., or they may not even care about following an MVC pattern, even if PW naturally leads there. This pattern was around before we had web sites/applications, so the "view" part is not like it was when we were building desktop applications in the old days with Borland C++. With HTML we've got server side markup and the additional layers of client side CSS and JS. Not everyone always agrees about where to draw the lines and it can depend on the case. I don't think we should decide that for people and I think it's good to be flexible on on this part of it. 

[Gideon So]

7 hours ago, wbmnfktr said:

I tried a lot of CMSs back then and because ProcessWire had this "direct output"-way of achieving a lot without needing to know much about PHP or programming in general was the biggest PLUS ever.

if/else/echo/foreach is almost everything you need to know to get up and running - and this quite far. Easier than anything.

Easier than the Wordpress-loop, Silverstripe's way of doing things, or Drupal and Typo3.

Such a delight and super fun to learn something new, a new CMS.

This is super true.

Gideon

[theoretic]

Hi friends! And thanks for ProcessWire!

Maybe I'm a bit late to the party, but I'd also like to bring some ideas here. Processwire is a great CMS having many brilliant ideas inside. But there's always some space for further improvements.

JAMStack paradigm

It's about static html pages which have some javascript-driven parts interacting with some APIs and changing their look and feel depending on what users do and which data API provides. Sometimes there's just a single static html page which behaves as a multipage web application, sometimes there are just small dynamic chunks. This approach has many advantages:

• There's no need to generate pages each time they are requested from server. They can be generated just once.
• Returning static pages drastically reduces the server loading.
• Static pages are safe by nature. There's nothing to hack there. And even if someone hacks into the server, there will be only some static html files there.
• APIs return pure data, no html at all. The most typical API data format is JSON which is pretty compact and human readable already, and there are others (bson etc.) which are even more compact.

Processwire vs JAMStack

The current ProcessWire is pretty far from JAMStack paradigm:

• By default, PW is about generating pages on each server request. And, being fair, lots of such pages could be static (generated only once).
• If someone will take a closer look to how the actual PW admin works, he/she will find that there are ajax-driven things there. But in these cases PW generally returns the chunks of html markup, not pure data.
• There's no native PW tools providing an easy way to build an API over PW. There are some 3rd part modules, and it's not a rocket science to build a PW-based API from scratch, but no native support out of the box.

Processwire as "headless CMS"

Headless CMS is a CMS which can only return data, not html. This approach is an important part of JAMStack approach, and there's plenty of such CMSs on the market. PW can be a perfect headless CMS, but it's not by default. You need to build an API on the top of PW to make it "headless". I did this in some of my projects, and I'm quite happy with the result. But, come on, give me a reason why this functionality doesn't deserve to be in the PW core? )

Processwire as "static site generator" (SSG)

SSGs are another important part of JAMStack world. They are tools allowing You to make static html files based on the data and the templates You have. Contrary to headless CMSs, SSGs are generally the tools used locally, and the result (static pages) is later uploaded to server. It's quite interesting that PW can be a server-based SSG! I also did this, and I was quite satisfied again. But AFAIK there's no core-level or even 3rd party tools to do this using PW.

Bringing the pieces together

PW can make a big step from the ol' good paradigm of server-side page rendering to the modern JAMStack. Two things are missing:

• Native tools for building an API on top of PW. Again, it's doable, but it's not native.
• A PW-compatible (maybe even PW-based) SSG which won't be a headache.

Both things are not rocket science, and they potentially could bring much more attention to PW, make it interesting for younger devels. I had a lot of talk like "ahhh You're that guy from 90ties, still writing php code and making server-rendered pages? You're the past already, man!".

Hope this will worth a good discussion ?

[AndZyk]

19 hours ago, theoretic said:

But AFAIK there's no core-level or even 3rd party tools to do this using PW.

Hello @theoretic,

have you tried StaticWire?
https://processwire.com/modules/static-wire/

I have used it once for a locally hosted website for a exhibition, but it worked for me as a basic SSG.

For online hosted websites I always use ProCache, which is AFAIK similar to a SSG :

Quote

• A static cache of your page output, enabling pages to be delivered without PHP or MySQL. This results in mindblowingly fast "time to first byte" scores, and the difference is visible and obvious to not just search engines, but your visitors too. This is the original and most important feature of ProCache.

https://processwire.com/store/pro-cache/#procache-is-for-speed-and-seo

Regards, Andreas

[ryan]

@theoretic

Quote

You need to build an API on the top of PW to make it "headless".

It's actually the opposite of that. ProcessWire is an API and that's all it is. Any output comes from the user of the API and not from ProcessWire, as it doesn't output anything on its own. 

ProcessWire started as a headless CMS, before the term even existed. The admin was later added on as an application built in PW, and then grew from there. But the base of PW is still just nothing but the API. ProcessWire itself doesn't output HTML. But since most use it for that, all of our example site profiles output HTML. There could just as easily be a site profile that outputs JSON or XML, or whatever you want it to. The point is PW has always been separate from whatever you choose to output with it, so that it has no opinion about what you use it for.  While we could have a site profile that outputs something other than HTML, I don't really know what we would have it output or who it would be for, but maybe someone else does (?), it would be a simple matter. 

[ryan]

Quote

I have to say doing commercial modules in PW is hard. The target group is small and the marketing of the module is the sole responsibility of the developer (eg. building a website/shop to promote and get the module).

@jploch @bernhard Long term I think we'll want to make it possible for others to sell their commercial modules here. But short term, what else can we do to help? You've both written some amazing page building software that deserves a lot of attention. Would you like to do a blog post about about it here? Or should we maybe have section on the site that highlights these tools? Perhaps something on the download or modules page? Doing commercial modules is hard either way, for me too, but I think it benefits all of us to have these tools available. Let me know what I can do to help. 

[ryan]

@szabesz

Quote

Regarding page content creation by "site editors" in the admin, since TinyMCE's future regarding its open-source state is questionable, Dan Brown at BookStack started to implement a replacement based on lexical:

I've thought Lexical looks like a really interesting project so have been curious about it. I can't even make past the first line of their quick-start work though, it gives me a JS error. I'm interested to see what the guy from BookStack comes up with. I'd also like to experiment with Lexical more. 

TinyMCE is providing custom open source licenses to projects like ours, and I have requested it from them here, but so far the responses I've received from them don't seem to be aware of any of it. They've been giving me prices for commercial licenses, so I'm kind of confused. There is a fork of TinyMCE 6 called HugeMCE that will apparently continue on the MIT license, but not clear how far that will go. 

[webdecker]

Similar to what @wbmnfktr and @poljpocket said before, I like PW so much because it is an API with a backend, the api is well documented (!), it is so easy to install, easy to update, easy to understand, easy to extend and customize, it can be installed anywhere, it is so direct, I can program simple php templates to output what I want the way I want. I could build simple websites and more complex web applications on my own without the need of experts of this and that technique  or paradigm. That's cool!
Please keep it simple, keep it that way and don't overload the core with too many features... ?
 

[monollonom]

12 hours ago, ryan said:

@jploch @bernhard Long term I think we'll want to make it possible for others to sell their commercial modules here. But short term, what else can we do to help? You've both written some amazing page building software that deserves a lot of attention. Would you like to do a blog post about about it here? Or should we maybe have section on the site that highlights these tools? Perhaps something on the download or modules page? Doing commercial modules is hard either way, for me too, but I think it benefits all of us to have these tools available. Let me know what I can do to help. 

One can have a look at how others do it: https://plugins.getkirby.com/

There the navigation is clearer as the categories are tucked away under “Types” and allows to have a clearly visible “Paid modules” menu link (Pro Modules could go under there as well as “First party paid modules”). Also they have no centralized way of selling modules, authors adding links to their own ecommerce solution (be it a custom one, Gumroad, ...). One thing I note though is even the paid modules are released on Github (but always mentionning how they are not “free software”), on PW modules are also required to have a Github page to be listed (I assume to be auditable / accountable).

Regarding a blog post, I’m not selling anything but I guess it could be nice even though it remains a one-off promotional tool.

Edited July 30 by monollonom
Removed last part, I realise it doesn’t help much the discourse and can be interpreted wrongly. Sorry about this

[jploch]

Like others I was also attracted to PW by the simplicity and low entry barrier. @ryan I am very grateful for the work you put into PW. The development experience with building the module was great, even addictive and I learned a lot on the way.

10 hours ago, monollonom said:

One can have a look at how others do it: https://plugins.getkirby.com/

I was also going to suggest Kirby as a good example. I think a redesign of the modules page would help a lot. A buying option is maybe not needed for now, but having a category like „commercial/paid“ that is easy to find. Also a „module of the month“ or „loved by the community“ (based on likes) section and a prominent spot on the homepage to highlight some modules would be nice. I am on mobile right now and can post more thoughts on this once I have some time. 

Edit: Also +1 for letting superusers access this new "module explorer" from the admin. This would make installing modules even easier and give new modules more attention. (Maybe we can address the security issues, that were mentioned.)

[theoretic]

On 7/29/2024 at 5:57 PM, AndZyk said:

Hello @theoretic,

have you tried StaticWire?
https://processwire.com/modules/static-wire/

I have used it once for a locally hosted website for a exhibition, but it worked for me as a basic SSG.

For online hosted websites I always use ProCache, which is AFAIK similar to a SSG :

https://processwire.com/store/pro-cache/#procache-is-for-speed-and-seo

Regards, Andreas

I took a look at StaticWire. It's truely a basic SSG, but IMO it's rather a local tool not intended for use in hosting environment. It's okay if You have some hundreds of pages, but what if there's 1000+ of them?.. Generating a lot of static files at once can take too much memory and time, so personally I opted for a lazy static pages generation. Here's my module doing exactly this:

https://github.com/theoretic/StaticPages

It's open source, and it's free.

[theoretic]

On 7/30/2024 at 1:01 AM, ryan said:

@theoretic

It's actually the opposite of that. ProcessWire is an API and that's all it is. Any output comes from the user of the API and not from ProcessWire, as it doesn't output anything on its own. 

ProcessWire started as a headless CMS, before the term even existed. The admin was later added on as an application built in PW, and then grew from there. But the base of PW is still just nothing but the API. ProcessWire itself doesn't output HTML. But since most use it for that, all of our example site profiles output HTML. There could just as easily be a site profile that outputs JSON or XML, or whatever you want it to. The point is PW has always been separate from whatever you choose to output with it, so that it has no opinion about what you use it for.  While we could have a site profile that outputs something other than HTML, I don't really know what we would have it output or who it would be for, but maybe someone else does (?), it would be a simple matter. 

Thank You @ryan! Maybe I was slightly wrong. Of course PW is not about "returning html by default". It's a site profile thing, not a core thing. Making an API-dedicated site profile is a perfect idea. Or even an "API + headless CMS" profile. I have seen some API-dedicated PW modules, but, considering the PW architecture, it could be better to have API functionality at site profile level.

[bernhard]

Hey @ryan thank you very much for the invitation to write a blog post. I'll probably ping you about that when my client projects that I'm working on are done!

Regarding selling modules: I want to add that it can be very complicated to sell stuff online in the EU due to tax regulations. In very short as soon as you hit 10.000€ revenue you need to charge tax in the country of the buyer, which can be 7% CH, 19% DE, 20% AT etc... There are companies that offer the service to sell stuff for you, so you only have one customer instead of hundreds. But they charge for it, of course.

So if you ask me it would be ideal if PW had a shop for commercial modules where all you have to do is add a github link to a private github repo and PW does the rest. Which is invoicing, taxes, generating license keys, offering download links etc. I know it's a huge task to do, but if I'm just sharing my point of view from selling modules. It would also be great if the customers were able to update modules with one click, just like they can do with regular modules. In case of commercial modules the'd need to have a valid license key in their settings, of course. And of course, that should only be done on development environments.

I'd be more than happy to pay a reasonable share for that and support the project with my work.

------------------------

But what I actually wanted to say: @ryan could you please make it more obvious how great PW is and how actively it is developed?

I think @teppo does a great job with his weekly newsletter and that also deserves a lot more attention! I just checked the website and the github repo again. I know we've "lost" people just because they looked at the github repo and saw the last commit on the main branch was over a year ago and they thought the project is dead. We all know better, but newcomers don't and the amount of work put into PW is unbelievable and people should instantly see this!

I also checked the download page on the website:

These two buttons probably don't mean anything to a newcomer. And the sentence below is really hiding itself.

What about something like this?

The breaking change thing might get a footnote that we are talking about breaking changes to the API here. English is not my first language so there might be better wordings, but you hopefully get the idea. Or maybe something like this:

I think "we" already have an absolutely great product and we can be very happy to be able to use it. @ryan I hope you are very proud ? 

But I think this is not obvious to someone evaluating ProcessWire and maybe we could do more in that context. I don't know if growing the userbase of PW is a goal of @ryan at all or should be. But at least for selling modules it would be a benefit. Also when looking for a job it's a lot easier to find an employment as a WordPress dev compared to a PW dev, I guess.

An interesting retrospective: I remembered we had a discussion about this topic some time ago. Turns out "some time ago" was 2017 ? https://processwire.com/talk/topic/17348-is-pw-becoming-more-popular/ It's an interesting read and shows that the same still applies 7 years later. wow. Ok so I googled a bit and found that the current website of processwire.com seems to be from 2019: https://processwire.com/blog/posts/pw-3.0.124-and-new-site/#new-website-launched And while I can remember that a lot has improved it's still not a great website at first sight, to be honest. @ryan please don't get me wrong, I know it's a lot of work and it's a great website and I know it has a lot of great stuff under the hood (like multiple instances talking to each other via API and bootstrapping, etc). Or take the blog post:

That's great, but no website visitor will ever realise that! All a first time visitor will see is an more or less default UIkit theme which looks outdated to be honest. Compare that to some agencies from the showcase section (eg https://typneun.de/) and you'll notice a difference ? Maybe one of them would be happy to sponsor a facelift for processwire.com ? At least @heldercervantes showed his interest in that in 2017.

Ok, so I explored a bit more... And compared... What do the folks at Nette do?

From the Design imho not a lot better if at all, but I love the catchy statement at the top and they instantly show some big brands that sponsor the project which instantly builds trust. I'm not a marketing or communication specialist, but this is some basics I realise. I'm quite sure we have experts that find a lot more room for improvement ? 

I'd also love to see sponsorship packages for processwire where agencies can support the project and also SHOW the support. Something like this maybe:

• Gold sponsor
  Logo on frontpage
  999$ / year
• Silver sponsor
  Name on frontpage
  499$ / year
• Bronze sponsor
  Fund 1 hour of bug-fixing
  99$ / year

Maybe github issues of gold sponsors could be addressed with priority or such. I don't know. Don't get me wrong again. I like that PW is not dependent on someone elses money, but it will definitely not hurt to add the opportunity for PW users to give something back without asking for any return (which is different to buying pro modules). I know that many buy pro modules just to support ryan, which is nice but again is not obvious and does not build trust for anybody viewing the pw.com frontpage.

Ok so I jumped back to pw.com ... For the record, here is a current screenshot:

So I clicked on "demo" - I haven't been there for some years...

Ok... Frontend...

Ufff. 2024? Doesn't look like. And again it hides all the beauty that lies under the hood.

Ok, so over to the backend demo:

A lot has been said about the pw backend already, this shows that it might be a worthwhile area to work on.

What it shows is a big orange warning about an .htaccess issue. This is probably not a good invitation for anybody new. Maybe it even draws people off. Instead it should show a huge warning like this:

What if we dropped the skyscraper profile and instead built a new modules directory which can serve as a new showcase? Keeping a profile up to date that is not used (and probably not of any use other than showcasing pw) is maybe unnecessary work if the same thing could be done with something that creates additional value.

Also I think it could be good to showcase the PW can be an absolutely great choice for modern frontend tools like TailwindCSS, AlpineJS or HTMX. I think we could really do a lot on that front just by thinking less about the product (pw is great and I think that is not going to change, whatever we do or don't do) and more about how to communicate this.

What about a section where we showcase "ProcessWire as XXX Alternative in 2024"

Many people are unhappy with existing CMSs. If I was unhappy with WordPress I'd probably google "wordpress alternative 2024". Many products do that and have comparison pages on their website where they show strengths and weaknesses of both tools and by that make it easier for people to understand what PW is, what it can do, where it is good at and where other tools might be better.

This post has again got far too long ? But one final note: I think it would be great if PW not only was a great product but also helped people using the tool make money. What do I mean by that? IMHO ProcessWire does not sell itself. It can be hard to compete with other tools that are more popular. At the moment basically anybody doing business with PW has to "sell" processwire as the correct tool on his own. Not everybody is good at marketing though, so it would be great if that was done by experts. For example we could have professional guides why pw is the right tool for job x or y on the official website. Like @dotnetic's post for example: https://dotnetic.de/blog/processwire-the-best-cms ; Edit: Note that I don't think that this is the responsibility of PW, but I try to say that PW could make it easier for us on the marketing front and everything that helps people that are using PW make money will help the project as they will have more money to spend or more resources to contribute or have more spare time to share modules with the community. The idea is to establish a strong win-win situation.

I don't know how exactly but I'd love to see processwire being a tool that, when chosen, let's the dev assured that he/she can on one hand trust the product and rely on it and on the other hand also know that there is a market for it so that he/she can make a living and that it's worth learning and exploring the system.

PS: If anybody has not yet starred the pw repo and is still reading, please do it now  ? https://github.com/processwire/processwire