I need to put a non-admin page/view inside my admin project build using Sonata Admin Bundle. Is there a correct or standard way to integrate an independent page within the admin, make it accesible trough the dashboard or menu, and display it using the layout and all styles of the whole backend admin (including form styles)?
The only way I imagine how to do it is create a custom controller, an make the views use the same twig layout of the admin, but I think of it as a "brute force" way.
The way you stated seems the best one indeed. By taking a look at the dashboard page in the Admin, it is simply a controller rendering a template that extends the base_template of the sonata.admin.pool service.
You may then override the standard_layout.html.twig template to throughout the admin (don't forget to put it in the sonata_admin configuration as well) to customize the menus and add your link.
Related
I readed doku and search about middleware on october informations, but nothing find what me can help.
My Problem:
I created Plugin and use RainLab User Plugin for Frontend Editoring of Content.
Frontend Content spilt up on Section, Group and Article.
Single Users become different access: hiddem, show, edit and more for sections and articles.
The site works with one plugin on content load dynamic.
How i can load content for single user by access config?
My solution:
I added on backend some functions to give access for users.
rainlab user content access
All access configs saved and works.
My idee is to create middleware to load content but i find nothing what can help me.
Docu tell me you can create middleware but middleware load all time on frontend, backend, all pages on website. This is not good solution.
https://octobercms.com/docs/backend/controllers-ajax#controller-middleware
In addition comes if i debug on middleware, so rainlab user functions not working, no informations about url request.
Why add middleware when you must load and create all classes and functions by himself??
I need middleware only for frontend and only for plugin or component.
I hope somebody can me help to find another solution or idee to fix it.
I think there is nothing left but to implement the content access in respective component on onRun function. :( and problem by this solution is: return Redirect not working outside a class or function (only on onRun)
There is Problem with your approach, as you want middleware and also you want to make sure it run for specific plugins and component. middleware worked based on request and request may have information about URL etc. but not about plugin & component etc so it can not determine when to run based on plugin etc..`
So you may use Different approach. and it will work with Frontend also with ajax requests.
You can create component inside your plugin, It will assessment all the access for logged in user if user is logged in. if user is not logged in you can provide different assessment access.
Now you need to add this component to your layout and now all pages which are using this layout have this access information from the beginning.
Now this component inject access information to page, So your Page and plugin's components can have this information readily available. now from your component inside onRun you can handle redirect at very top.
Component is not to define access, its just inject predefined access information which is in database [ as you said you use users plugin so fetch it and inject it ] to the page
Component will be specifically just inject access information to page. And that Component will be on layout so. it will automatically trigger for that layout pages. so it will executed first and based on that you can decide how to use it. you can also render conditional component based on that. as you can have access information in markup part as well so
if you have any doubt or questions please comment.
Is this possible to register custom controller in sonata admin? Without any CRUD or other completely unnecessary things,
Simple form with one file uploading (no sonata upload, simple input type file).
Just create usual controller with path in admin zone ("/admin/my_uploader" for example).
You can add menu link using custom template for sonata layout.
Another solution is using ConfigureMenuEvent, this way can be better if you write reusable bundle.
I have just started YII one week back. I have made a theme in that is
\themes\yog
it is very small project, just 4-5 forms, those are mostly fro the admin. so what i want now it suppose i am using the
site/login
route, I want to render it via YII's default views . i.e
\protected\views
I want to run the default views for only some actions, like login, or adding news, event and other admin related tasks. But other actions should render the views from my new theme.
Thanks.
In that SiteController set Yii::app()->theme to a non existing theme, and it should fall back to use the views from the protected/layouts file.
If you want to specify different layout files read this: Yii: Render action using different layout than controller's layout
When you log into the Magento Admin Panel, you're only shown menu items that your role allows you to. Where in the Core does Magento check the user's role to determine which Navigation items should be shown? (I'm not interested in the _isAllowed method on Admin controllers, I'm interested in the Navigation rendering).
Also, as along as I'm here, outside of the aforementioned _isAllowed, navigation rendering, and SOAP/RPC API methods, what other parts of the Magento system rely on ACL?
Looks like Mage_Api_Model_Config and Mage_Admin_Model_Config are involved in the API and admin permissions respecively, they both have the methods
loadAclResources()
getAclAssert()
getAclPrivilegeSet()
Cheers,
JD
Found what I was looking for, but I'm still interested in other areas of the admin that use ACL resources.
Mage_Adminhtml_Block_Page_Menu::_checkAcl
I'm working on an app in CodeIgniter, and I want to have admin pages for several of the objects in the application, and I'm wondering what would be the better way to put these into an MVC structure.
Idea 1:
In each controller, have an admin function, and add all of the admin pages I would like into that function.
example URL: domain.com/articles/admin
Idea 2
Make a new admin controller, which would have to reference many different models, and put all of the admin pages in there.
example URL: domain.com/admin/articles
Which way would be better?
Edit for clarification: By admin functionality, I mean being able to do the basic CRUD actions on any object, and be able to display a list of all of said object.
Definitely a different controller at least!
I used to think that I could keep all my admin functions in a single controller, but as my programs grew, I realized that I needed multiple controllers in my administration section.
So, I created a folder inside my controllers folder with the name "admin" and put all my administrative controllers in there. So my folders would look something like:
application
controllers
front.php
welcome.php
admin
dashboard.php
useradmin.php
etc...
One problem this creates, however, is when you type http://mysite.com/admin in your browser, it returns a 404 page. So, go to your "application/config/routes.php" file and add a custom route:
$routes['admin'] = 'admin/dashboard/index';
I'll echo Justin in keeping it part of the individual controllers.
You should setup some kind of authorization system that the individual controllers can use to so who is logged in (username) and what access they have (admin/member/etc). Here's a SO thread on CodeIgniter Auth Classes.
The view would then conditionally show the appropriate links, and the controller would enforce the policy by checking the auth before passing any data to the model or rendering an edit view. On unauthorized access an error could be rendered, or simply render with the non-editing view.
This approach seems to make the most sense (at least to me) because all the functionality is stored in the individual controller. Keeping admin functions in a single admin controller means you'll have to manage two controllers (the admin, and the actual controller) every time you add somethign new (or remove something).
If you're concerned about putting auth checking in every controller, you could create a generic controller class with all the auth setup, then have your controllers extend it. In the end the individual controller auth check could be as simple as:
function edit()
{
if(!$this->auth()){
//display auth error, or forward to view page
}
}
Of course some kind of ACL implementation would make this better, but I don't believe CodeIgniter has an 'official' ACL.
It's a good idea to have an admin folder in the controllers folder wherein you can access your administration e.g. yoursite.com/admin/users.
All your administrative needs will be there and all methods will be protected by checking user privileges like so:
if ( ! $this->auth->logged_in(array('login', 'admin')))
{
$this->session->set_flashdata('message', 'You do not have access to view this page');
redirect('admin/users/login');
}
Then all controllers outside the 'admin' folder will - depending on your type of site - will only be for viewing, etc.. no administrative portions.
Idea 2 is better.
system/application/controllers/admin
You keep all your admin controllers here.
Here is an extensive guide to the pro's and con's of each method:
http://philsturgeon.co.uk/news/2009/07/Create-an-Admin-panel-with-CodeIgniter
Depending on what you mean by 'Admin' functionality...typically, this is thought of as an 'Edit' view.
And typically, you use the existing controller to serve the 'Edit' view allowing the authorized users to make the edits (in your case, Admin users only).
Looks like a personal choice, i love having everything centralized so the admin controller would be my bet.
That way i wouldn't have to open up 5 different controllers while modifying admin tasks.