Reuse admin interface in frontend?

Question

I was wondering what would be best practice, in terms of performance and code reuse, for the following:

I've got a plugin admin area almost all writen and usable in admin area, but i want to give some users change and editing options for database table data, that is also changeable from the admin area.
So, what would be the best practice: Reuse (how, if it's possible to know...) the admin code that allows users to edit data WITHOUT entering the admin area (which they would never be allowed), or rewrite all the code again for those frontend editing area?

Has anyone tryed this before?

Thank you all...

Comments

Out of curiosity, why don't you want to them to enter the admin area? With admin permissions you can strictly control what each administrator can access in the admin area, so you could configure it in such a way that they only can access your plugin (or parts of it even).

---

Need to mention it : creepy... to allow an amount of users to get such in hands...
Dbase changes.. ? when something disrupts the system? who can restore.
Also it depends of exactly what could be changed (example : V1 theming,  Alf ? (e107 italy) had such things incorporated to change theme behaviour) something like that?
All in all it comes to > who may > what when troubles arise (trustworthiness)...
Plugin :  (imo) 2 points of access to admin in total, (shielding) ?
I do not believe someone already tried that, but than again some plugins were quite 'in' to system.. AOI by TheMadMonk or OIM ?

---

@Moc

For instance, i can set "Contributors" allowed to change or correct bits of data, but not allow them to be "Admins", got the point?

---

@rica-carv I don't get the point yet. By setting admin permissions, you are able to allow them to only change or correct bits of data, and at the same time prevent that they can do anything else. The only thing they can do is change that what you allow them to change.

I don't understand what the downside is of setting them as admins and giving them specific permissions so they can only change that data.

---

@Moc Well, i can't figure out how can i set permissions to specific users to only certain areas of admin interface, if that's what you're talking about.
For instance, is it possible for a user to have admin right ONLY to the admin area of forum, for instance, and another to the admin area of downloads, both without acces to all the other admin areas??
How can that be done?
I don't see how....
 

Ok, i see what you mean, but that's not quite exactly what i want.
For instance, we can only allow a member to have access at plugin level, and nothing more.
So, if i give a usr access to a plugin, he can do anything! From messing with the database to poke around with plugin settings!
And i only want to give him access to the data, not the settings!!!!

Therefore i want tou reuse part of the admin code interface in the front end. Not all, just the editing part....
Just to avoid to duplicate code.....
 

My aim is that i want to give a "colaborator" user editing rights only over a certain plugin, ie, it would be possible for him to edit data from the database for that plugin, but from the frontend, without any need to go to the admin area...... because i don't see how can i limit areas friom the admin interface to specific users..... maybe i'm missing something here....

---

And i only want to give him access to the data, not the settings!!!!

I am pretty sure this is possible as well.  For example this code within the Admin UI allows to set 'perm' for a specific section of you plugin (for example "manage" or "preferences" in this case: https://gist.github.com/Moc/904ac04332791f601d373553a2b9be9e  

I just need to dive into the code (as I am also working on writing up developer documentation for this), to figure out what values you can use here. 
 

Answer 1

To let users/clients to the admin area is not a solution, mainly because you don't have control over the admin theme and over functionality there.

My attempts:

- maybe 4 years ago, in fact, it was lonalore doing, he copied e_admin to the plugin as e_frontend (not remember correctly) class and he was able to use it frontend. If I remember correctly, there was e_frontend class in core then.

- maybe 2 years ago, tested with CaMeRon frontend using of Admin UI. It worked then.. Something was needed, using a different header/footer, fix loading some css/js...  and maybe parameter ":raw" and echo...  I still have access to that site, I could look, if it is needed. But Admin UI should be worked on the frontend, if not, it is a bug. And I think there is a closed issue about this from that time. It was a site with 3 levels on frontend editing... and it worked at that time.

- maybe a year ago... used an admin solution from efiction CMS as e107 plugin, wow, it was something, the logic behind admin levels, settings capabilities and visibility... I just haven't get time for this and we decided to stay with UnNuke, so it wasn't needed anymore.

- actually, in the process, I am moving all admin functionality to the plugin. I got it working, but now I need to replace admin shortcodes with plugin shortcodes because they work only if ADMIN is true, strip it not needed code, and solve save access. But it had to be postponed because... as you can see... there are too many changes in the core now and the themes got priority.  It should be called the client zone. In meantime, the client decided to use WordPress solution for this...    And if I remember correctly, the challenge here was rendering admin menu (without manually written code).

By the way, with OIM plugin user needs access to admin area too.

So use Admin UI on the frontend, set correct permissions, check correct queries etc, it should work.  If not, move this topic to Github.

Comments

I just needed it. Table with sorting and filtering. It almost works. Problem is that everything is available to guests... Inline editing, batch edit, options...

---

@jimako
My aim was to reuse the admin php file code in the front end, with all those issues, it seems that it needs to be duplicated and rewrited for frontend reuse, precissselly what i wanted to avoid....
It's a waste of time and duplicated code, and if you change anything in the admin area code, you need not to forget to change in th frontend code...
That admin area code should be reusable, just like php traits or methods.... i think....

 

Right now, it's a heavy job to make a admin area code, and currently i'm strugling with the code to make some fancy stuff in admin area (double inline inputs, buttons inside form, etc.) without writing plain html.
Until now i managed to do what i want with some "hack & slash", but it takes a lot of time to scavenge through code.....