Leaderboard

Not why it wouldn't work for you - it works for me. Tracy Debugger is a useful tool that can help you debug. Now that I see you are deleting the page being saved you don't need to worry about making the fields not required - you can delete the page and redirect all within the before ProcessPageEdit::processInput hook. When you redirect you interrupt anything else that would normally happen such as evaluating the input for empty required fields and saving the page so these things will not happen. $wire->addHookBefore('ProcessPageEdit::processInput', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->arguments(0); // Only for the ProcessPageEdit form if($form->name !== 'ProcessPageEdit') return; $page = $event->object->getPage(); // Use $page to check for specific templates here... // Check field values in POST $input = $event->wire('input'); if($input->post->delete && $input->post->delete_confirm === 'DELETE') { $event->wire('pages')->delete($page); // Delete user also if needed $event->message('Your message here'); $event->wire('session')->redirect($event->wire('config')->urls->admin); } });

You have to hook before the input is processed and make those fields not required. Example: $wire->addHookBefore('ProcessPageEdit::processInput', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->arguments(0); // Only for the ProcessPageEdit form if($form->name !== 'ProcessPageEdit') return; $page = $event->object->getPage(); // Use $page to check for specific templates here... // Check field values in POST $input = $event->wire('input'); if($input->post->delete && $input->post->delete_confirm === 'DELETE') { // Get normally required fields and make them not required $first_name = $form->getChildByName('first_name'); $first_name->required = false; // Repeat for other required fields... // Do your delete/notification/redirect actions here // Or if you need the page to actually save when deleting then do actions in separate Pages::saved hook or similar } });

Couldn't you use this, assuming all offices, eg HUMAN RESOURCES have a template names "office" $page->parents('template=office'); Actually you might want "parent" instead of "parents" to make it easier in this case.

Personally when I install a CMS I prefer to set it inside a subdirectory rather than the root folder. There are different reasons for this choice. For example you may wish to have different CMS installed in different subdirectories; or multiple copies or versions of Processwire in different subdirectories; keep separated directories for production and development; and so on. Sometimes this choice is taken also to obfuscate your CMS contents. In this forum I found some helpful hints, but I could not find a turn-key tutorial explaining the detailed steps for redirection and how to hide subfolder in urls' segments. It's pretty easy. Just let's do it step by step. We are going to create a new .htaccess file in the root folder (please note it is a new one, we will leave the .htaccess file in Processwire subfolder unchanged), where we will add the section described below. Just replace yoursite.com and yoursubfolder with ... your ones! # .htaccess in root directory # Redirect to Processwire subdirectory <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?yoursite.com$ RewriteCond %{REQUEST_URI} !^/yoursubfolder/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /yoursubfolder/$1 RewriteCond %{HTTP_HOST} ^(www.)?yoursite.com$ RewriteRule ^(/)?$ yoursubfolder/index.php [L] </IfModule> With this approach we can protect root files and subdirectories from redirection. Are we done ? Yes and no. After these modifications pages are redirected correctly, but in the browser link you will note that subfolder's name is still showing. This is not good, we want to hide it. We are just one step away. Let's open our site/config.php and add the following line at the end: /** * Set urls root to hide Processwire folder * This must be combined with .htaccess in root directory */ $config->urls->root = '/'; Do not forget to lock site/config.php after modifying it. If you prefer, instead of modifying config.php, you can place the above line in _init.php. And here it is! I hope this simple tutorial can be of help.

Use Adrian's solution

@Robin S - thank you very match!!! The solution as I wanted!

Hi,sorry if the topic is covered elsewhere.Background : I'm a part-time, for hobby (ie. not-for-a-living) processwire developer,so I'm probably not very representative of the community, Question : I'm wondering what is the "governance" status of processwire, these days ?With this question, I mean that let's say we segment processwire as follows :1- pw core / roadmap / Ryan new features2- pw core / roadmap / community features requests3- pw core / issues fixes4- pw websites / main site5- pw websites / forum6- pw plugins ecosystem / Ryan commercial extensions7- pw plugins ecosystem / community free + community commercial8- pw weekly...My understanding of the current governance status is :1- : This is Ryan's soverain decisions (for very good reasons ? , with addition of some core members work (on some pull-requests).3, 4- : This is also Ryan driven ; with several core community members doing the diagnosis & triage of issuesAll the above activities (1, 3, 4), along with activity 2-, basically, are funded by the community purchasing Ryan commercial extensions (6).5-, 8- : These are mostly run by several core community volunteer members.Now I'm wondering about 2- :What is the governance system for defining pw roadmap ? for "injecting" the community feature requests into pw roadmap ?Is there some kind of "board" of core members + Ryan, for deciding on the prioritization of these things ? or something like that ?Is there some kind of baseline defined for the breakdown of work on core activities 1- vs 2- vs 3- ?As a not-for-a-living user, I don't have any special nor legitimate expectations about pw roadmap decision-taking (besides having a better understanding of what becomes a feature request which one deposits on github ?But I guess the expectations must be different for other people, who are financially involved in pw ecosystem.And as a side note, I'm also wondering about 7- , as my feeling is that a frontend merging of 6- (which would remain prime) and 7- would, I think, be key for a broader pw outreach beyond the current adopters, for the benefit of the whole community ; something similar to eg. https://www.opencart.com/index.php?route=marketplace/extension thanks for your insights

There's this module which was created to work around that exact issue: https://modules.processwire.com/modules/fieldtype-page-ids/

At this point I'd like to open this issue to someone who is way more into hooks and custom functionality than I am. Maybe @bernhard or @adrian or @szabesz or @dragan ... they know a lot more about hooks and ProcessWire than I do. They will have a solution for this.

Go to /processwire/module/edit?name=TracyDebugger edit Tracy's settings: Check this option That way only Superusers can see Tracy on the live site. Hope that helps

While I also mostly use the alternative syntax for the very same reason, it is also worth noting that (at least on the frontend) Tracy Debugger's Validator panel is quite handy. I keep using it all the time.

I just wanted to mention. I found a new job as a front-end dev at https://backslash.ch. Since 2 months there already and enjoy it. We work with in-house CMS specially targeted to governments. So a lot less PW for me in the future, but I'll use it as my tool for private projects.

Here's a basic example of how you could save files to a PW page via a front-end page using tus-php and Uppy. 1. Install tus-php via Composer. 2. Create a PW template that will provide the tus-php server endpoint - in this example the template is named "uppy". In the template Files tab, disable any automatically appended template file. In the template URLs tab, allow URL segments. If using Tracy Debugger, disable the debug bar in the front-end for this template because we don't want any output from Tracy being included in the response. The contents of the uppy.php template file: <?php namespace ProcessWire; // Create PW temp directory $td = $files->tempDir('uppy'); $td_path = (string) $td; // Create TusPhp server $server = new \TusPhp\Tus\Server(); // Set path to endpoint - no trailing slash here $server->setApiPath('/uppy'); // Set upload directory $server->setUploadDir($td_path); // Listener function for when an upload is completed $server->event()->addListener('tus-server.upload.complete', function(\TusPhp\Events\TusEvent $event) { // Get path of uploaded file $file_path = $event->getFile()->getFilePath(); // Add uploaded file to "files" field on Home page $p = wire('pages')->get(1); $p->of(false); $p->files->add($file_path); $p->save('files'); }); // Send response $response = $server->serve(); $response->send(); // Exit from current PHP process // Could probably use PW halt here as an alternative // return $this->halt(); exit(0); 3. Create a page using the template - in this example the page is at url http://1testing.oo/uppy/ 4. Add the Uppy assets, JS and markup to the template of the front-end page that you will upload files from. Markup Regions are used in this example. <pw-region id="scripts"> <script src="https://transloadit.edgly.net/releases/uppy/v1.4.0/uppy.min.js"></script> <script> const uppy = Uppy.Core({debug: true, autoProceed: false}) .use(Uppy.Dashboard, {target: '#uppy-box', inline: true}) .use(Uppy.Tus, {endpoint: 'http://1testing.oo/uppy/', limit:10}); </script> </pw-region><!--#scripts--> <pw-region id="stylesheets"> <link href="https://transloadit.edgly.net/releases/uppy/v1.4.0/uppy.min.css" rel="stylesheet"> </pw-region><!--#stylesheets--> <div id="body"> <div id="uppy-box"></div> </div><!--#body--> 5. Upload files via the front-end and see that they are added to the "files" field on the Home page.