bernhard

I think it's great to have all modules under "Setup" for Superusers and for clients on bigger sites/apps you can separate modules into several sections:

Offtopic, but have you (@zeka) had a look at RockFinder and RockGrid? And the upcoming RockFinder2 and RockTabulator? ?

Hm... For whatever reason the halt() method is protected and can therefore only be called from within the class or derived ones. Passing $this to the function does not work and I don't know of any solution other than using die() or exit() in this case. Or just let the function return false and halt outside in that case: function foo() { if(...) return false; echo 'foo bar'; } if(foo() === false) return $this->halt(); echo 'something more';

Hi @tpr any chance we can get a fix for this issue in AOS as long as it is not fixed in the core? https://github.com/processwire/processwire-issues/issues/812#issuecomment-520855872 Thx ?

I've never used url segments in the admin myself. You can always use url parameters though. Only thing you have to keep in mind is that PW strips off all parameters except the ID parameter when a user is not logged in and wants to visit yoursite.com/yourbackend/yourmodule/?id=1&foo=2&bar=3 which would mean he would be redirected to yoursite.com/yourbackend/yourmodule/?id=1

Can we see your executeRefresh() method? Maybe it's just a typo? I'd try "foo" + "executeFoo" instead of "refresh" - maybe it's a reserved word for whatever reason or conflicting somewhere else?

What is your question? Is it still not working?

Thx, fixed in 1.1.5 True, but I won't fix this as it's not critical and I want to focus on RockFinder2 + RockTabulator ?

I just had a quick look and the description "best of both worlds, WYSIWYG + pre-defined blocks" sounded great ?

This looks really awesome! ?

Yeah - I've too often had to build complicated RockFinder queries and came up with this quick&easy solution one day and couldn't believe I didn't think of it earlier ? Don't tell anybody, but I've just started developing RockFinder2 with a new syntax that will be even easier to use and more intuitive and powerful ?

That's a good idea. Though I'm not sure if non-technical users totally understand what that means or what is going on. I agree. I just had my first statement in an open browser window and did not submit ?

I'm always happy to improve, thx ? I was thinking of that... Then I thought it might make sense to put all those little admin "bugfixes" in a module that we can install on any site. But then I thought that's basically the same as AOS, so maybe it would be something for @tpr ? And it seems that @adrian already has such a module that he installs on every site that fixes issues that ryan has not fixed for a longer time? Maybe it would make sense to open such a module up for the community for collaboration? Or maybe this would be counterproductive as it would seduce us to quick-fixing things and not properly file issue reports and wait for ryan to implement it?

Ok, I get your points and agree. What do you think of displaying the url directly under the title field and show an edit icon that takes you directly to the settings tab? I think this would make it more obvious to the editor that changing the title does NOT change the url while it gets a lot easier to change the url even when the field is "hidden" under the settings tab.

Are you using markup regions? Those can lead to unexpected output sometimes.

I've used template prefix syntax for my fields in one project and it is really annoying now ? You might find some inspiration here: https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/

Another option could be to build a redirect page, eg mysite.com/?id=1234 that redirects to this page, eg mysite.com/myparent/mypage - then you can easily and efficiently build your links via the ID property.

I think that having different page titles and names is not what a user wants 90% of the time. I think it would be great to have it synched by default (eg a checkbox that enables custom pagenames only if the user really wants to). This could then also work when a page is cloned and the title is changed. The pagename would automatically change.

There's nothing wrong with using RF for the frontend, but you are right, pagination was not on my list. And I don't think we will ever need it for RockFinder, because if you are using pagination, you can use native PW find operations without any performance drawback. Exactly, that's why I implemented the callback feature where you can use the PW API to get any properties of your page via PHP:

Hi @ryan, This is indeed an ingenious little helper! Thx for sharing this idea with us! One problem though: When I'm only in the backend, the url and filename methods get never called. Could you please make the setFilename method hookable so that this method also works when the page is just edited in the backend? It would then only need this simple hook and all files are downloaded on demand: $wire->addHookAfter('Pagefile::setFilename', function($event) { $file = $event->object->filename(); if(!file_exists($file)) { // download file from source if it doesn't exist here $src = 'https://example.com/site/assets/files/'; $url = str_replace($this->config->paths->files, $src, $file); $http = new WireHttp(); $http->download($url, $file); } }); Or is there a better way of doing it? Edit: Ryans version does of course work without issues - just make sure to have the proper PW version installed ^^

I get this error on one site using tracy debugger. Are you using tracy?

Seems that modal=1|panel is used to hide the header/footer, but you also need pw_panel=1 for handling link targets: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Jquery/JqueryUI/panel.js#L86-L121

sorry, of course it was ?modal=panel The pw_panel get param is new to me - what does it do exactly?

You have the ?panel GET parameter, can't you use this?

Hi @AJOSPACE Why do you want to have a non-superuser that can do that? Please explain your usecase...