Leaderboard

Just a heads up regarding a possible fix posted in the GitHub issue: https://github.com/processwire/processwire-issues/issues/411#issuecomment-340139239

Major revamp to Dumps / Dumps Recorder panels This has bugged me for a while - the Tracy core dumps panel is: ugly and with a forced label whether you want labels for it or not doesn't show a count of dumps next to the icon doesn't show dumps from consecutive ajax calls - each call overwrites the previous dump That is why I built the original Dumps Recorder panel, but it also had a problem: the redirect and ajax Dumps Recorder panels contained all previous dumps (those from the main page request, etc) which made it hard to see what was from what So now I have overridden the core Dumps panel with a new version that has: an optional label a count of dumps adds consecutive ajax calls so you don't miss any. I have rebuilt the Dumps Recorder panel as well. You probably won't want this most of the time, so it is no longer enabled by default on new Tracy installs, so if you are upgrading, I recommend disabling the Dumps Recorder panel by default and just enabling via the Panel Selector as needed. It no longer has a "Preserve Dumps" option, because that is now it's only purpose, so when it is enabled, it will preserve all dumps across all page / ajax requests and reloads. You can click "Clear Dumps" whenever you want, and of course disabling it will also clear the recorded dumps. I think this is a major improvement - it keeps things simple when that's all you need, but enables recording when you want to keep track of changes over multiple requests or you simply find that your bd() calls are somehow being lost / not shown - sometimes I see this when debugging modules - the dumps will be stored, but not shown - the dumps recorder will record these and show on the next page reload. Hope all that makes sense - please try it out and let me know if you find anything that you think can be improved. One other thing - I have moved the $_SESSION section from the Debug mode panel to the Request Info panel - I think that's a more appropriate location - inline with having the INPUT (post, get, and cookies) in there. On Tracy upgrades, you'll need to enable SESSION in the config settings for the Request Info panel.

ProcessWire 3.0.81 makes major improvements to the Role editor, simplifying the setup of access control in ProcessWire: https://processwire.com/blog/posts/processwire-3.0.81-upgrades-the-role-editor/

In response to a wishlist request... Field Save + Add New Adds a "Save + Add New" button when editing a field. Usage Install the Field Save + Add New module. When editing a field, click "Save + Add New" if you want to save the current field and start the process of adding a new field. Note: The button will not redirect you to "Add New" if you are performing some special action such as duplicating a field or adding a field to a template. https://github.com/Toutouwai/FieldSaveAdd/

Since i typically maintain separate pages for those types of media (in a media library for every site), it is just a matter of setting up page select field. I use selectize so that the user can see what they are selecting. Also if i use a page for logo, then they can update the logo from the media library without having to change the setting; or they can add several logos to the media library and then select which one to use on the settings page. I don't yet know how to support image/file fields natively in this module, although since the settings pages themselves are pages of template admin, it might be possible. I was actually able to use both image and file fields and upload an image, however there are still errors with the value of the inputfield not yet working... In other news, here are some new screenshots of settings panels using UiKit theme, including a working example of using WireTabs:

Thanks and keep bugging us with such updates

there is no dashboard for PW. If you login though, you would see the page tree, that's the admin landing page. I would never permit a client access to changing the site's global base font. As mentioned in posts above this could have not only detrimental effects to the layout of all content elements, but would also be virtually impossible considering that many parts of the base css file (global style for example) may have rules that refer to that loaded web font. If this ability for base font to be selectable in admin was a requirement of the project, then i would neutralize all of the font rules in the css, and place 1 style tag in the header, which would be selected using some settings page (settings factory or custom helper module), this selection would also have the effect of loading the correct webfont (i use webfonts.js for font loading)... so to sum up, yes it is definitely possible to grant control of the global base font for a site to a settings page with the right modules, and code in the header, but whether it would really work is questionable; You also might need to account for 2 fonts, since most sites use 2-3 complementary webfonts each optimized for either headings or body text..

I may be wrong but the problem is most likely due to this line. With single quotes, $evName is interpreted literally, so you get errors trying to create the same page again, and don't notice it because you probably have the debug mode off as @Robin S pointed out. Also, <?php namespace ProcessWire; foreach ($events as $event) { // you don't have to manually clean up strings to create page names, just use $sanitizer $evName = $sanitizer->pageName($event['name']); $p = $pages->get("/events/$evName/"); if (!$p->id) { $p = new Page(); $p->template = 'basic-page'; $p->parent = '/events/'; // $p->name = '$evName'; // single quotes -> interpreted as literal string $p->name = $evName; } $p->of(false); $p->title = $event['name']; $p->save(); } ?>

I found a way to solve my problem, the Post helped me too: The code looks the following and works with the TemplateEngineModule. If you want my solution to work without the TemplateEngineModule, remove the line $view->setFilename('person');. Template person_listing Settings in Backend: The allowed Page URL Segments: regex:^[0-9a-zA-Z\-\_]+$ Template person_listing.php Code: if ($input->urlSegment1) { $pagename = $input->urlSegment1; $match = $pages->get('name='.$pagename); if (!$match->id) throw new Wire404Exception(); $view->setFilename('person'); // Remove this line if you don't use TemplateEngineModule! echo $match->render(); return $this->halt(); } Hope this helps someone else.

So I ended up with the slightly modificated code of abdus which works like a charme: wire()->addHookAfter('ProcessPageAdd::buildForm', function (HookEvent $e) { /** @var InputfieldForm $form */ $form = $e->return; $form->add([ 'type' => 'markup', 'value' => '<script> $("#template").prepend("<option value=0 selected>Please select</option>"); </script>' ]); $template = $form->getChildByName('template'); $template->attr('required', 1); }); Before pressing the save button: After pressing the save button an nothing was choosen:

@wbmnfktr This was the structure that I had before and it works but I want to get rid of it, because the category pages were always displayed in my breadcrumbs. So I had to manipulate the breadcrumbs output before render.

Ok, so if I understand it right, you want to force user to pick a template. I'm not sure if this fits your needs but with a bit of JS and hooks you can remove default value and set the template select required (with `required` html attribute), such that you cant get to the next step without deliberately picking a template wire()->addHookAfter('ProcessPageAdd::buildForm', function (HookEvent $e) { /** @var InputfieldForm $form */ $form = $e->return; $form->add([ 'type' => 'markup', 'value' => '<script>document.querySelector("[name=template]").selectedIndex = -1;</script>' ]); $template = $form->getChildByName('template'); if ($template) $template->attr('required', 1); });

Pretty sure that's just a typo, and should read "This does the same as above". You can do anything with Markup Regions that you can do with the typical delayed output approach. Each markup region serves the same purpose as some variable that you would put markup in and output in _main.php, like $sidebar or whatever. There are a few ways. Here is one... _main.php (just showing the main content part - of course there will be <head>, footer, etc in this file too) <region id="main-content"> <region id="top"> <div class="full-width-coloured-bg"> <div class="container-1400px"> <div>SOME STUFF IN A CONTAINER</div> </div> </div> </region> <div class="container-1400px"> <div class="row"> <div class="col-10"> LEFT SIDE </div> <div class="col-2"> SIDEBAR </div> </div> </div> </region> basic-page.php This file can be empty because _main.php is based on the markup needs of basic-page. But until this bug is fixed you might want to include some dummy region in basic-page.php or else the Markup Regions parser won't be triggered and <region> tags in _main.php will not be removed. home.php <region id="main-content"> <div class="container-1400px"> <div>SOME STUFF IN A CONTAINER</div> </div> </region> services-page.php <region id="top"> <div class="full-width-coloured-bg"> <div class="container-1400px"> FULL WIDTH STUFF </div> </div> <div class="container-1400px"> <div>SOME STUFF IN A CONTAINER</div> </div> </region>

I whipped up a module for this:

Ok, I have committed a new version which fixes the two bugs that @jmartsch reported. As mentioned above, I have also revamped the password generator - it now populates the password fields while you are creating the user and the generated password matches the options defined in the PW "pass" field's config settings. The only one I can't match is the complexity factor, but so long as you stick to the default (or lower) it should all be fine - thanks to @Robin S's Password Generator (https://processwire.com/talk/topic/17406-password-generator/) for some inspiration Please let me know if you notice any problems with this new version.

Hi @AVD, usually changing font on the fly is not the best choice you could made on the front end, mainly because every font has a different way to handle kerning, line-height, weight, etc. This may cause issues in the whole design of the site, since it may be (or maybe not) possible that some elements on your page breaks the whole layout. Moreover I think that Wordpress themes (like Avada) offers way too many options that, even if fascinating at first, may lead to uncontrollable results on the front end, resulting in a mess (especially regarding the communication aspect of your - or your client - brand) if not handle properly. That said it's not hard to build some sort of switch on the Processwire backend to change fonts on the various pages, but I'd suggest to evalutate this option twice, if not mandatory for what you are achieve

Released: https://modules.processwire.com/modules/process-documentation/ https://github.com/outflux3/ProcessDocumentation This is a new module that will be released soon - the purpose is to allow you to create help pages in the admin. This differs from the Admin Help module in the approach, and will be kept totally separate. The Admin Help modules provides the ability to make a help tab on any page edit screen (and optionally make that pop up in a lightbox), as well as a single process page showing all of the help pages in a single accordion. This module's workflow is different - first you can create your help pages any way you want using any template and any field for the body text. You can create unlimited admin help pages, using ProcessDocumentation, select the page to display, and then users can click on that in your menu to access the help page. You can create a folder structure by creating a top level menu item using ProcessList, and then various help pages under that parent using ProcessDocumentation. The module comes with 2 internally used textformatters, one of them adds classes needed to the markup for some elements to allow styling within the content and not conflict with admin theme rules (e.g. ol, ul, blockquote, table etc.). The other textformatter allows you to implement jQueryUI tabs within your help page, using a simple shortcode/token format. The styling for the jQueryTabs widget matches that of the standard processwire admin theme tabs, so that users will feel familiar with the interface. Instructions: 1) Install the ProcessDocumentation module. It will also install the 2 textformatters. You don't need to apply those textformatters to any field, they are just used internally by the module and called in the correct order to make them work. 2) Select the field to use for the content display (e.g. body). 3) Create your content. If you want to use tabs, this is the syntax: {tab=My First Tab} Some content {tab=My 2nd Tab} Some more content {/tabs} Make sure to close the tabs or the page will break... you need 2 or more tabs for it to work. You can only currently have 1 set of tabs per page. You should be able to safely use lists and tables. 4) Create the process page under the admin. Select ProcessDocumentation as the process and then select the page to show from the tree. 5) Now you should have the menu item in your menu if you are using Reno it will be on the left, and under a parent if you setup a parent in the tree. Clicking on that will render the help page. This example uses 7 tabs. If you are superuser, you will see the edit process settings. Other users will see the edit content only, which allows them to edit the content of the help doc, make corrections or additions. If you need to prevent access to any documentation pages by any role, you just add the name of the process page to the permissions and then don't check it for that role. The module has a defined permissionMethod that checks to see if that permission is defined, and then if the user has it. Not defining individual help page permissions means they are visible to anyone with the documentation permission. There is more work to be done on CSS, and other small details.

Hey! When I was building a little commercial Processwire website for a family member, I started looking into caching with WireCache and somehow had troubles to find a satisfying solution to organize the caches and their expirations. My site had a few parts that updated in a regular manner while other parts should be refreshed whenever the current page - or e.g. for the menu: any page - was saved. I wanted to create a cache of the whole page's html which should expire whenever any of its parts expired. This would be simple if you could set multiple expire values for one cache. Unfortunately, you can only set one. So I started to build a solution to my problem which uses the WireCache and creates a dependency tree for every cache. And since I haven't yet implemented a Processwire module and this little class might be useful for other websites, too, I thought I'd try to make a module out of it. This is it. Github: https://github.com/janKir/CacheNesting Please have a look, and feel free to leave a comment. This is my first module, so any suggestions are welcome. I am not even sure if my approach makes much sense for performance reasons. I'm happy to hear your opinions! Thanks a lot!

I'm not sure if your editor highlights variables inside strings, but PhpStorm, for instance, makes it really easy to spot the difference. Check your editor/highlighting settings, there might be an option to enable it. And yeah, tunnel vision is definitely real.

Perhaps some exception or PHP error is occurring. Do you have debug mode on or (even better) Tracy Debugger installed to make sure you see error messages?

Let's do a comparison of how you would do this with the typical delayed output approach vs Markup Regions. When it comes to the Markup Regions example I'll do it a little differently than you've proposed it, with a dedicated <region> for scripts instead of appending to <head>. Delayed output _init.php $scripts = ''; _main.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> <?= scripts ?> </head> //... template-which-needs-js.php if(strpos($page->name, 'special') === 0) { $scripts .= "<script src='{$config->urls->templates}assets/js/my-script_2.js'</script>"; } else { $scripts .= "<script src='{$config->urls->templates}assets/js/my-script_1.js'</script>"; } Markup Regions _init.php Nothing needed here because one of the nice things about Markup Regions is that you don't need to initialise a markup variable. _main.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> <region id="scripts"></region> </head> //... template-which-needs-js.php <region id="scripts" pw-append> <?php if(strpos($page->name, 'special') === 0): ?> <script src="<?= $config->urls->templates ?>assets/js/my-script_2.js"></script> <?php else: ?> <script src="<?= $config->urls->templates ?>assets/js/my-script_1.js"></script> <?php endif; ?> </region> So comparing a markup region to a variable: Use pw-append where you would have used $some_var .= 'something' Use pw-prepend where you would have used $some_var = 'something' . $some_var Use neither pw-append nor pw-prepend where you would have used $some_var = 'something' But Markup Regions are even more powerful because you can have multiple nested markup regions in _main.php, which is something you cannot do with variables.

As said before, I don't know Twig that much, but with PHP it's not that much uglier. PHP is a template language in itself, imho. Here's the equivalent (well, it should work ;-): <?php foreach ($page->exhibition_artist as $artist): ?> <?=$artist->title;?> <!-- Show works that are related to current exhibition and belong to a given artist --> <?php foreach ($pages->find("template=work, work_exhibition=$page->path, work_artist=$artist") as $work): ?> <?=$work->title;?> <?php endforeach;?> <?php endforeach;?>

Thanks bernhard and 3fingers for weighing in on this topic. Having access to font selections was just an example of a feature I'm used to seeing in a CMS dashboard. Any future font change I'd make would be only to the site's base-font, not applying multiple fonts to individual pages. I was excluded from collaborating on the font choice for my website and I thought if I found something better down the road I could simply change it out. Looks like I can, but need to code it myself. I have the technology, it's just not what I signed up for. I can see, however, Processwire is an ideal platform for designers & developers, and the merit of limiting editing features to optimize load time and reduce front-end conflicts. I probably won't know what I want to modify (if anything) until I'm ready to update my site with new pages, content and images. So it's not feasible at this point to ask my developer to add features that I don't know that'll I need. Do you know if it's possible to change the template's core code to add features to the dashboard at a later date? Also, are any screenshots or demos available of PW's dashboard?

Welcome to ProcessWire. Maybe, that the settings for fonts is not defined in a template file, but in a css, less or scss file. (Regarding to how your agency organized your site)

I'm going too. Probably not the whole thing, I'm still looking at the program. I'm following you on twitter so we can contact at the time.

Thank you so much Robin!

Another idea... Create a new parent for each kind of event type. Set corresponding template restrictions in the template settings (family tab) and the users were forced to choose what kind of event they want to create.

Here is another one: If I create a user via the API and use $new_user->sendEmail = true; an email is not being sent. Here is the code that I execute via Tracy console: $new_user = new User(); $new_user->of(false); $new_user->addRole("editor"); $new_user->email = "aceman3000@gmail.com"; $new_user->name ="aceman3000-gmail.com"; $new_user->sendEmail = true; $new_user->save();

Another bug: If you choose to re-send the welcome message, a new password is not generated.

Hey @adrian. I installed the new version from Github. There is a small bug that I found: If I create a user and don't send him a welcome message, then the next time I edit this user (maybe I want to add some details to custom fields) the label of the email function reads "Re-send welcome message" although I did not send an email yet. Feature request: If "Generate password" is checked, and the "PasswordForceChange" module is installed, the checkbox "Force password change on next login" should be checked, because it is not save, to send passwords via email. But maybe that is just my opinion. What do you think of that?

In order to complete the testing scenario I added a form to my login page now as well - embed method A, B, and C with FormBuilder form above and below login form. Login still works fine without any errors.

I also have a gitlab account because I want to learn more about it and they way development should go (as in a real company). I basicly work alone so it might be a little overkill. However as a beginning developer I want to learn to work with repositories. Do you push all code (pw and template files)? Or just the template files? Or do you push docker containers? Do you push from Gitlab to a production server? I currently just use it as backup of the template (not the DB). With gitlab I can add client as Reporter, making it a bit of a helpdesk. They can report bugs or changes and I can pick them up. I can also post the manual there. Those are nice features. I would love to hear more of workflows that would work well with processwire.

Managed to get Login/Register working on a clean install with no FormBuilder with a few minor tweaks to the code: Firstly, to be on the safe side, I changed $page->url to $page->httpUrl. Secondly, on occasion my frontend page named 'login' got confused with the admin page named 'login' so specified exactly where to redirect. if(!$user->isLoggedin() && $page->id!=1193) { // not for login page $session->set('returnPage', $page->httpUrl); $session->redirect($pages->get(1193)->url); } Still having issues with SessionCSRF with LoginRegister + FormBuilder. Will post in the FB forum. Thanks

I agree with @abdus that field rendering is the solution. But if you're just wanting a tidier way of doing what you are already doing then you can rewrite it as: <?php foreach($foos as $foo): ?> <div class="foo"> <h1 class="foo__title"> <a href="<?= $foo->url ?>"><?= $foo->title ?></a> </h1> <?php if($page->headline): ?> <h2 class="page__headline"><?= $page->headline ?></h2> <?php endif; ?> </div> <?php endforeach; ?>

Check out field rendering https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/#field-rendering-with-template-files

@SamC, I don't entirely follow what you are saying, but here are a few things that might help. 1. You can remove elements in _main.php by using "pw-remove" in a template file. _main.php <div id="main"> FULL WIDTH OR SIDEBAR IN HERE </div> <div id="sidebar"> THE SIDEBAR </div> basic-page.php <!-- Remove #sidebar --> <div id="sidebar" pw-remove></div> 2. You can have as many nested ID'd or region elements in _main.php as you like, and then modify/replace any of them from your template. _main.php <region id="main"> <div class="container"> <div id="main"> FULL WIDTH OR SIDEBAR IN HERE </div> <div id="sidebar"> THE SIDEBAR </div> </div> </region> home.php <div id="sidebar"> <p>Just customise the sidebar.</p> </div> basic-page.php <region id="main"> <div class="container"> <p>Use a completely different #main on this template.</p> </div> </region> 3. The three blog posts about Markup Regions can be a bit confusing because the spec changed as the feature was developed and none of the posts cover the entire set of available keywords and syntax. Check out the comments in WireMarkupRegions.php for a more comprehensive spec. /** * Identify and populate markup regions in given HTML * * To use this, you must set `$config->useMarkupRegions = true;` in your /site/config.php file. * In the future it may be enabled by default for any templates with text/html content-type. * * This takes anything output before the opening `<!DOCTYPE` and connects it to the right places * within the `<html>` that comes after it. For instance, if there's a `<div id='content'>` in the * document, then a #content element output prior to the doctype will replace it during page render. * This enables one to use delayed output as if it’s direct output. It also makes every HTML element * in the output with an “id” attribute a region that can be populated from any template file. It’s * a good pairing with a `$config->appendTemplateFile` that contains the main markup and region * definitions, though can be used with or without it. * * Beyond replacement of elements, append, prepend, insert before, insert after, and remove are also * supported via “pw-” prefix attributes that you can add. The attributes do not appear in the final output * markup. When performing replacements or modifications to elements, PW will merge the attributes * so that attributes present in the final output are present, plus any that were added by the markup * regions. See the examples for more details. * * Examples * ======== * Below are some examples. Note that “main” is used as an example “id” attribute of an element that * appears in the main document markup, and the examples below focus on manipulating it. The examples * assume there is a `<div id=main>` in the _main.php file (appendTemplateFile), and the lines in the * examples would be output from a template file, which manipulates what would ultimately be output * when the page is rendered. * * In the examples, a “pw-id” or “data-pw-id” attribute may be used instead of an “id” attribute, when * or if preferred. In addition, any “pw-” attribute may be specified as a “data-pw-” attribute if you * prefer it. * ~~~~~~ * Replacing and removing elements * * <div id='main'>This replaces the #main div and merges any attributes</div> * <div pw-replace='main'>This does the same as above</div> * <div id='main' pw-replace>This does the same as above</div> * <div pw-remove='main'>This removes the #main div</div> * <div id='main' pw-remove>This removes the #main div (same as above)</div> * * Prepending and appending elements * * <div id='main' class='pw-prepend'><p>This prepends #main with this p tag</p></div> * <p pw-prepend='main'>This does the same as above</p> * <div id='main' pw-append><p>This appends #main with this p tag</p></div> * <p pw-append='main'>Removes the #main div</p> * * Modifying attributes on an existing element * * <div id='main' class='bar' pw-prepend><p>This prepends #main and adds "bar" class to main</p></div> * <div id='main' class='foo' pw-append><p>This appends #main and adds a "foo" class to #main</p></div> * <div id='main' title='hello' pw-append>Appends #main with this text + adds title attribute to #main</div> * <div id='main' class='-baz' pw-append>Appends #main with this text + removes class “baz” from #main</div> * * Inserting new elements * * <h2 pw-before='main'>This adds an h2 headline with this text before #main</h2> * <footer pw-after='main'><p>This adds a footer element with this text after #main</p></footer> * <div pw-append='main' class='foo'>This appends a div.foo to #main with this text</div> * <div pw-prepend='main' class='bar'>This prepends a div.bar to #main with this text</div> * * ~~~~~~

Hey @adrian. Thanks for your quick reply No they did not show even when the option was checked. Switching the init function to a ready function fixes the problem. I also thought of doing this, but didn't do it. Now it is working fine I use the latest version from github = 1.0.5 and if I open the file in a texteditor or in my IDE then line 54 is the correct line. EDIT: Weird, on github it is line 55. Must be something in my editors. Regarding the output of line 72 (that was something that I added): bd($event->object->attributes["class"]); There is a problem with removing the required attribute from password fields. It gets removed, but if you accidentally enter something in the password field and then delete it, you can not submit the form, because the required attribute gets added back in. This is coming from the InputfieldPassword.js which gets added to the page. Starting in line 120 it reads $input.on('change', function() { var val = $(this).val(); if(val.length > 0) { $input.attr('required', 'required'); $confirm.attr('required', 'required'); } else if(!$(this).closest('.InputfieldStateRequired').length) { $input.removeAttr('required'); $confirm.removeAttr('required'); } }); So if the "Generate Password" Option is set, the script should not be executed or loaded. One approach would be, to remove the CSS class "InputfieldPasswordComplexify" so the script does not react to it. I tried to make a hook for this, but it does not work yet. Maybe you have some suggestions? Here is my hook in the ready function: $this->addHookBefore('InputfieldPassword::render', $this, 'removeComplexify'); and here the function protected function removeComplexify(HookEvent $event) { $f = $event->object; bd($f); $f->removeClass('InputfieldPasswordComplexify'); } I don't know what is wrong or if this is the right approach. I even tried to use addHookAfter, which also did not work. Maybe you have an idea?!

hi avd and also welcome from my side, nice to hear that you get a pw site. maybe you can share your experience of pw after your first steps with us? would be interesting to hear! in processwire you can make almost everything editable. you CAN. but it's all up to the developer. and in my opinion thats a good thing. so the question is always WHY do you want to make this or that editable. if you have a valid reason one can just create a field for that and build that functionality into your site. but for other things that will not (or should not) change often it's better to change the code directly (and fonts seem to be a good example for that). hope you enjoy pw and your agency does a good job

Thanks clsource. I've actually been able to spec fonts within WordPress theme, but perhaps it is a feature included with only some (i.e.: Avada). Good to know I can edit Processwire's template files.

Hello and welcome to the forums. You arrived at the right place we are a friendly community happy to help newcomers. About your question: Yes, but as the agency said. It should be configured to do so. Wordpress does not have this functionality either. every wordpress theme comes with their own settings and options. So the agency programmed your site but it didn't program Processwire to include such settings. Maybe wasn't in the original specs. As you mention that you know html and css it seems that you have all the required knowledge to integrate this feature in your site. Just go to the templates folder and take a look for the files. You will encounter many files with html in them. One of them will have the <head></head> tags and you could change the fonts easily

Here's a screenie of the front end:

I'm in the process of learning vue, webpack, etc, and thought this might be a good thing to work on. So I'm building a new generator. At the moment, I'm simply replicating the functionality that already exists, and I have an operational front-end working. As I dive into the back-end, I'll work on the changes mentioned above. Quick question: Currently, selecting Process as the type of module enforces it to extend Process. Should I provide the ability to extend other Process modules?

Never done it myself, but I know it's possible to decouple the image processing and keep the goodies on an API for manipulation, similar to PW's. You can take a look at Cloudinary feature to upload an image by its URL. Also, there's IMGIX .

Thanks all — things are becoming a bit clearer now. I think it's just a matter of convincing my brain to look at things from the perspective of the API and not raw PHP. I'll study up on the cheat sheet some more, and try not to ask these rudimentary questions. No promises though.