bernhard

Is your site a multi-instance installation? Why is it site-ncog and not just site? PS: Please try it with a fresh PW single installation and report if that works. If not, report the error. If yes, please try to debug what could be the problem with the other installation.

I guess this has nothing to do with my module. Where and how did you install AdminThemeUikit?

Yes, that's correct.

You need the files AND the database for a working processwire installation, so if you don't have a database dump anywhere, you'll not be able to run pw. Maybe you have a dump in /site/assets/backups/database ?

Hi Torsden, try to use ProcessPageEdit::buildForm, do a google search for this exact phrase and see if you can get examples. Sorry, on mobile ? The principle is to get the right field in the hook and then just change the "required" setting.

Glad to see you again, @Nvim! @Pete, are you also happy?

OR selectors should not be a problem. Could you please try to refresh all cached files? Maybe there's something else that causes this? Please try to narrow it down a little more... What's the array that is converted to string on line 195 of PageFinder.php ?

New version online: 1.1.2 The selector for the finder is now always stored as string, but can be retrieved as string or array - getSelectorStr() or getSelectorArr() This can be useful to share code for grids that are similar but need little adjustments, like one grid shows all available trainings, one grid shows only trainings that where booked by the current user: include(__DIR__.'/trainings.php'); $finder->setSelectorValue('client', $this->user); $finder->addField('done'); $this->setData($finder);

The new rockfinder updates make it easy to extend grids: Extending Grids Sometimes several RockGrids are very similar and you don't want to duplicate your code. You can create one base file and include this file from others: // trainings.php $finder = new RockFinder([ 'template' => 'training', 'sort' => 'from', ], [ 'first', 'from', 'to', ]); $finder->addField('coach', ['title']); $finder->addField('client', ['fullname']); // trainings_booked.php include(__DIR__.'/trainings.php'); $finder->setSelectorValue('client', $this->user); // only show trainings of current user $finder->addField('done'); // add column to show if the training was completed $this->setData($finder); You can then create another file, for example trainings_available.php to show all trainings that are in the future and available for booking: include(__DIR__.'/trainings.php'); $finder->setSelectorValue('from>', time()); $finder->setSelectorValue('client', null); // client must not be set -> means available for booking $this->setData($finder);

Nice! ? Please let us now about the results/answers.

I'm using 5.7 both on dev and live. Sorry, no idea ? http://smalldatum.blogspot.com/2017/06/sysbench-for-mysql-50-51-55-56-57-and-8.html , while http://www.oaktable.net/content/mysql-56-vs-57 says they perform quite similar. Maybe 5.6 has a problem with those subqueries?

RockFinder now supports array-syntax, which makes the code a lot cleaner:

hey @tpr, is there a way to disable the filterbox on some admindatatables, eg via adding "nofilterbox" class to the table? Edit: Created a PR

Sure, it was just an example. This would of course be possible. A shopping cart only functional after signing in? No guest-checkout? No, that's not what I'm thinking of ? But yes, SSO could be a good tool for many other usecases using this approach!

Sorry dragan, totally missed your post! Seems your comments where exactly what I've come up yesterday ? Yeah - it's an early stage idea ? Real logged in users could just have more rights than silently logged in users. What pages are created would have to be managed by the module. But that would be the same if you built that app in the frontend! Take again the shopping cart example: What if you wanted to provide an image upload feature for your user? You'd need to create a temporary page and make sure that the user can only edit this page. If the user did not finish checkout, you'd delete this page after 1 day. The same thing could be done in the backend. I think it is not always necessary to keep track of which user edited recordset x. Again the shopping cart: It would be enough to count how often a product was added to a cart by a public user, or how often a cart was checked out successfully. But as long as the user does not check out the cart, it might not be necessary to log him in as a real, unique user. Another example: What about a public guestbook? Users could click on "create new entry", then the backend could create an unpublished page that only this user can edit (don't know yet how this could be done), the user could save this page (having all backend features like url field sanitization, email, ckeditor input, file upload) and an admin could then publish it after approval. Or think of a forum software: Logged in users could create new content, but public users could only read entries. This would also make a lot of sense to be built in the pw backend as we already have a standard there: Uikit, ProcessModules, jQuery. And boom, one Forum Module could then be instantly used on every other PW installation, with easy theming support via LESS (eg RockSkinUikit). We could even work a little bit on the admin to make it easy to replace the header + footer of the theme, so it would be even easier to integrate the whole forum into an existing website by just injecting the menu and footer section!

Thx Robin, the hook in your link is an interesting idea to handle AJAX ? But I think including CSS + JS from the admin into the frontend would make things tedious... Another approach would be to create a FrontendTheme similar to the AdminTheme that works the same on all installations. But still all the great backend features (file upload, inputfields etc. would have to be rebuilt and that's what I want to avoid.

I just tested it and it worked as expected ? // ready.php $wire->addHookAfter('Pages::added(template=user)', function(HookEvent $e) { $user = $this->users->get($e->arguments(0)->id); $user->addRole('superuser'); $user->save(); }); Tried it in the backend by adding a user manually. Maybe you added your user via API?

I guess when you hook Pages::added you need to call addRole() on the user object, not on the page object, so you'd need to convert that page from the hookevent into a user: $wire->addHookAfter('Pages::added(template=user)', function(HookEvent $e) { $user = $this->users->get($e->arguments(0)->id); $user->addRole(...); $user->save(); }); Not tested ?

Just tested my idea and it works: I created a "public" role + user and it can see the hello world module when logged in. The login process could be done automatically on the frontend. Or after a simple captcha to add one very basic layer of security. Assigning the "public" role to the guest user does work, but visiting the processmodule does redirect the user to the login-screen. I'm not sure about the security of this approach, though. What do you think @Robin S @BitPoet @tpr ? For example, the PW version is displayed in the footer. This could easily be fixed, but also config data is sent to the client via the ProcessWire js config object. But on the other hand, the PW access control system should be safe as it is - so if a role had only one permission assigned for a special processmodule, it should not be a security concern, right?!

OK, I'm back in the office and can share some more thoughts. Thx for your input so far. I'm talking about "no authentication whatsoever", yes. But I'm not talking about "free-for-all-editing". Of course I don't want to have public access to all my pages, that would be nonsense. But I was wondering if it could make sense to have some tools of the backend available to the public. ProcessModules are one example. Forms could be another. I'll explain the idea by examples: Shopping Cart Have you ever developed a shopping cart for one of your clients? It's not that easy, right? You have to take care of data storage (cookies or localstorage or session), you have to take care of the user interface (adding items, removing them, changing amounts etc), you have to make sure everything is safe (sanitization, csrf etc) and so on. This is a lot of work to do and we all know that our website's frontends are all different, so building this for one client would mean that you have to build a lot of this functionality over and over again for the next client. The alternate approach: What if we could build backend modules (process modules) and grant access to guest users? We could build a shopping cart module, that handles all these complicated things for us and uses built in tools, such as csrf, inputfields, routing ( executeFoo(), executeBar() ). It could have expiration features based on the session time. It could make it easy to register new user accounts. It could be And the best: It would be reusable! That's a huge benefit and could make developing several tools so much more efficient and fun (and maintainable). Also think of forms in general. They are always a pain, because they need field validation (front + backend), need to remember their state on failure etc.; This is all already there in the backend! It's just hidden behind a login and I wondered if it couldn't be a huge possibility to bring certain parts of those great featureset to the public. Similar to FormBuilder, as I already stated. Another example: Think of a kind of photo-book service. Users could visit your site, start building their photobook, upload pictures etc.; Just to try things out. It would be great to give those features to your users without any signup process and create the account afterwards. Eg. during checkout.; Or what about a theatre booking service? Display a seatmap, book tickets, show prices, etc: All a LOT to do in the frontend. If we developed a backend-oriented module where we can change colors of links, masthead etc, this would make things so much easier and it would be one click for the next project!! I hope you get my point. Until now, I didn't really think of developing such things in the backend, because I thought it would be a lot more effort to style the backend to my needs than building a new custom frontend solution. But that's totally wrong! It's now really just changing some color codes in LESS when using RockSkinUikit module. These pages could even be loaded in an iframe in the frontend. The height of this iframe could be adjusted via javascript, so the user wouldn't even see that he is actually in the backend. Tools are already there: It's just displaying the admin page with ?modal=1 GET parameter. While thinking of this approach new ideas and possibilities keep popping up in my head: We could build a forum software. It could be a set of process modules, using CKEditor, image upload etc. - but of course only EDITABLE for logged in users. But the thing is: The process-modules (read-only) part would need to be visible also for guests. Building a forum software with ProcessWire as it is (or better to say: as we use it) now, would be a pain, because every installation of PW has a different backend. Moving all parts that can (and should!) be standardized to the backend would be a logical step IMHO. Well... while writing I had another idea: Maybe it would be possible to create a new user + role for such modules, like "public-backend". When a website visitor add's a product to the shopping cart, he could be automatically logged in as user "public-backend". This user could then have access to the process modules that handle all the shopping cart features. We already have the demo-mode of the backend, so I think it should be possible in general to bring non-registered users into the backend. What do you think? Sorry, ideas and visions are quite hard to explain in another language. Did I make things clearer? ?

The site where you copied your code from uses ProCache and this https://processwire.com/blog/posts/processwire-2.6.9-core-updates-and-new-procache-version/#major-enhancements-to-html-minify-capabilities If you are new to jQuery it's worth doing some homework here: https://learn.jquery.com/ While it is not necessary to use it on your frontend, it is used in the PW backend all over, so understanding jQuery at least a little will make your life easier. Welcome on board and good luck with your first pw site ?

That's exactly what I'm talking about ?

Thx Adrian but I don't like this approach and it is not what I'm talking about. In your example the user must be logged into the admin already. If my user was logged in I would not have a problem. I want to have him use several areas of the admin without being logged in.

IT should return only published pages! I can't investigate during the next days, sorry.

Yeah, they are helpful in several situations. And they could also be tweaked for better mobile support. See https://modules.processwire.com/modules/admin-modalception/ for example. Maybe if you encounter real problems you could file an issue on github which describes the problems.