bernhard

It's really just adding the field to the finder:

Of course it works. If you don't like the wording "staging" you can also google for "migration live" https://www.google.com/search?q=site:processwire.com+migration+live

long time no see, great to have you back and thanks for sharing ?

Hello Bastien and welcome to the forum, there's no one single one-click solution for that, but we have several options. Did you already do some research? https://www.google.com/search?q=site:processwire.com+live+staging

Do you know RockFinder?

I always have a dev-section in my config where this would perfectly fit into:

I've also been struggling with this: Thats because the $page you want to check is the first argument of the HookEvent, so you need to apply it there, not at the first part, which is the class (or object). You can also do this:

You can define access per template, per field, per module, per code block (then, yes, you have to write that one if() else() manually). The pw backend is just a pw application itself. Whatever you can do there is also possible in your own applications.

https://processwire.com/api/ref/files/temp-dir/ So it should keep itself clean by default...

The easiest solution would be a redirect to the edit screen: $wire->addHookBefore('ProcessUser::execute', function($event) { $this->wire->session->redirect('./edit'); }); You'd still have the /edit in your url, but is that a problem? At least you don't need any additional clicks...

Hi @breezer, I'd love to see a forum-solution for PW, but to be honest I'd only want to pay for it if it was exactly what I need or extremely flexible. Both is very unlikely. If you want to get familiar with module development in PW this would be a great opportunity to start with. Easy and I'm quite sure it would be helpful for many of us: A favicon generator helper module: You might also want to talk to @autofahrn (forum bug again... *sucks) from this post: If you choose to develop your module open source I'd be happy to assist wherever I can to make it great ? PS: A huge challenge will be all the Frontend Markup Generation of your forum. As every site can be different in PW this makes such modules a pain to develop. I'm working on a Frontend-Theming-Module right now, that might make this a lot easier...

This was posted 15h ago also in the general support forum and has several links to related topics: If you have any specific questions it would be nice to let us know what kind of research you've already done and what options you've already tried out...

I think you could just create a new page under /youradmin that has the admin template and the process "ProcessUser" assigned. Then you can hook into executeEdit to always set the userid to the currently logged in user: $wire->addHookBefore('ProcessUser::executeEdit', function($event) { $this->wire->input->get->id = $this->wire->user->id; }); I'm once more impressed by the flexibility of PW ? My user has id 41 of course, and not 123456789.

Happy to assist. I think it would be a good idea to give very clear and easy instructions of how to help. Something like a little tutorial that guides us step by step through the process from finding an un-translated word to creating the PR. Thanks for taking this project over! ?

I'm far from an expert on all this npm, node, grunt things (actually I use none of them, just a php less parser to compile less to css on the fly) but I don't get why you want to do all the compiling on both machines? Why not do all the compiling just on your local dev machine and then git push/pull the static files to your live server? Only problem with that workflow is that db changes are not synched automatically but usually you don't have a lot and if you have, they are quite easy to solve. You have at least three options: Move a DB backup from your local dev to remote live and restore it there. You can do this only, of course, if there where no changes/updates on the live system during your development. Use PW's import/export tools. You have pages import/export and template/fields import/export. For small updates those tools work well and fast. Use code to do that automatically, eg via the migrations module or wireshell.

Here's a little Tutorial of how to get pages and their parent's titles requested by @mel47 The page structure: The initial basic Finder: The easy and inefficient way: This will load all pages in memory and be slow when you have lots of pages! The a little more complicated but far more efficient way. First, we prepare the finder to join: Then we join that finder to the initial finder: Then just hide those two unnecessary columns in your final grid: document.addEventListener('RockGridItemBeforeInit', function(e) { if(e.target.id != 'RockGridItem_yourgrid') return; var grid = RockGrid.getGrid(e.target.id); var colDefs = grid.gridOptions.columnDefs; var col; // all your grid's frontend settings grid.getColDef('parent_id').hide = true; grid.getColDef('cat_id').hide = true; });

I'd vote for that. I've tried a multisite setup years ago but then ended up in a mess where I had several websites using one multisite setup and one breaking all others or being extremely tedious to bring out of that setup. Customizations are not so easy, you might have modules that do not work on a multisite setup etc etc. But maybe it was only me and it's working well for others. I'm happy to hear different experiences!

Just for reference, I think the easiest way to do aggregations at the moment is creating a regular finder and taking the resulting SQL as subquery and modifying it to your needs: And if you need it in your code (not in the RockFinder Tester) you need to set the SQL via $finder->sql:

You are right, so I guess the docs are misleading in this case.

same

Am I using it wrong or is this a bug? According to the docs it should support the array syntax, shouldn't it?

Thx again! I knew there was such a possibility but was looking all over the wrong spots ? echo $uk->home->rocktheme_footermenu->implode(" | ", function($p) { return "<a href='{$p->url}'>{$p->title}</a>"; }); Now it feels like PW again ?

Here are the docs: https://processwire.com/api/ref/wirearray/each/ I simply want to create a footer-menu... nothing fancy, but I thought instead of foreach I'd use the each() method... but some details are missing for this use: The method can return a concatenated string or an array of items. What I'd need - or at least what I think what I'd need - is that it returns an array of generated strings. The Problem: $pages->each("<a href='{$url}'>{$title}</a> | "); Results in Item 1 | Item 2 | If it returned an array with those strings I could simply do this: echo implode(" | ", $items); Using this syntax does also not work: $pages->each(["<a href='{url}'>{title}</a>"])); As it returns this crazy array where I can't use implode() either: My traditional way of doing this would be this: $del = ""; foreach($uk->home->rocktheme_footermenu as $p) { echo "$del<a href='{$p->url}'>{$p->title}</a>"; $del = " | "; }; But I think this would be nicer and feel more like PW: echo implode(" | ", $uk->home->rocktheme_footermenu->each("<a href='{url}'>{title}</a>")); Am I missing anything or would it be nice to have the Option of returning a simple array of strings?

Thx for the hint! This calls for being built into a pw module ?

Hey! I'm developing a module for easy and fast frontend development (something like theming) and implemented favicons yesterday. Referencing one favicon for browsers is one thing, but referencing all different versions another... I used http://www.favicomatic.com/ that generates all the favicons for me and it also creates a code.txt file with the necessary markup. Now in my module I just have to upload a favicon to their website and place all the files in a specific folder of my module. Everything else is done automatically. That's quite nice, but I was wondering how you guys are doing it? Is my linked service a good choice? There is also https://realfavicongenerator.net/ but this has the drawback for me that it does not generate a codefile so I'd have one extra step in the process. Thx for your opinions!