bernhard

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.

Hi everybody, just came up with an idea of a new concept how we could develop our processwire pages... As some of you might know I've developed this module to skin your backend fast and easily: Why? Because several things are a lot quicker and easier to achieve in the backend then rebuilding such admin-tasks in the frontend: User login, profile editing, data presentation with access control. For example, right now I'm building a kind of dashboard for a client where users can book slots for therapies, manage their profile and data etc. This is all done in the backend and users get access after registration. So far, so good... I really like this concept, because modules are clean and especially reusable. There is a standard for how we develop things in the backend. Everything works the same, on every project, on every installation, from any developer. Today I thought: Wouldn't it be great to have those benefits also for several FRONTEND things? Or, in other words, for several parts that need to be available for PUBLIC users (guests)? For example, we could build a shopping cart checkout easily with the tools we already have in the backend. There are several hosted shopping-cart services where you get a hostet checkout-page that does also look a little different than the website's frontend, so I think this would not be a problem for certain tasks (https://foxy-demo.foxycart.com/checkout) The only problem is, that the user would have to register before it could use those tools. So I thought: Is there a possibility to make some areas of the backend available to the public? Is this a good idea at all? Or are we opening security holes there? Isn't FormBuilder doing something similar with the iframe-embed method? This is just an early stage idea, but I'd be happy to hear your thoughts on this. As much as I like ProcessWire, I don't like that I have to build lots of things for the frontend over and over again...

That's why I don't like modals and always use panels. They are not perfect, but a little better, because the take the whole screen height. But there is room for improvement in this regard, I agree.

Such a script could be a nice troubleshooter for beginners if it were included in the backend somewhere - maybe worth a PR? ? It could be a simple InputfieldMarkup where the Locale translation happens.

I don't think so...

?

If possible it would be nice if the feed had a structure like shown here: https://processwire.com/talk/topic/20649-revamped-modules-install-interface/?do=findComment&comment=178910 Then I could use it directly as datasource for my RockGrids without further manipulation of the data.

Hi @flydev Funny thing, I haven't used this module for a while, but started using/needing it again yesterday. I saw that there is lots of room for improvement, but unfortunately I have some tough deadlines and can't work on it at the moment. I've just pushed an update with v6.2.2 of handsontable - it seems to work so far. Please report back if you encounter any problems.

Are you talking about an overview page that lists all children or are you talking about a single page view of one of the child pages? Maybe you can provide more code and not only the sinppets? The forum has a spoiler feature (the eye symbol) where you put all code without messing the post too much.

Don't want to discredit your work, but maybe a note/link in the first post of this topic would make sense? Not saying that people should use "my" way, but it might make sense to mention it there so that they can make an educated decision ?