Thanks Thiousi!
Here is some of how it’s set up (with some changes to make it clearer):
Model (as in MVC)
In the content folder I created a page named “app”. Within that page I created sub-pages for each model. So my folder structure looks like:
content/app/user
content/app/book
All of those pages are empty and simply are to allow me to create Kirby models for them:
site/models/user.php
site/models/book.php
Kirby models can be treated like any PHP class so within them I have typical CRUD functions, like:
// site/models/user.php
class UserPage extends Page {
public function create() {
$error = false;
$messages = array();
try {
$user = site()->users()->create(array(
'username' => get('username'),
'email' => get('email'),
'password' => get('password'),
'language' => 'en',
'role' => ‘customer’
} catch(Exception $e) {
$error = true;
$messages[] = 'The user could not be created. ' . $e->getMessage();
}
return compact('error', 'messages'); // Explained below in "Linking them all together"
}
}
Notes:
I have a model called “user” but unlike in traditional MVC where the model properties (e.g., username, email, password) are defined in the model, my “user” model is just an abstraction of Kirby’s user object and as such I let Kirby handle those property definitions.
Not having to create a user management system from scratch (especially considering security) was one of the reasons I went with Kirby instead of Laravel or Rails.
As a result it’s very simple:
- A user submits a POST request to /signup: tell Kirby to create user account.
- A user submits a POST request to /login: tell Kirby to validate username and password and login.
- A user submits a GET request to /logout: check if user is logged in, then tell Kirby to log the user out.
(All these functions are explained in the Cheatsheet.)
View (as in MVC)
Views are no different than normal pages. So for creating a user, I have this page: content/signup and its accompanying template in: site/templates/signup.php
Controller (as in MVC)
My MVC paradigm gets a little confused here, but my controllers’ responsibilities are mostly redirecting users away from pages they shouldn’t have access to.
For example, if a non-logged in user tries to access the /profile page, he or she will be redirected to the /login page.
Linking them all together
I created a plugin titled “API”. The whole plugin consists of a list of routes to perform CRUD operations on the models. For example:
// site/plugins/api/api.php
kirby()->routes(
array(
array(
'pattern' => 'signup',
'method' => 'POST',
'action' => function() {
$user = page('app/user');
$data = $user->create();
if ($data['error']) {
return array('signup', array('error' => $data['error'], 'messages' => $data['messages']);
} else {
go('profile');
}
}
)
);
Notes:
- Route is only called by a POST request (i.e. the user submits a form on the signup page).
- $data contains the response of the user model. If an error occurs, then the signup page is shown again and the error message passed in as a template variable. Errors are shown in the signup template like:
<?php if (isset($error)): ?>
<div class="errors">
<?php foreach ($messages as $message): ?>
<?php echo $message ?><br>
<?php endforeach ?>
</div>
<?php endif ?>
In conclusion
That’s a simplified explanation but hopefully it somewhat shows how easy it is. So to answer your question, the panel is only used by and accessible to me, while all users use the frontend. Let me know if you’d like to know anything else.