Recently Browsing 0 members
- No registered users viewing this page.
I just want to point out this framework for making html apps https://onsen.io/
it's compatible with jquery, angular, vue, react or any other js framework.
So far I made an app using this and bootstrap with https://propeller.in/
for the desing and some libs like jquery and lodash for the app logic
I prefer this to other alternatives like ionic since it does not bound you to angular or react.
I've been getting more and more into building full fledged web apps using PW as a framework. I use PW for data modeling and storage, user management, etc., and extend the Page class for different templates to add functionality to specific types of pages/data models. It is a very simple and powerful way to develop.
However, one thing that I have struggled with is finding the right way to approach page view access for users of an application (This would also apply to a password-protected area of any PW site). I'm going to try and boil this down to the most simple, common scenario, and go from there:
I am building an app where every page in the app (except for the login screen) should be password protected. Should I...
1. Turn off page view access in the template access settings for the guest user and use the settings to redirect the user to a login page.
This has the drawback that you cannot disable guest view of the home page (a built-in PW limitation that seems a bit arbitrary). You are also limited in how you can define what to do when the page is not viewable (you must use the options provided in the admin interface), and you do not have the option of continuing to load the page with an alternate view (for example, a login form). Also, sometimes it requires configuring a lot of settings for a lot of different templates. It also doesn't give you page-specific access control.
2. Leave the access settings wide open but write some code at the top of my template files, init.php, or ready.php to redirect users who are not logged in.
This has the disadvantage that it only applies if ProcessWire gets that far into the page load process, and it doesn't effect any other aspect of ProcessWire (for example, whether the page is available in a $pages->find()). If I wanted, I could allow anyone to reach any page and just show/hide the content based on the user's permissions or role. If the user doesn't have permission, I could keep them on the same page but show the login. Once they logged in, they'd be on the page they were originally looking for.
3. Write my own hook before or after Page::viewable and/or ProcessPageView::execute (or somewhere else?) to switch access on or off and redirect based on my own requirements.
This should be more reliable and secure than #2 and more flexible than #1, but it feels kind of like reinventing the wheel. Maybe the best approach is some combination of #1 and #3, with #2 reserved only for showing and hiding individual sections of a page that is already viewable.
I'd be very interested to hear how others are handling this.
The CDS Group is an established service partner of leading manufacturers and trading partners in the IT and high-tech sector. We relaunched their service website using the latest ProcessWire. Building this website was fun, especially because of the latest additions to ProcessWire, like the recently introduced markup regions and AdminThemeUIkit. It is really easy to brand the new admin theme with a few lines of code, in my case 7 (see a glimpse in the screenshot below). Besides that, this website makes heavy use of the Repeater Matrix, to be as flexibel as possible. The front-end was build with Bootstrap 3 and the icons used are an custom icon font generated with the IcoMoon App. For a better usability, every textarea can be edited in the front-end.
AdminThemeUIkit Front-End Page Editor Repeater Matrix ProCache Markup Sitemap XML Email Obfuscation (EMO) Database Backups Jumplinks Tracy Debugger Regards, Andreas
With any website, there is the possibility of db issues - overloaded server, network connectivity if the db is on another machine in the hosting network, etc.
I would love to see a feature where if there is any reason the db fails or cannot be accessed, then pw displays a dedicated page that is stored in the filesystem - instead of displaying nothing, or an ugly mysql error. Obviously it would be good to log the error, and possibly send a notification to the admin (email?).
This gives us the opportunity to still present a professional front (albeit with no functionality) while problems are resolved behind the scenes. I cannot think of a company I have worked for that hasn't had db errors at times
What are your thoughts?