Weekly update – 8 January 2021

[ryan]

Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): 

Flexible content or page building 

One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: 

First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core.

Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them.

Admin theme improvements

We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. 

Improvements to existing Fieldtypes and Inputfields

Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. 

Pull requests and feature requests

People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. 

External API

There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it.

File/media manager and more file sharing options

There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. 

External file storage

Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure.

Live preview and auto-save

There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. 

More multi-site features

There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support. 
 

[Rudy]

? for file/media manager and external file storage. Those are top two of our wish list. Thanks Ryan!

[Zeka]

@ryan Now we have custom page classes that I'm really like and I use it on all of my current projects, but maybe the same approach can be applied to custom page types? 

And one more request is the ability to deactivate the default language for page, I know that it could be implemented by custom field and some logic in hooks, but maybe such functionality could be added to InputfieldPageName. 

Thanks. 

[horst]

3 hours ago, Zeka said:

the ability to deactivate the default language for page

+1 ?

[Ivan Gretsky]

It seems like we gonna have a fascinating year! I am enjoying being here since 2014, but feels like the most interesting part is just starting!

[bernhard]

Hi @ryan

thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year.

 

• IMPORTANT: Admin Theme

As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more):

My key goals have always been easy things:

• Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray)
• Make it easy to change the Logo
• Make it easy to add custom CSS/LESS

--------

I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit:

Again: Custom color, custom logo, that's it!

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

Another one: Custom color, custom logo:

-----------

Another one changing only the main color (page tree example):

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

Learnings:

• If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules...
• My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/
  PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!!
• I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like:
  
  getNav() and getSearchform() are hookable methods that I added to my module.

 

I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files:

// file structure
foo
 |-- foo1.php
 '-- foo2.php
bar
 |-- bar1.php
 '-- bar2.php

// code
echo $uk->render("foo/foo1");
echo $uk->render("bar/bar2");

This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered:

$wire->addHookBefore("RockUikit::render(foo/foo1)", function ... );
$wire->addHookBefore("RockUikit::render(bar/bar2)", function ... );

Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless.

 

Support for a Dashboard-Page

That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example:

Or this more beautiful one:

The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary!

1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields).

2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here:

One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ".

 

############################################

• Would be great: Migrations

I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why?

• Because I want to have my fields under control of GIT
• Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock
• Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh
• Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API):
• I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php

 

############################################

• Brainstorming: ProcessWire without DB

We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be:

• WireData
• WireFileTools
• WireRandom
• WireTextTools
• WireHttp
• Sanitizer

I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/

One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this:

// copy files to root folder
include("index.php");
$wire->install([
	'user' => 'demo',
	'pw' => $wire->random->alphanumeric("8-12"),
	...
]);

Or take another example: https://processwire.com/api/ref/wire-mail/

There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something?

############################################

• Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges)

I've started a discussion here and as you can see the post got a lot of attention:

ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc...

Why? Because the only option right now is to add TWO date fields to one template and there the problems begin...

• What if you want to make sure that one date is after the other?
• What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth"
• How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great!
• What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)?
• What about timezones?
• How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days...
  
• What if you want/need to handle recurring events...?

############################################

• PageBuilder

I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix):

• Every item is a single page in the tree and has a custom template
• Every repeater item can live anywhere in the pagetree
• Every item is defined in a single PHP file (using RockMigrations to make it reusable)

This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand:

Setting up such a block is quite easy:

class Headline extends \RockMatrix\Block {

  public function info() {
    return parent::info()->setArray([
      'icon' => 'header',
      'title' => 'Überschrift',
      'description' => 'Fügt eine Überschrift auf der Seite ein.',
    ]);
  }

  public function init() {
    $this->addHookAfter("Pages::saveReady", $this, "saveReady");
  }

  // this method makes it easy to customize the item's edit-form
  // you can change labels, collapsed state, add notes or custom classes etc...
  public function buildForm($fs) {
    if($f = $fs->get('title')) {
      // dont show label for this inputfield
      $f->skipLabel = Inputfield::skipLabelMarkup;
      $f->wrapClass('rmx-pd5'); // add class to remove padding
    }
  }

  // the label of the repeater item
  public function getLabel() {
    return $this->title ?: $this->info()->title;
  }

  // migrations for this item
  public function migrate() {
    // the parent migrate creates the necessary template for this block
    parent::migrate();

    // then we set the title field optional for this template
    $this->rm()->setFieldData("title", [
      'required' => 0,
    ], $this->getTpl());
  }

  // code to use for rendering on the frontend
  public function render() {
    return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>";
  }

  // optional saveready hook
  public function saveReady(HookEvent $event) {
    $page = $event->arguments(0);
    if($page->template !== $this->getTpl()) return;

    if(!$page->id) {
      $page->title = "This is my initial headline";
    }
  }
}

As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them.

Another example: A gallery block (headline + image field):

Spoiler

class Gallery extends \RockMatrix\Block {

  const thumb = 150;
  const large = 1920;

  const prefix = "gallery_";

  const field_images = self::prefix."images";

  public function info() {
    return parent::info()->setArray([
      'icon' => 'picture-o',
      'title' => 'Bildergalerie',
      'description' => 'Alle hochgeladenen Bilder werden als Galerie angezeigt.',
    ]);
  }

  public function init() {
    $this->addHookAfter("Pages::saveReady", $this, "saveReady");
  }

  public function buildForm($fs) {
    if($f = $fs->get('title')) {
      $f->label = "Überschrift für diesen Block";
      $f->notes = "zB Galerie (ein 'L' !)";
    }

    if($f = $fs->get(self::field_images)) {
      $f->description = "Bitte die Bildrechte beachten und ggf. vermerken: [So geht's](https://i.imgur.com/uBUXjUG.png).";
    }
  }

  public function getLabel() {
    return $this->title ?: $this->info()->title;
  }

  public function migrate() {
    parent::migrate();
    $this->rm()->migrate([
      'fields' => [
        self::field_images => [
          'type' => 'image',
          'maxSize' => 3, // max 3MP resolution
          'maxFiles' => 0,
          'descriptionRows' => 1, // for copyright
          'extensions' => "JPG JPEG",
          'label' => 'Bilder',
          'icon' => 'picture-o',
        ],
      ],
      'templates' => [
        $this->getTplName() => [
          'fields' => [
            'title',
            self::field_images,
          ],
        ],
      ],
    ]);
    $this->rm()->setFieldData("title", [
      'required' => 0,
    ], $this->getTpl());
  }

  public function render() {
    $images = $this->get(self::field_images);
    if(!$images->count()) return;

    $out = '';
    if($this->title) {
      $out .= "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>";
    }
    $out .= '<div class="uk-margin-bottom uk-text-center uk-grid-small
      uk-child-width-1-2 uk-child-width-1-3@s uk-child-width-1-4@m uk-child-width-1-6@l"
      uk-lightbox="animation: fade" uk-grid>';
    $cnt = 0;
    foreach($images as $img) {
      $cnt++;
      $src = $img->size(self::thumb, self::thumb)->url;
      $href = $img->maxSize(self::large, self::large)->url;
      $alt = $img->description ?: "Bild $cnt von ".$this->title;
      $cap = $img->description;

      $out .= "<div>";
      $out .= "<a href='$href' class='uk-transition-toggle' data-caption='$cap'>"
        ."<img class='uk-transition-scale-up uk-transition-opaque' src='$src' alt='$alt'>"
        ."</a>";
      $out .= "</div>";
    }
    $out .= '</div>';
    return $out;
  }

  public function saveReady(HookEvent $event) {
    $page = $event->arguments(0);
    if($page->template !== $this->getTpl()) return;
    if(!$page->id) $page->title = "Galerie";
  }
}

 

I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020...

Access control, page status, etc etc are still challenges though, of course.

#######################

 

I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. 

 

One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? ? 

Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here ?

 

[d'Hinnisdaël]

+1 for a solid database migration mechanism. Deploying field/template updates to production involves a lot of manual copy/pasting. Having a built-in way of describing changes in database structure would make automated deployments and rollbacks possible.

[Ivan Gretsky]

18 hours ago, bernhard said:

// copy files to root folder
include("index.php");
$wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]);

A proper CLI installer is my dream)

[ryan]

Quote

Now we have custom page classes that I'm really like and I use it on all of my current projects, but maybe the same approach can be applied to custom page types? 

I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. ? Is there some other kind of page type you are talking about?

Quote

My theme uses the old admin theme repo sources, because we do not have any source files in the core

I will update the AdminThemeUikit repo. Unfortunately I've run into some npm error where it wants to do some kind of updates before it will update the UIkit version, but updates it wants to do in npm fail. This seems to happen every time I want to update something that uses npm, but I always eventually find a way around it. This last one has had me stuck for awhile though. I'll revisit it here soon. I've never liked these command line package installers/managers because they always seem to have some problem without a clear answer. I guess it's the nature of the beast.

Quote

For all others, here's an example of how my dirty core hacks look like:

In this case, you've modified the core _masthead.php. Don't do that. ? The intention is that an admin theme would provide its own _masthead.php file (or whatever you decide to name it). Actually I was thinking admin themes would replace all of the markup files. That's in part why they are all split out on their own. The updates added to AdminThemeUikit last week make it so that you no longer have to provide your own markup files if you don't want to, but for your case where you are changing method calls and include statements in those markup files, you'll no doubt want to have your own markup files. 

Quote

Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless.

This gets into more overhead than I'd want to be involved for rendering the admin theme... at least for the core default one (AdminThemeUikit). I've even tried to actively avoid the traditional type of hooks here, so that the admin theme itself doesn't add its own overhead to the request. There's nothing faster than include() of a php file to render something, so that's the strategy AdminThemeUikit takes. 

Admin themes use a different kind of hooks for adding markup in parts of an admin theme, and they actually aren't really hooks at all, even though I still think of them as being a type of hook. You can call $adminTheme->addExtraMarkup($name, $value); to add extra markup to various parts of the admin theme. Any module or admin template code can do this any time during the request, up until the admin theme gets rendered (at the end of the request). The $value is the markup you want to add, and the $name is a region name where any one of the following are currently recognized: 

• "head" - adds markup before </head>
• "masthead" - adds markup in the div#pw-mastheads
• "notices" - adds markup after the notices/notifications
• "content" - adds markup in div#pw-content-body
• "sidebar" - adds markup in #pw-sidebar, only if theme uses a sidebar
• "body" - adds markup before </body>
• "footer" - adds markup in footer#pw-footer

This is the strategy that the admin themes use to support other modules in adding markup where necessary to the admin theme output. This is faster and simpler than using a traditional hook. More region names can be added easily if/when we need more. 

If developing your own admin theme, then you don't need hooks or the addExtraMarkup() function because you can already override anything in the AdminTheme you are extending, you can provide your markup files as needed, and add your own methods as needed. Admin themes should still support markup added with addExtraMarkup() though, but it's easy, just $adminTheme->renderExtraMarkup($name); at the appropriate spots in your admin theme template files.  

Quote

Support for a Dashboard-Page

If there's anything I can add to make it easier for people to have a dashboard page, I'm happy to. But I don't currently think it should be built into the core. The core doesn't have anything worthwhile to communicate to admin users in a dashboard, so it would just be extraneous fluff (i.e. "numbers", "more numbers", and "numbers again"), like it seems to be in most systems. The kind of stuff that makes a simple system look complicated. Others may have something specific they want to communicate to their logged in users, and that's where I think it becomes worthwhile. If there's demand for it, I'd be more interested in hearing not about a dashboard, but about what one is wanting to communicate with it. 

Quote

I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module.   

Thank you for continuing to develop this. I agree there are benefits. This may be something we should keep talking about for the longer term. 

Quote

Examples of such classes that might be useful even without a DB connection could be:

With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection).

Quote

There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! 

A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). 

Quote

ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc...

The core datetime field is meant to store a single date/time, but that's it. I agree that sometimes a need arises for more than a single date/time. ProcessWire core is meant to focus on the basics, while supporting modules to accommodate a broader set of needs when they occur. I think this is a good example of a need that is nicely accommodated by a module that you've developed. 

Quote

PageBuilder

Thanks for sharing the strategy you are using here. It's great to see the different solutions people are working with these last couple of weeks. From the screenshots I really like the approach you are using here. It looks powerful while easy to understand and client friendly. Yet also looks very PW familiar as well. Visually it might be the clearest I've seen, even relative to something like The Bard. 

The means of definition does also look simple, though I think for something that other developers would use, they might prefer that the front-end rendering be isolated from the back-end component. Something that makes it easier for you to provide pre-written components, while they provide the front-end markup. For instance, maybe the render() method delegates to a front-end template file somewhere in a subdirectory off /site/templates/fields/? And if there is not file, then maybe it provides a default output. 

Quote

Access control, page status, etc etc are still challenges though, of course.

The reason repeaters store their pages off in the admin structure is to solve these things. But it does come with its own challenges as well.

Quote

One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you

Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands.

Quote

A proper CLI installer is my dream)

Seems like it might be simple to do. Can you expand on this? When/where would you use it?

[horst]

2 hours ago, ryan said:

If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years.

? ? ? ???? ?? ????????? ?‍♂️?‍♂️??‍♂️?‍♂️?‍♂️?‍♂️ 

 

[Krlos]

5 hours ago, ryan said:

Most likely I'll be here for at least another 46 years.

I'm so glad to read this. ?

[Ivan Gretsky]

15 hours ago, ryan said:

Seems like it might be simple to do. Can you expand on this? When/where would you use it?

I need a cli installer for setting up new ProcessWire sites with all the little tweaks I am doing every time quick and easy. For now I maintain my own ProcessWire profile, and use it during the installation process. But maintaining and especially source controlling a profile is hard. I would like to have a script to set up a new installation doing all my tweaks. The script should:

1. Install PW with a Blank Profile.
2. Install RockMigrations.
3. Downloads a migration (a setup script) from git hosting platform and run it.

To develop all this and particularly to test it I really need an automated way to install PW, getting all install options from cli arguments and/or from a config file. I guess the cli installation will be great for any testing tasks and CI.

[bernhard]

Exactly what I'm working on, so I'm happy to share my knowledge (code) if there is interest!

It seems that interest is there since 2015... https://processwire.com/talk/topic/9494-wire shell-an-extendable-processwire-command-line-interface/

Installation and usage are simple:

Installation

cd /to/your/project/root/folder
# clone rockshell into the "rock" folder
git clone git@github.com:baumrock/RockShell.git rock
cd rock
composer install
cd ../

Usage

# in your projects root folder
# this will list all available commands
php rock/shell

----

RockShell will then live in a separate folder "rock" beside "site" and "wire", so everything stays clean. Also it can run without processwire, which is necessary for installation (of course) but might also be helpful in case of anything pw related does not work (500 error due to wrong config or the like). That's why I'd be very interested in using WireFileTools etc. without a running pw instance. I'd be happy to get some hints how that can be done...

[markus_blue_tomato]

26 minutes ago, bernhard said:

Exactly what I'm working on, so I'm happy to share my knowledge (code) if there is interest!

[Kiwi Chris]

17 hours ago, ryan said:

Quote

One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you

Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands.

Never say never. When I was 25, I was fit an healthy, and then got meningitis which nearly killed me. When I was 42, I was also apparently fit and healthy, and then ended up with a twisted bowel which also nearly killed me. I've recently been asked a similar question by some of my clients, "What happens if something happens to you?"

I think perhaps a peace of mind option with the pro modules might be to include some sort of clause that allows rights to modify them to provide bug fixes etc, and also explicitly have some sort of clause around what happens if the developer (you) ceases to support them.

I've often thought about software licensing and what should happen if the original author is no longer able to support their code, but there's still a need to use it. I know that people need to earn a living, and relying on donations usually won't be sufficient, so licensing software is a fair way to get paid, however it would be useful to have some sort of commercial license that both respects a copyright holders right to earn an income, but also provides peace of mind to licensees in the event of the software being abandoned by the original creator. I understand in normal circumstances, copyright extends past an author's death, but I know that my wife or daughter would not be able to support any code I might write, although they might need revenues generated by it if it's still useful without modification, so the licensing thing is complex.

[AndZyk]

I also wish you all a happy new year. ?

I know that I am late to the party, and most of my wishes are already mentioned I think, but for the "Flexible content or page building" you could look at your competitor. ?

Regards, Andreas

[ryan]

@bernhard That looks awesome! 

@Kiwi Chris I'm sorry to hear about what you've had to go through there, and I'm glad that you made it through all that and are doing well. 

I didn't say never. We're all doomed. Every day is a gift. But if people are going to ask me to entertain doom and death, then after I do that, I think it's also honest and appropriate to state there's no known present danger, odds are good that it'll remain that way for the life of ProcessWire, and the reasons why. If I were battling some condition that changed the odds then I would also want to state that.

@AndZyk Kirby is a commercial product so not really a direct competitor. In our case, we are talking about what can be built without a company paying for it, and without any budget for that matter. So while I think it's good to look at, I also would say to everyone that we have to be careful about setting core builder expectations from other projects, especially commercial and highly funded ones. 

[Ivan Gretsky]

7 minutes ago, ryan said:

In our case, we are talking about what can be built without a company paying for it, and without any budget for that matter.

@ryan is it possible that the community funds the development of the content builder? Can you think of a number we can set and try to collect? We can at least try this model)

[AndZyk]

3 minutes ago, ryan said:

Kirby is a commercial product so not really a direct competitor. In our case, we are talking about what can be built without a company paying for it, and without any budget for that matter. So while I think it's good to look at, I also would say to everyone that we have to be careful about setting core builder expectations from other projects, especially commercial and highly funded ones. 

Sorry, if I wasn't clear enough in my suggestion: I was just referring to the new Blocks and especially the Layout feature in Kirby 3.5 (linked in my previous post), which looks awesome, although I haven't tried it yet. But I could imagine something similar in ProcessWire and think that should be possible. If the Layout feature would be a pro module, I would be glad to pay for it. It was only my intention to give a pointer what a similar product is offering. ?

[ryan]

@Ivan Gretsky Thanks for the suggestion, I actually don't have any idea about what it takes just yet. I was thinking we'd see what we can do without a budget and if demand is there for something more (but it's not possible without funding), then we'd cross that bridge when we come to it. Whether community funded or Pro module route or another, we can talk more when/if it seems needed. Part of our plan involves more support in RepeaterMatrix for this sort of thing, so that at least is already community funded. But for the core side of things where we are looking at an editor.js type strategy, I don't know how much resources it'll take to build, but I'm hoping it'll be manageable without needing to seek funding, since we're looking to integrate with an existing tool. 

@AndZyk Thanks, I know your intention wasn't set the standard from that. My reply was just something I meant to mention earlier to everyone, so this seemed like a good place to do so. But of course I think it's a good idea to look at everything out there, both free and commercial, this can only help. I'm going to explore what Kirby is doing in more detail too. But I also have to be realistic that our resources are limited relative to commercial projects, or commercial backed projects like WordPress. So we won't be able to build a direct Gutenberg competitor (not that I think anyone wants us to), but I do think we'll be able to build something great. 

[bernhard]

I'd suggest to continue discussion about the content-builder over in the older thread:

I totally missed all the posts there and I think some over there might have missed my statements here ? 

[Zeka]

23 hours ago, ryan said:

I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. ? Is there some other kind of page type you are talking about?

@ryan 

Sorry for being not clear enough. I was talking about the ability to specify custom Page classes and especially the ease of use when you only have to change some lines in the config and all classes and files have their place and get autoloaded. I was thinking that it would be great to expand such behaviour to classes that extend the PagesType class. 

Take a look at this tutorial 
https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/
While it still actual, there is an easier way to deal with custom Page classes. That what I meant. 

Thanks

[Pete]

Flexible content or page building 

I've mostly used RepeaterMatrix for this. I think looking at some of the examples above, something in the core would be welcome and something with maybe a simpler interface too. Thing is, in my case, I still probably need the flexibility of what I can do with RepeaterMatrix but just making it even simpler for site owners once I hand things over is welcome. I'll have a think about it.

Admin theme improvements

99% of the time all I really need personally is to maybe change the colours. It sounds silly, but anything that shows clients you're paying attention to detail is good - which is why I love that you can link their logo into the masthead and they like that, but colour scheme is the obvious addition if it's something we can just set with a colour picker or by entering a hex colour value or something in the admin theme settings.

Improvements to existing Fieldtypes and Inputfields

Decimal is something I really need for any site with pricing, or if trying to build any basic ecommerce functionality so +1 for that as I don't think it's something that adds significantly to the core hopefully. Seems small enough anyway.

External API

I have had more requests in recent years as a developer along the lines of "do you do mobile apps" and for all projects I want to use PW as a backend, so if there was a JS API I guess that would help (don't really know) but I also feel like some of the REST API activity I saw a few months back by someone (sorry, don't remember much!) would help with that.

File/media manager and more file sharing options

I think it's great to keep the current ability to upload images/files where they're needed in a page (and I know you wouldn't remove that) but if we could use tagging to help categorise images/files and that helps build the file/media manager feature that would make sense. I still think the point of initial upload would more often than not be when you need to upload the file for a specific page, but on a few larger sites I've found myself uploading the same header image to a few different pages because it was appropriate although they weren't in the same tree, and it would have been easier to re-use with a file/media that's tied to the file/images field, so in those fields if we had "Upload" or  "Choose from gallery" as options - giving the ability to set a different description, tags and cropping for a single image depending on where we need to use it, and then the file/media manager is in charge of making sure when we delete one instance it remains in the other image field.

Does that make sense? It comes up for me more often on larger sites, but also giving folks one place to look to see what images are already available can prevent repeat uploads of the same image. Sure it doesn't add much overhead, but it's still overhead.

Not sure I've got the right solution there but something that doesn't require breaking out of the normal workflow is more intuitive in my mind. I think my point is that you don't always want to re-use the same image in a CKEDitor field, you might want to have it in a single/multi image field on more than one page and that's currently not possible to my knowledge.

EDIT: I know you could maybe use tags to achieve this, or a field that selects files somehow like ASMSeect, but there are occasions where you want to re-use and re-order and re-uploading seems to be the only way. Maybe my use case is so unique though that it's too much to bother with the more I think about it. Seems pretty unique anyway.

[bernhard]

100% agreed ? 

Just thinking out loud...

If we were building a website with a blog. And every blog post had fields "title, coverpic, body". And if the "coverpic" field was set to that all uploaded coverpics lived in /site/assets/files/coverpic. And if we then created some new blog posts...

First, we'd create PostA and upload coverpic "foo.jpg". That would live in /site/assets/files/coverpic/foo.jpg; Then, one week later, we'd create PostB and wanted to use the same image (because it was some stock image that is used for every blog post that showcases any event)... We could have the option to upload a new image or choose an existing one from /site/assets/files/coverpic which would mean that no additional storage would be used, because it was just a reference to /coverpic/foo.jpg

If PostB was deleted, the image would need to stay available as long as no other field references the image (here PostA).

Or maybe even better, if the storage path would be totally free to choose, eg /site/assets/files/blog/[...].jpg ?!

---

For some of my clients that would for sure be great. They do now have a shared folder (dropbox), where they save images that they need on a regular basis for their website and then upload those files again if they need it. OK, but not the best solution.

My described solution would change quite a lot in terms of PageImages I guess, so maybe as a quick win it would be better to just extend the file/image field with a file chooser, so that one can browse existing files of the same field (or of a definable set of sources) and when clicked, the image got uploaded/copied to the current page destination (eg /site/assets/files/1234/foo.jpg) meaning there'd be an additional copy (little overhead) but using existing concepts and having no complex changes behind the scenes ? 

[szabesz]

2 hours ago, bernhard said:

and when clicked, the image got uploaded to the current page destination

I guess you meant "copied over to" instead of "uploaded to", correct? Anyway, I like this idea. If there was a central and configurable image browser (the image sources could be defined by the developer), so that admin users can re-use images by copying over images of a page to another page than that would help. Such a feature has its cons of duplicating the image, but on the positive side there would be no need to manage dependencies.