bernhard

Thx @gottberg, glad we could find a sulution even though we couldn't find the reason for the issue ?

https://processwire.com/docs/modules/hooks/#how-can-i-add-a-new-method-via-a-hook

I've now came up with this setup which works really well for me: /site/config.php (can safely be committed to GIT) <?php if(!defined("PROCESSWIRE")) die(); /*** SITE CONFIG *************************************************************************/ $config->debug = false; $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; /*** INSTALLER CONFIG ********************************************************************/ $config->dbHost = 'localhost'; $config->dbPort = '3306'; $config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire $config->timezone = 'Europe/Vienna'; // include config file from outside of the repo include('../config.php'); ../config.php DEV (one file for all laragon hosted sites on my local machine) <?php $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER['HTTP_HOST']]; $config->debug = true; switch($_SERVER['SERVER_NAME']) { case 'www.XXX.test': $config->dbName = 'XXX'; $config->userAuthSalt = 'XXX'; $config->installed = 123456789; break; [...] } ../config.php LIVE (one file for each vhost) <?php $config->dbName = 'XXX'; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->httpHosts = ['www.XXX.com']; $config->userAuthSalt = 'XXX'; $config->installed = 123456789; setlocale(LC_ALL,'en_US.UTF-8'); Thx for that ideas @arjen and @jens.martsch!

Yes. Same here. Also on mobile it is a little annoying. Google does it like this: Ctrl+Scroll for Desktop: 2-finger-scroll for mobile:

I understand, thx for the explanation ? What program did you use for the mobile screenshots?

This issue is fixed now, but when I try to scroll down the menu further than shown on the screenshot the modal closes:

This looks absolutely brilliant! Congratulations for this great work and thanks for sharing it with us! I've also tried it on my phone and everything just worked ? One thing that was counter intuitive for me was the left arrow icon on the top left corner of the frontpage. On all other pages this icon means "back", on the frontpage there is no "back" of course, but I didn't realize that I was on the frontpage, so it might make sense to remove the icon there? Another thing: I wanted to share the app with a friend, but the share icon is only available on sub-pages.

Thx arjen! Never used field permissions because I've never needed them. Or actually I've just hooked the field and set it to locked collapsed state. I think your scenario is close to mine. The solution sounds great from a technical point of view and for the tools and settings we have. But I think it is not the way it should work! Imagine a site that manages users and invoices. That's all content, isn't it? So a content management system should be perfect tool for this job. Imagine you want to store forename, surname, email for users and you want to store net value, gross value, items and date for invoices. Processwire would be great for that, wouldn't it? Now imagine you want to show all invoices to some users, but the users should not be able to edit them. Not so easy! We have the tools for listing basic info (date, net, gross), but how could we show all details of the invoice to the user? The edit screen would be perfect. Well, if the fields were not editable there... Setting the fields themselves to read only sounds like a proper solution, but that's a lot of effort for such a simple and basic task! Imagine you had more fields! And imagine you added a new field later to the invoice template and forgot to set the field restriction... You'd have an editable field on a read only page. IMHO The fact that you've built your own custom process module for this proves that the tools we have are not enough! I just want to have a role that can see all data of invoice templates but not edit them. I think this is a fundamental hickup in the permissions we have. Or it is a missing process in the backend. Maybe we need a process that can VIEW pages in the backend if the user has view permission, even if the corresponding template file for frontend display does not exist? Not sure what the best solution would be, but it's not the ones I've used and heard so far ? I'm also happy to hear if someone disagrees. Have a great week and thanks for your opinions!

Hi @Jonathan Lahijani, this sounds really great! I'm in for collaboration on this ? @wbmnfktr the problem that I have with site profiles is that they never work the way I want them to work. The setup is usually different to how I develop pw websites on the frontend. I tried to build a frontend theme module once last autumn, but it got complicated quite quickly. So to use such a module it would be quite some effort to get started (same problems as with site profiles). Nevertheless I think that it would be great to have some kind of frontend framework. Something similar to what we already have for the backend. That makes standard tasks easier (think of $config->styles->add(...) ) and - well - more standardized (meaning reusable/shareable). I thought of developing a module for that that would basically just bring in some helper functions (like rendering style and script tags) and that can be extended via sub-modules for CSS frameworks that hold custom methods (like rendering an uikit menu, uikit slider etc). I have not started with that one, but the benefit of such a module would be that we could start with a very simple module that everybody could easily use and it could very easily be extended via pull requests (add uikit slider render method, add uikit modal method etc). And this setup would be 1-click updateable via the PW modules screen. Some kind of migrations module could do the setup of necessary fields. Site profiles don't offer this flexibility! But it sounds like Jonathan is coming up with something great here...

I'm sorry but I can't help you further than I did with this one. If you want me to have a look at your setup you can contact me via email/PM.

Sorry, no - otherwise I would of course have posted them above. Please debug it, check the console for errors, try different browsers etc.; It is working here on all my installations.

view+edit: no (not by default) delete: yes

Well, I tried to explain the problems.. and I was asking if I'm the only one having those problems, which I can't believe. Thx. Maybe this could be done. But imho pw is a framework and showing content read only to some users without having to build a custom frontend should be fundamentally built into the system. That sounds like an admin view permission would make sense. The problem with this approach (which I also took for my crm) is that it is inconsistent with how the pw permissions work. Usually you add a permission to unlock features. Without an admin view permission I'm locking down fields in the edit screen, but the page still has the editable state internally. That is simply not good. And that's why the core imho should support an additional permission that is less mighty than the edit permission. Such a permission could also make public pages in the backend possible. Which might be a good idea or not..

Hi everybody, I've asked Ryan about his opinion of a new permission that makes it possible to view pages in the backend but not edit them. This was the description of the idea/request: In short: The idea sounds interesting to him, but he is not sure if that belongs into the core as that was the first request in that direction in the last 10 years. He also mentioned "demo" mode setting as a possible solution. I've thought of that as well, but it is not possible because it deactivates all POST data and so you completely break all features that rely on POST. It's also not a great solution because it still loads all the inputfields (as editable inputfields) and not in locked mode. For example a ckeditor textarea would still load the whole editor with all it's plugins and with the scrollbar and maybe hanna code tags while it should actually load pure read-only HTML with text formatters applied. I'd love to hear your opinions about such a new permission. Have you ever wished it would exist? Is it something you have never needed in the past 10 years? Is it something you have just never thought of? I know that @Macrura is also doing a lot in the backend, so I'm especially interested in your opinion and experience with that topic. Also @BitPoet and @Robin S Finally I think that this SHOULD be part of the core. I think this situations should be a no-brainer, and of course should be maximum secure. I don't think we should mess here with hooks to adopt the system to such fundamental needs. Also we should not have to develop a module for just showing some read-only page data to our users (like a quick wiki for example). I'll collect some feedback here in this thread and then try to communicate a condensed feedback to Ryan. PS: I can remember that there has been some discussion about that already in the forum, but unfortunately I could not find the topic. Maybe someone has a link for me?

Hey @Macrura could you maybe add some screenshots or short screencasts as a little inspiration how you are using this module? ? @BitPoet thx for the module! Just tried it and it works great. Could you please consider showing all available results as default if no character is typed? At the moment it shows the "loading" animation but it seems to do nothing until you type any letter: I think it would be better if the dropdown showed "admin" or "hello_world" right from the beginning, because if users do not remember the correct word of a hanna code they could simply type [[ and choose it from the list of available options.

Wow, how could I miss that one! ? Thx

I've of course tried it in an incognito window... I'll try that next time with another installation ?

Hi @Macrura, this looks brilliant! Thx for sharing it with us ? Do you think the module could also be used for text-block suggestions like shown here? On my quick glance it seems this would need extra steps, at least for multiline textblocks?

Thx for clarifying. That doesn't work here on Win10 + Chrome ? I don't find any occurances of "favicon.ico" in the wire folder, so I guess your browser is making you see the favicon, not ProcessWire?

I agree 100% to what @wbmnfktr said! If you want to get rid of repeated task jump into module development and build reusable components that you can share. Far better than putting many sites under one hood. I know what I'm talking about - I've also done that once and regretted it lateron ? Building modules also has the benefit of being more flexible (you don't end up in all sites having the 100% same setup) and last but not least: You can share them with the community ?

Not sure if anybody is already using it... I'm using it every day and I'm extending the api from time to time. Today I added a setFieldOrder() method. Now it is quite easy to change the order of fields and set new column widths: // adjust field widths $rm->setFieldData('project', ['columnWidth'=>33], 'rockinvoice'); $rm->setFieldData('inv_date', ['columnWidth'=>33], 'rockinvoice'); $rm->setFieldData('type', ['columnWidth'=>34], 'rockinvoice'); $rm->setFieldData('invoicetomarkup', ['columnWidth'=>100], 'rockinvoice'); $rm->setFieldData('due', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldData('paid', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldData('num', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldData('sap', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldOrder([ 'type', 'invoicetomarkup', 'due', 'paid', 'num', 'sap', ], 'rockinvoice');

Sorry, don't get what you are saying... Where do we have to add the favicon.ico to be desplayed in the backend? ?

Have you had a look at PageArray.php? And in WireArray.php: Not sure if it should return a NullPage or null/false - but I guess it should be consistent... To add one more: findOne() returns "false" ?

Likely _main.php is being appended automatically: https://www.google.com/search?q=site:processwire.com+appendtemplatefile