bernhard

As it seems you are quite new to PW and motivated I suggest to avoid if(this AND that AND that): // user template switch warning in backend $this->addHookAfter('Process::execute', function($event) { $user = $this->wire('user'); // early exit if user is not logged in if(!$user->isLoggedin()) return; // early exit if template is default if($user->template_switch->value == 'default') return; // show message to change template $u = $user->name; $t = $user->template_switch->title; $p = $this->wire('config')->urls->admin . "profile"; $this->wire->warning("...", Notice::allowMarkup); }); Of course this is totally up to you or anybody but IMHO this improves readability a lot. ?

Well... I'm also not convinced 100% myself to ban frontend editing completely ? The interface is great and it's so much more user friendly to get exactly the same visual representation as you type. And it sounds reasonable to only load/save parts of a page and not everything. It always depends on the usecase, just wanted to note that one has to be careful with those fancy tools and also think of the drawbacks ?

I don't know if that is the case and I don't have time to investigate. You did lots of things right (like placing the most basic hook you can think of, then check if it works and only then doing the next step). If you encounter any problems on that road you either have to look for a different solution (like changing from frontend to backend editing) or you have to investigate and find the reason why things don't work as expected. In the current case it could either be a bug or that saving of the field just works a little differently when fired from the frontend. That's by the way one of the reasons why I'm not using frontend editing any more. It bring's too much troubles for too little benefits imho. Doing those investigations can be frustrating sometimes, but you'll learn a lot about ProcessWire which will help you on all following challenges ?

If I got this right, you could sort of achieve the Admin view part of this with Listers and some custom code, or perhaps ListerPro out of the box, though that would mean that such content is no longer managed in any sort of tree structure (yet, at the same time, it would still actually exist in the tree). The latter part could then be half resolved by hiding the page from the tree with a hook that hides such pages from the tree, but it still wouldn't change the fact that in ProcessWire pages always exist in a singular tree. If I understand you both correctly this is what I'm doing with RockFinder2 + RockGrid / RockTabulator. It's far from perfect yet, but it's built for managing content in a non-hierarchical way which is a very common need IMHO. I don't like listers for that purpose at all. They are limited, they are ugly (*personal opinion!* taking too much space etc), they are hard to customize (like colorizations etc), they are not reacting fast to user input. Of course, there are good reasons why they work as they work: Scalability, access control, multilanguage. These are all points that are challenges for my modules. But in all my projects the benefits of having structured grids of data that are nicely designed, compact and "reactive" (like when filtering columns etc.) outweigh the cons. Not saying my modules are the way to go or better than what you describe. Just wanted to share what is already there and how I'm using it.

Hi @celfred I can confirm that your hook does only fired when the page is saved on the backend. Frontend-Editing does not trigger this hook. The Event Interceptor does also show the event log for me... That's a bit strange. Maybe @adrian knows why?

Have you ever tried on-demand downloading of files? https://processwire.com/blog/posts/pw-3.0.137/#on-demand-mirroring-of-remote-web-server-files-to-your-dev-environment This works really great. You can start with a completely empty files folder and PW will download all requested files on demand - either on the frontend or on the backend.

Just added onother fix that has been bugging me for years: https://github.com/processwire/processwire/pull/169 https://github.com/BernhardBaumrock/PwQuickFixes/commit/74c1378d0274bd6a99147bac597490d0113c2633

Not sure ? $pages->find("template=product, has_parent=123, r_produkty_image.count>0"); This should find all your pages and images... Where product is the template of the pages that you want to find and 123 is the id of your Produkty page. Does that help?

Which version of PW are you using? https://processwire.com/blog/posts/processwire-3.0.119-and-new-site-updates/#chunked-ajax-file-upload

Hi Ryan, as always great to hear about the progress ? I have no idea how that will work internally, but this sounds like it might be a good time to also think about having a setting for a custom storage path in core file fields. Maybe that will be possible anyhow by default (like providing an external file system driver that actually stores files on the local file system). But if not this would be a huge improvement in many cases: File fields in module config File uploads with custom storage path in processModules Maybe having a file field on multiple pages sharing one single storage location (like a global gallery) Thx ?

Depends on what you call "serious" but it will be quite a bit of work for sure. IMHO buying FormBuilder will not be enough. What's more important is that you get a good understanding of how PW works. What is a ProcessModule? What is an Inputfield? What a Fieldtype? How does all this play together? Once you get that you can build anything with PW.

Here "content" is my repeater matrix field. See the first dump - it shows the selector used. If you take that selector you get all items (including unpublished). If you do a status>1 you'll get all that are not regularly published (means hidden etc). Doing status>= Page::statusUnpublished would show only unpublished items (not sure if that makes a difference to status>1). And I'm also sceptical if repeaters are the best option here compared to using regular pages ?

I've no experience with this module, but you can modify all markup inside the <div class="InputfieldContent"> via the Inputfield's render method: $wire->addHookAfter("Inputfield::render", function($event) { $event->return = "<div>foo</div>".$event->return; }); If that does not work for your case it might be due to this issue: https://github.com/processwire/processwire-issues/issues/1141 (if that is also an issue for you it would be great to add your problem description there so that ryan sees that it is not only my problem ? )

v0.0.2 Just added some setup instructions and checks on install/uninstall thx to a report of @thausmann

Sorry, forgot to mention that @David Karich added support for options fields and slide ranges, so there is no need for manually doing joins like shown before ? How to create custom column types It is really easy to create custom column types that can retrieve any data from the PW database. See this commit for two simple examples: https://github.com/BernhardBaumrock/RockFinder2/commit/54476a24c78ae4d3b6d00f8adfb2c8cd9d764b9d If the fieldtype is of broader interest please consider making a PR. If you are the only one needing it add the type via hook. Adding a custom column type is as simple as this: $f->addColumns(['FieldOptionsValue:your_options_fieldname']);

@pwired your links are all broken (some safelink.php obfuscation)

There's no simple solution to this problem yet: https://www.google.com/search?q=site:processwire.com+page+builder You have several (not great) options: Hanna Code, CKEditor classes (for simple things), PageTableExtended. The easiest might be to use RepeaterMatrix.

v0.0.2 implements the changes that @adrian put into Tracy to have all hook parameters available in the hook ? A big THX to Adrian! This needs the latest version of Tracy which is not yet online, I think @adrian ?!

@David Karich asked me how one can get values of an options field instead of an ID. It's unfortunately not implemented yet, but it can be quite easily be done manually (and that has the benefit of being extremely flexible and not limiting). I added an example to the readme! Example of how to get values of an options field instead of their IDs: $f = new RockFinder2(); $f->find('template=basic-page, include=all'); $f->addColumns(['title', 'options']); $f->query->select("opt.value AS `options.value`"); $f->query->leftjoin("fieldtype_options AS opt ON opt.option_id = _field_options.data"); db($f->getData()->data); Dumping the query object will be really helpful on such tasks! You can also replace the field's value instead of adding it to the result: $f = new RockFinder2(); $f->find('template=basic-page, include=all'); $f->addColumns(['title', 'options']); $select = $f->query->select; unset($select[2]); $f->query->set('select', $select); $f->query->select("opt.value AS `options`"); $f->query->leftjoin("fieldtype_options AS opt ON opt.option_id = _field_options.data"); db($f->query); db($f->getData()->data);

Yeah, sorry for forgetting about that. It's an old issue: https://github.com/processwire/processwire-issues/issues/550

Just add some javascript that polls the page in the background every 5 minutes or so: https://stackoverflow.com/a/8682723/6370411

Thx, that gives us a good picture. I'm just asking because determining the "online" state like this is not really reliable. What if the user opens another page on the website in a second tab? This would remove the online state on the meeting-hall but this window could still be open. Not sure how critical this online state is and I don't want to overcomplicate things. Just want to make sure you have thought of that ? An easy solution could be to save the timestamp of the last activity of the user on that meeting-hall page. Then you could show "last active 5min ago" and if that time goes beyond lets say 10min you show "offline" or hide the user from that list. Maybe this would also make your setup easier, because you could simply add the timestamp to the users template and populate that whenever a user interacts with the meeting-hall page. A list of all active users would then be $pages->find("template=user, meetinghalltimestamp>$nowMinusTenMinutes")

Hi @celfred Could you please describe the bigger picture of what you are doing? Is this some kind of chatroom like thing?

I think that does not matter and like this it might be more readable ?

That sounds great, thank you very much ? Hm... I think that is not the best option. Better would be to have the variable name as key and the type as value: PS: Sorry, this is taken from the Pages::saved() hook! /** * Hook called after a page is successfully saved * * This is the same as hooking after `Pages::save`, except that it occurs before other save-related hooks. * Whereas `Pages::save` hooks occur after. In most cases, the distinction does not matter. * * #pw-hooker * * @param Page $page The page that was saved * @param array $changes Array of field names that changed * @param array $values Array of values that changed, if values were being recorded, see Wire::getChanges(true) for details. * */ public function ___saved(Page $page, array $changes = array(), $values = array()) {