e107help.org Q&A
0 like 0 dislike
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...
e107 version e107v2.x
in Core by (306 points) 19 37 44
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 ?

1 Answer

0 like 0 dislike
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.
by (2.0k points) 15 46 57
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...
Welcome to e107 Q&A, where you can ask questions and receive answers from other members of the e107 community.
956 questions
1,359 answers
2,365 users