Leaderboard

Heya folks! Just wanted to say that I finally got a chance to properly test this module, and... wow. Amazing work! It looks like you had a bunch of additional stuff planned, but the features that already are there are very useful, and apart from a few minor glitches the module seemed to work like a charm. While the built-in template editing tools we have in the core are not at all bad, at least for me the workflow with Designme is still a huge improvement ? At this point I'm mostly curious about what else you might've had in store when you said that the module was "far from being good enough for release". @elabx, care to provide some insight on this? I mean... it feels to me like you could've removed some of the "less "critical" features (widgets, perhaps even the code editor, etc.) and just released the module as-is. I might be missing something important, of course, but that's my impression anyway. Either way I'm blown away by just how awesome this module is! ?

So I basically meant like I felt it needs a bit more of a well thought structure to make it more maintainable for the future (and I think it had some missing parts? can't remember). I have had to give maintenance to other projects *cough* Recurme *cough* and although that one was particularly complex, I learned my lesson that I definitely don't want to release MVP's that turn into a pain to maintain later just for the sake of getting it out there, I might be just wrong of course. (joshua always insisted I was too conservative in this aspect haha) I agree some of the features could be taken off, like the editor and widgets. I also remember some bits were missing to make it fully functional at the point we envisioned, I think a bit of stuff with repeaters/repeater matrix, don't remember now honestly but it indeed works for the most part! We really feel it shows a lot of the power ProcessWire "hides"!

ProcessWire blocks direct access to PHP files within the templates directory, see: https://github.com/processwire/processwire/blob/master/htaccess.txt#L317-L318 And with good reason, since the template files are supposed to be included by ProcessWire during page visits, so calling a template directly (bypassing ProcessWire's access checks) might leak confidential data. If you absolutely want to do it your way, move the PHP file outside the templates directory (for example, in the webroot) and it should work (there are several other rules in the htaccess blocking specific files and directories from direct access, so make sure to check the htaccess for those). But the "ProcessWire way" would be to create an API template and page and use URL segments and URL parameters to pass data to it. This way, you get access checks out of the box and can utility ProcessWire's mail modules instead of the native mail function, which will very likely send your mails directly to the spam folder of the recipients ...

Ok, it was "fairly" simple. I didn't find a way to use WireUpload to handle unzipping, so had to do it manually. But this seems to work: <?php namespace ProcessWire; $upgrade = function (RockMigrations $rm) { // Install lang support module modules('LanguageSupport'); // get default language $default = languages()->get('default'); // Download lang pack from github to cache folder, unzip and loop and add .json files to language_files field for the language $http = new WireHttp(); $zipUrl = "https://github.com/apeisa/Finnish-ProcessWire/archive/master.zip"; $zipLocal = config()->paths->cache . "language.zip"; $http->download($zipUrl, $zipLocal); $items = files()->unzip($zipLocal, config()->paths->cache); if(count($items)) { foreach($items as $item) { if (strpos($item, ".json") === false) continue; // Yeah, there could be more proper check here... $default->language_files->add(config()->paths->cache . $item); } } // finally save the language $default->save(); // UI update needs still logout/login or modules => refresh modules()->refresh(); }; Not sure what part of that could be part of RM and how? Also - in this level uninstall of LanguageSupport works nicely - I think it might be a lot more complex when multilang fields are involved.

@ThierryGD I have never used this module, so no idea. If you don't need something custom-built or super specific, I recommend Form Builder for ProcessWire: https://processwire.com/store/form-builder/ It's a commercial module, but absolutely worth it. Comes with automatic mail notification to site administrators for new form requests, as well as an auto-responders. For actual mail delivery the best option is to use a mail account and send mail through SMTP. There's the WireMail SMTP module for that.

Thx @Juergen that also helped me today. This is what I came up with (for future reference) when I needed to add a page clone button: /** * Add clone button to form */ public function addCloneButton() { // add button to form $this->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->arguments(0); $form->add([ 'type' => 'submit', 'name' => 'btn_clone_plan', 'value' => __('Clone'), 'icon' => 'clone', ]); $form->get('btn_clone_plan')->addClass('ui-priority-secondary'); }); // process input $this->addHookAfter("ProcessPageEdit::processInput", function($event) { $form = $event->arguments(0); if($form != "InputfieldForm") return; // dont fire on inputfields if($this->input->post('btn_clone_plan')) { // tell PW to save the page $this->input->post->submit_save = 1; } if(count($form->getErrors())) { // clone only if there are no errors, otherwise do a regular save unset($this->input->post->btn_clone_plan); } }); // do the clone $this->addHookAfter("Pages::saved", function($event) { if(!$this->input->post->btn_clone_plan) return; unset($this->input->post->btn_clone_plan); // prevent endless loop! $clone = $this->pages->clone($event->arguments(0)); $this->session->redirect($clone->editUrl); }); } PS: This approach might be easier, but I wanted an extra button:

Relative to ProcessWire 3.0.161, version 3.0.162 contains 24 commits that continue upgrades/improvements to selector operators, fix various minor issues, add new API convenience methods, improve documentation, optimize and refactor various portions of code and DB queries, and much more. For full details, see the dev branch commit log as well as last week’s post. Next week I hope to finally finish up a new version of ProCache and continue with some additional core to-do items. By early August my hope is that we’ll have the next master branch version ready. Also added this week is a new dedicated documentation page on this site that covers all of ProcessWire’s selector operators, including all the newly added ones here: selector operators. Thanks for reading and have a great weekend!

If you must use these files it would probably be best to call the php file from a ProcessWire template. For instance the same template that outputs the form. You could change the form’s ACTION from “contactform-process.php” to “/” and check if the form was submitted at the top of the template file (for instance, if $input->get or $input->post contains some value or possibly if $config->ajax is true, depending on what the form does). If so, include the contactform-process.php file. If you tell us what you’re trying to achieve, we might be able to help you do it with ProcessWire, though.

Today I want to share a little module that adds 2 additional save buttons with redirect and 1 unpublish button to the page edit. 2 additional save buttons: My intention was that it would be nice if someone saves an article in the backend and will be redirected after saving directly to the frontend page of the article. This module adds 1additional save button at the bottom next to the default save button and 1 at the top. So you can choose if you want to save the article with the default save button or you will save it with the custom save button and you will get redirected to the frontend article. 1 unpublish button: The idea behind this was that I want to disable the setting tab for non superuser. The problem was if I hide it, then non superusers are no longer able to unpublish an article. Therefore this module adds an additional unpublish button at the bottom - the user clicks it and the page will be saved with status unpublished. All pages under the admin section will not be affected of this module. Module is multilingual, so you can set the button texts in all languages. Top view page status published: Bottom view page status published: Bottom view page status unpublished: Here is the code: <?php /** * Adding 2 additional save buttons with redirect to frontend and 1 unpublish button for page edit form. * * ProcessWire 2.x * Copyright (C) 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class CustomPageSaveAndUnpublish extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Custom page save and unpublish module', 'version' => 1, 'summary' => 'Example for adding 2 additional save buttons with redirect and 1 unpublish button to page edit', 'href' => 'http://www.processwire.com', 'singular' => true, 'autoload' => true ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addSaveButton"); $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addUnpublishButton"); // tell processwire that this is a page save if ($this->input->post->submit_save_minor) { $this->input->post->submit_save = 1; // attach hook on page save $this->addHookAfter("Pages::saved", $this, "hookPageSave"); } if ($this->input->post->submit_unpublish) { $this->input->post->submit_save = 1; // attach hook on page save $this->addHookAfter("Pages::saveReady", $this, "hookPageSaveReadyUnpublish"); } } public function hookPageSave($event) { //function to redirect to the frontend after save $page = $event->arguments("page"); if ($this->input->post->submit_save_minor) { // this will get saved after this saveReady hook so no need to save here $pageid = $page->id; $goto = wire("pages")->get("id=$pageid")->url; //get url of frontend article wire("session")->redirect($goto); } } public function hookPageSaveReadyUnpublish($event) { //function to change the status to unpublished $page = $event->arguments("page"); $status = $page->status; $unpublishmessage = __("Status of the page is set to unpublished"); if ($this->input->post->submit_unpublish) { if ($status == 1) { $page->status = "2049"; $this->message($unpublishmessage); } } } public function addSaveButton($event) { //function to add the 2 additional save button with redirect at the top and at the bottom $page = $event->object->getPage(); $status = $page->status; if (($page->rootParent->id != "2") AND ($status == 1)) { //dont show on all pages which are under the admin section and which are not published $form = $event->return; $buttontext = __("Save and go to page"); // new submit button $f = $f2 = $this->modules->InputfieldSubmit; $f->attr("name", "submit_save_minor"); $f->attr("value", $buttontext); $f2->attr("name", "submit_save_minor"); $f2->attr("value", $buttontext); $f2->class .= ' ui-priority-secondary head_button_clone'; // add submit button after the regular save button only if page is published $form->insertAfter($f, $form->get("submit_save")); $form->insertAfter($f2, $form->get("submit_save")); } } public function addUnpublishButton($event) { //function to add the unpublish button at the bottom if page has status published $page = $event->object->getPage(); if ($page->rootParent->id != 2) { //dont show on all pages which are under the admin and dont show the button under the delete tab $form = $event->return; $unpublishbuttontext = __("Unpublish"); // new submit button $f = $this->modules->InputfieldSubmit; $f->attr("name", "submit_unpublish"); $f->attr("value", $unpublishbuttontext); // add unpublish button after the save button if ($page->status == 1) { $form->insertAfter($f, $form->get("submit_save")); } } } } Everybody who is interested can download the modul here: CustomPageSaveAndUnpublish.zip Best regards Jürgen

Yes, what I'm saying is that if you have HTML Entity Encoder enabled for the Title field then you wont get the cut off title, because < will be encoded to &lt; and so strip_tags() will leave it alone. The issue you've raised probably hasn't been noticed before because PW has the HTML Entity Encoder textformatter applied to the Title field by default and it's rare to disable it. If you're wanting to avoid double-encoding by Twig then until the issue is fixed you could just encode the title field before Page List renders the label: $wire->addHookBefore('ProcessPageListRender::getPageLabel', function(HookEvent $event) { $page = $event->arguments(0); $page->title = htmlspecialchars($page->title); });

Regarding a) and b) you might perhaps find some useful bits and pieces from here: https://github.com/teppokoivula/VersionControlTests/blob/master/tests/VersionControlTest.php. If I remember correctly, installing language support and adding new languages was indeed relatively simple, though if you want ProcessWire to recognize them right away you need to go through some extra hoops (look for "reloadLanguages" and "LS_init"). In fact reloadLanguages() was initially added for this case. That being said, this is some very old code, so I have no idea if it still runs (properly) ? Edit: looks like you solved it already ?

Hi Teppo, thx for your thoughts! ? Interesting question. I'll try to brainstorm some answers/questions and refer to the two solutions as packages- and modules-route: Modules could only support one markup (how would you ship markup for uikit/bootstrap/tailwind/... ? Or you would need to define renderFormUikit(), renderFormBootstrap(). Modules would have markup code in module code (ugly string concats etc) or would need to implement $files->render(...). Related to the previous point: Render files in module-route could have any name, live in any folder, etc - there's no standard, wheras using the packages route a module could have /partials or /views folder and everybody familiar with Wireframe would get what's going on Everybody not familiar would not get what's going on or could maybe even not use it ? Maybe it would add more overhead then necessary?! Your modules syntax seems very clear to me! I guess the request came with some background in my mind: I wanted to have packages with PHP (logic + view) code, LESS for style and JS for frontend. For example the searchForm might need some JS to work that you need to add to your theme. But that would also be easy to add to the layout with one single include, so that would also be no real argument for the packages route ? Packages would have the same context as all Wireframe view files (including other partials etc; not sure if that makes sense though, because packages should work as-is (standalone) without any theme related partials...). I think I have to just try both approaches on my current project and report back my findings ? I really want to avoid copying files over to an extra place that breaks updates! ?

Looks like GitHub itself is down right now, so this probably has nothing to do with SettingsFactory ?

you need to check images count if(count($page->images)) { // the page has one or more images } https://processwire.com/docs/fields/images/ https://processwire.com/api/ref/page/if/

How is your inputfield's formatted value configured? try setting it to be formatted as a single item.

Hi, for better readability and more stability in edge cases, I would use the $config->paths->get("NameOfMyModule") syntax to get the exact matching path to your modules root directory. This is working even if someone, for example, dropped in the module from zip from github and the directory name became something different like "NameOfMyModule-master". I only would use this in front- and back end. $includeFilename = $config->paths->get("NameOfMyModule") . 'css/style.php';

?‍♂️ Makes sense. I've added this to my todo list, will take care of it soon. Again, makes sense. I'm personally not a huge fan of tutorials — it's just not my thing. I prefer to learn by finding a project to work on, or alternatively by digging into existing implementations. Probably explains why there's no tutorial available for Wireframe either. Another item on my todo list ? Yes. On a very minor note the API for redefining component view would look like Wireframe::component('foo')->setView('bar'). Also: I typically choose the view in the component, i.e. the constructor picks the most suitable view based on the params it received. Both approaches are fine though, depends on the context! ? Interesting idea! I can definitely see value in this, but I'd still like to give it a bit more thought. It's easy to add features, but hard to remove (or significantly alter) them, so I prefer not to rush things ? Out of interest, how do you see this comparing to Markup modules using render method(s)? For an example: <!-- RockSearch with partial --> <section><?= $packages->RockSearch->partials->searchform() ?></section> <!-- SearchEngine --> <section><?= $modules->SearchEngine->renderForm() ?></section> One benefit would be that if I wanted to use the default search form as a starting point and start building on top of that, I could just copy the file to local partials directory and change the reference in the layout. This would, obviously, mean no more easy updates, so it's a double edged sword. In SearchEngine I decided to go with a set of interconnected render methods, each tasked with some specific part of the markup. I felt that this provided the best balance between reusability and customization: one can get pretty far by modifying config settings, but if that isn't enough, it's also possible to make more drastic changes using hooks. All in all I really like the idea, but it will require a bit more thought and probably some experimenting to strike the perfect balance ? Hopefully I'm answering the right question: Controllers and views are specific to a single template. Controllers' job is to accept arguments, process data, and pass processed data to the View layer. View — which consists of layout(s), view files, and partials — is there to output said data, so it should be as "dumb" as possible. View doesn't need to know anything about what's going on behind the scenes. Partials were originally just "include files" without the ability to accept params or a dedicated approach for processing data. They were great when you had a relatively static block you wanted to repeat in multiple templates, but if you wanted to pass them params, you'd have to define them in the parent context, etc. Components were added to fill this void. There's always a class that can accept arguments and process data, and usually there's at least one view file meant to render output. (Components can also render output directly by implementing the render() method, or they might not produce any markup at all, so technically component views are optional.) ... and then things changed a bit when partials also got the ability to accept params. Now the biggest difference between components and partials is the class: I prefer not to mix code with markup, which means that if I need a reusable "thing" that needs to, say, fetch data from an API, it's a component. On the other hand if I just need to reuse a block of HTML and perhaps iterate/output some variables in there, most of the time I go with a partial. In my mind controllers + views (and layout(s)) are the typical way to use Wireframe. Components are handy when you need an element that should be reusable across multiple templates. I guess they're sort of "template-agnostic miniature controller + view" bundles ? Note: how you actually use Wireframe may vary. Your site might not have any controllers, relying on components instead. Or you could produce all the markup in the layout and have no other files (apart from the bootstrap file). What I've described above is just the way I prefer to do things ?

A huge shout out thank you to all the PW developers who have, and continue to help me.

@teppo Dude, this was in my head when it worked. Thank you!!!

Check the "Advanced" tab in the Template settings. There you'll find an option to make the createdUser modifiable:

@schwarzdesign, I agree with your suggestion in the GitHub issue, but in terms of working around it double-check that you have the HTML Entity Encoder textformatter applied to the title field (it is by default after installing PW, and should be applied to all plain text fields). Because with that applied I don't experience the issue on a clean PW installation:

As a workaround, just use ≤ ?

This is an amazing project! I tried it works pretty much everything. I really hope that someone with the right knowledge (and here there are many people who have them) can complete and implement it. Anyway I start using it right now! Really thank you @joshuag for this module!

Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip

thanks - and i guess the version file needs to be updated (?).. this is working well for me; I have my own dashboard module, but it uses templates, pages and fields, and is thus cumbersome for smaller/low budget sites. My dashboard module uses AdminLTE, so it has stuff like collapsible panels with state recall; For some of the more complex panels like Formbuilder entries, etc, i'll just build custom panels and hook into this module. Thanks again for building this! This is very extensible, looks and works great, and seems like it will be a very popular module! Here's the dashboard i just threw together...

Thank you for the module, it helped me understand how to create an additional button to add extra actions...