bernhard

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!

Hi @MarkE and welcome to PW and the forum ? I think PW is great for building what you described. But I'm "a little" biased as I build everything with PW from simple websites to complex custom CRM and Feedback Tools... Yes. Is it a sports club? Then you can have a look at mistelbach-mustangs.at's calendar or the team site. Sounds good to me. But I'd recommend starting in the backend first (more on that later). You'll get an idea of how everything works and you might be better off doing the frist part also in the backend. That's not a general statement, you'll just be able to do a better decision once you know how the system works and it might save you from building a custom frontend once you know how easy it is to build custom backends ? Not sure about this one. I guess your wording is just a bit different from the PW world. I guess you mean you want to want to modify your data objects, right? So in PW this would mean your objects are pages, and your properties are fields. Classes would be templates, so for example you could have a template (~class) "team", an instance of this class would be the object, in PW this would be a page "Team A", and to modify it you'd simply add/remove/edit such a page. And yes, you can control anything you want here easily. You can set permissions in the backend and you can even set permissions on a field level. If that still is not enough there are several helper modules out there: https://modules.processwire.com/categories/users-access/ And if that still is not enough control, it's really easy to attach hooks or for reusability and better code organization it's also dead simple to create custom modules. That does sound strange again. The PW backend is just an application built on top of the PW API to manage it's own data (crazy and genius). Just have a look at the page tree and find your admin's root page (page id = 2). Most of the pages there use the "admin" template, but not all, for example the permissions have their own "permission" template: Having an "admin" template just makes it possible to assign a ProcessModule to this page. That means visiting this page via its URL calls the selected process module: So, creating your own admin pages is really nothing else than creating a PW page with template "admin", creating a ProcessModule for it and assigning it to that page. Have fun ?

Tried that now but still have red <region> tags. Which version of VSCode are you running? I think there was an update that changed the tag grammar some time ago...

That sounds great @BitPoet, thx! Could you please elaborate a little more on that? Thx ?

Thx, unfortunately this did not really help. It seems that this has something to do with the color theme. Some themes do invalid items red, others don't. Unfortunately I was not able to create a custom version of the default dark plus theme that only overrides the invalid token color setting. It seems to be not as easy as setting the option in the user settings. And copying the theme and overriding did not work for me. Has anybody of you tried this before with success?

Does anybody of you know how one can make VSCode not display pw markup regions in alerting red?

You are obviously missing TracyDebugger ?? SCNR, but joke aside, tracy does also help you a lot on ajax debugging. It has fl() = firelog and bd() = bardump that can help a lot to see what's going on! A quick guess: If you are using custom AJAX scripts it might be the case that the headers are not set correctly so that PW recognizes it as $config->ajax == true. Maybe that's not at all helpful, not sure, but in a hurry ?

Thanks robin, using the config.js file it worked as expected. It still does not work using the inputfield settings... I used the exact same string that you have in your screenshot... No idea. But it's fine for me now that the workaround is in place.

v18 adds a plugin that can sync page fields with rockgrid columns: Example Setup Adding the asm in a processmodule. $fs is a fieldset where we add our InputField to. $gridname is the name of the grid that is connected. // which lists to show $this->wire->config->scripts->append($this->wire->urls($this) . "scripts/manageLists.js"); $fs->add([ 'type' => 'InputfieldAsmSelect', 'name' => 'listsToShow', 'label' => __('Show list membership for...'), 'attr' => ['data-grid' => $gridname], 'asmOptions' => ['sortable'=>false], ]); $f = $fs->getChildByName('listsToShow'); $f->setAsmSelectOption('sortable', false); foreach($pages->get('template=rockmailer_lists')->children as $item) { $f->addOption($item->id, $item->title); } And the portion of the javascript file: // sync ASM field with displayed lists in grid // attach event listener when document is ready $(document).ready(function() { var $select = $('#Inputfield_listsToShow'); var colPrefix = 'rockmailer_list_'; RockGrid.plugins.syncAsmSelect({ asm: $('#Inputfield_listsToShow'), grid: RockGrid.getGrid($select.data('grid')), colName: function(pageId) { return colPrefix + pageId; }, colDef: function(col) { col = RockGrid.colDefs.yesNo(col, { isYes: function(params) { var pageId = String(params.column.colId).replace(colPrefix, ''); var lists = String(params.data.rockmailer_lists).split(','); return lists.indexOf(pageId) > -1 ? true : false; } }); col.pinned = 'left'; return col; } }); }); In this case we set a custom callback to modify the colDef for the column. It uses the yesNo plugin to show icons instead of true/false values:

I've just added this plugin successfully: https://ckeditor.com/docs/ckeditor4/latest/guide/dev_colorbutton.html Unfortunately it seems that the field's settings do not have any effect ? I tried several versions: {"colorButton_colors": "FFB400", "colorButton_enableAutomatic": false} {"config.colorButton_colors": "FFB400", "config.colorButton_enableAutomatic": false} colorButton_colors: "FFB400" config.colorButton_colors: "FFB400" It still shows all the default options: Can anybody help me, please?