Anyone thought about ditching the admin area yet?

[Mathew Lenning]

I was just working on my component and wondering if anyone has considered unifying the front & back ends? It seems that a lot of complexity and duplication comes from having them separated. I understand that is part of the whole mambo legacy, but is it really nessecary anymore?

Unifying them would simplify a lot of the classes and bring all of the backend functionality to the front-end (which most components are doing the hard way. It would also simplify installation packages and remove the need for mirror MVC/Language/helper files.

If this has already been discussed please forgive my ignorance, I only stumbled upon the mailing lists after the 3.0 release.

If it hasn't been discussed yet, then this could be a good opportunity to consider the possibility.

Looking forward to hearing everyone's opinions.

[John McBade]

Mathew,

Yes, I have seen it discussed here and I would agree that it is a worthy notion that a clear case can be made for.

Welcome to the group, (from another new guy),

-John

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
> To post to this group, send an email to joomla-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Alonzo Turner]

This issue has been discussed before and usually, people are on your side of the argument. I could not disagree more. While I think there is room for change, I do not want front end administration. My clients have always been confused by the front end editing options. The front-end back-end UI is a fairly common paradigm and is used by lots of different online services and software packages.

So, that's just throwing out my two cents.

Thanks, Alonzo.

[Mark Dexter]

I think the best answer to this issue is web services. If we can use a
web services api for all admin tasks, then it becomes pretty easy to
access the api from anywhere you need to. For example, you could
access the same admin task from a phone app, a front end screen, or a
back end screen. The heavy lifting is done behind the scenes the exact
same way in all cases. The only difference is the way the API calls
are created.

Does that make sense? If so, we need people to help with the web
services project. See
http://docs.joomla.org/Web_Services_Working_Group to get started. Mark

[kisswebdesign]

@mark, that makes good sense - many ways of achieving the same thing without duplication of the 'heavy lifting' code.

I will have a look at the Web services project this week(time permitting), and see if there is something I can help with.

[Mathew Lenning]

@Alonzo 

I agree that the current state of front-end editing is for lack of a better word "painful", but I also believe that the reason is because the front and back are divided, so what we end up with in the front end is makeshift/ hacky administration functions which are more of an after thought than a main feature. From a technical stand point merging the front and back-ends doesn't have to mean the end of "admin panels", since the new template system allows us to use different templates for different menu items, it would be entirely possible to rebuild the admin panel exactly as it is in the front-end if the application was unified and functionality boundaries removed.

The major benefits with a unified application would include things like not having to log in twice in order to edit your site, bringing full ACL to the front-end without having to hack it into ones components, Removal of duplication and routing logic and simplify almost every aspect of component development. Another benefit would be that the learning curve for Joomla development would be significantly reduced meaning that more people could join the fun.

Of course the majority of those benefits really only concern the 3rd party component developers, but I think the benefits to the community would also be profound. 

From the stand point of the end-user, less complication means stability (less code = less bugs), more features ( if developers don't have to think about front-end + back-end, We are free to think about front-end + "INSERT COOL NEW FEATURE HERE".)

From the stand point of the project, less complication means improved code coverage (less code = less unit tests required), few bug/security patches delivered quicker, more cognitive space to think about the future.

  

@Mark

I agree that RESTful is the first step in making a unified application. I'm still trying to figure out git, but I'd love to be part of the solution. 

I'll work through the wiki to get up to speed. 

[Matt Thomas]

Isn't this topic essentially points 8 and 9 of the roadmap (
http://developer.joomla.org/cms/roadmap.html) ?

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

--

[wdburgdorf]

No, please don't! After a very bad experience with a component (LOGOS) early last year, I thought about ditching Joomla (yes, so much frustration with that single component ...). I spent several weeks with Drupal, and there were many things I liked about it. The "missing" admin backend was not one of them. Not a problem at first, but eventually it became a real issue. For example, it was not possible to switch the frontend language without switching the backend language at the same time. I did not see how the unified interface made life easier for clients (or for me). If I as the developer have a hard time being confused by the interface, how well will a client get along?

With Joomla it has happened to me that I "killed" the backend (ACL settings error, etc.). No problem for the frontend, site keeps running, great! I'm happy with the backend looking and working in exactly the same way on all of my sites (well, a bit of a difference between 1.5/2.5/3.x ...), while being able to customize the backend without affecting the frontend at all.

Surely frontend editing can be improved without getting rid of the backend. (None of my clients ever had any complaints about the frontend editing, though.)

Of course it has some benefits to unify front- and backend, and you surely had good reasons to add it to the roadmap. I'm just worried that those benefits will not compensate for the problems ...

But if you really need to do it, please do it better than Drupal! (Well, maybe/probably Drupal 8 is already better than 7 ...)

[Ove]

Guess so Matt.

Quote: " 9. Unified Site Administration ..... All administrative
functions will progressively be moved to new frontend control panels and
landing pages"

What's the difference? If you call it Control Panel or Backend
Administration is not the deal. Most of coding for a little more complex
extension is done for the administrators. I guess the most important
thing for an adminsitrator is to allways see a unified User Interface
for all extensions. As there is a quasi standard template used in the
backend you can find most of the menus, buttons ... where you expect
them to appear. There are some differences how components appear. Some
of those depending on being backward compatible. with the same code.

i.e. you still need different views for an extension administrator and
an extension editor (to avoid a very complex ouput switching). Let the
"Site" be designed but not the "Administration"
More reuse of code is of course welcome.

Another thing in handling: Someone mentioned language swiching. Yes this
is a good example why two sessions are useful. Another is adding Guest
Content. You would have to log out to see it. Tell an administrator to
use two different browsers? And what about security? You have an
administrator session lifetime, in frontend you can be logged in
forever. But there are advantages with a single log in!

My small thoughts.
Regards
Ove

[piotr_cz]

+1.
IMHO some things may be merged in together (Models, Controllers), some
should stay separate (Views, Application).

I this is possible already, frontend part of com_content is already
utilizing some admin models for editing:
https://github.com/joomla/joomla-cms/blob/master/components/com_content/controller.php#L26

frontend com_media is loading complete admin component:
https://github.com/joomla/joomla-cms/blob/master/components/com_media/media.php

[John McBade]

Ove,

You bring up a very important item for me! I must say up front, that ML support, and ML content management - including the ability to associate content for multiple languages is a CRUCIAL core feature for me. It is the MAIN reason we as an organization (here in Japan), still use Joomla today. If this is broken, it's a deal breaker for us. It's that important. I am well aware this is crucial for people of all language groups using Joomla around the world.

Quote: "Another thing in handling: Someone mentioned language swiching."

Now I suppose this is possible to manage using a default language for the user who logs in to edit/manage ML content and associations. I like how the view tries detect the language the browser is using, and then the fallback is that the user can select another language.

So, is the idea of unifying the Front and Back ends taking into account the language switching? Is this how it will (proposed) be handled still, or is some other notion possibly in mind? Is this a detail that needs to be worked though?

Thanks,

-John

[Ove]

John,
I think you misunderstood my comment. This was about working in two different languages at the same time! Then you need two sessions. One for each language as e.g. a the language cookie is set.

[Mathew Lenning]

@ wdburgdorf,

I understand your concerns. and I agree that changing the way Joomla admin works would be a nightmare for almost all of us, but to be honest most of the concerns you've expressed are template issues. I agree that having an administration area is important, I just don't think that it should be a separate application.  I might even go so far as to argue that the ACL settings error, which killed your back-end, was a result of the excess mental strain that maintaining two instances of essentially the same concept causes. 

Using one application instance to present and administer a Joomla site shouldn't mean the Joomla administrative area has to change the way it is organized, it just means that the double standard for functionality has to be removed. 

@ Matt T, 

You are right this is already in the road map. I didn't see that document before posting this, so thank you for sharing.

@ Ove,

I think you've brought up some really good points, especially with multiple languages, but I don't think two sessions is the right answer. Already there is a simple configuration for the admin to set their own front and back end languages. Which are stored in the database, so having content and controls in different languages shouldn't be a problem, we can just change the name of back-end language to  control language and presto one session with multiple languages. 

Also the issue of security (session lifetime) is a perfect example of why the front and back should be unified. Why does the front end application sessions work different than the back end sessions? Is a session not a session. 

Now going to the guest content, forgive me if I'm mistaken, but isn't it true that "As-Is" administrators have to open two separate browser tabs in order to access the front and back ends? This is for any content whether its guest content or not. What is worse is that you have to log in twice to view any content above public access level and if the session experiences in either of these session your forced to log in again. Is it not also true that if you have your site "Offline", there is no way to see guest content at all.  So at the moment the only way to create and view guest content in the front end is to publish it for the world to see and then start fixing errors before anyone notices. Not the greatest solution in my opinion (no offense intended to any of the hard working volunteers that made it so).

When the front and back ends are unified, I don't see why it wouldn't be possible to add dynamic role switching for administrative users. Imagine how awesome it would be to choose an access group from an acl drop down and then be presented with the EXACT experience users in that role would be presented with. No need to create fake user accounts and assign them to the appropriate roles then log in under each of their accounts to see how the site works or doesn't work for them. No need to publish to the world before you can see if your guest content is ready for the world. 

@ John

+100 for Japan based Joomla developers. I'm in Yamagata-ken! The crazy thing about Joomla's language implementation is there is no difference between the front and the back end besides the sys.ini which is only used in the back-end, but even if your component uses the exact same terms it requires that you have a separate front end INI and back end INI file. Unifying the front and back will eliminate the need to duplicate language files and make life easier for everyone.

@ Everyone

It is great to see everyone's opinion on this subject and I'm also excited to see that this is on the road map. Now that it is official this might be a good chance to talk about how we want to administer our Joomla sites. 

Just from the discussion to this point these are things I'd like to see.

1. Ability to have the admin controls and the content in different languages.

2. The ability to view content under different personas (guest, public, registered, etc...)

3. Real content previews (I hate having to open two browser tabs to see the results of my work)

4. Progressive enhancement from start to finish. (removing as many dependencies on JavaScript as humanly possible)

please add your thoughts to the list.

[Ove]

Mathew Lenning wrote On 06.05.2013 14:08:

> 1. Ability to have the admin controls and the content in different
> languages.
> 2. The ability to view content under different personas (guest,
> public, registered, etc...)
> 3. Real content previews (I hate having to open two browser tabs to
> see the results of my work)
> 4. Progressive enhancement from start to finish. (removing as many
> dependencies on JavaScript as humanly possible)
>

First - I'm of course pro a smother integration of the User-/Admin areas.
If your 1. - 3. could be solved without sessions it would be great.
You mentioned ini. language files. Yes it's a big issue by itself. Make
them more reusable would e.g. be to use more common strings especially
in forms. But this would be very hard work. I've seen extensions that
use a copy of the backend .ini for the frontend. Maybe you can load the
backend .ini within your fronte-end. Not tested! I'm not sure if size of
code on the server and in requests has any relevance in those days. It
changed over time from KB to MB to GB.

Sorry. want to mention this even if it has nothing directly to do with
this thread but worth to keep in mind.
I'm not a "session-specialist" so if someone with better knowledge make
thoughts on sessions : With the best regards from the IT responsibles
within the European Union - Please add functionality for opt-in to
Sessions (read Session Cookies). Without a working Plug-in Joomla! is
not conform with legislation within EU. You can find at least one
working Plug-in on the JED (a commercial one I have tested that really
blocks the session cookie and not deletes it after setting it in the
first place)
Even Google has gone the half way on european landing pages and at least
inform you about what they are doing for their living - collecting
cookies. "We take help of cookies to ... OK-button Read-More" Though
the cookies are allready set.

@ John
As I think it's important that the possibility of working with at least
2 different "settings" (now = sessions) in one browser not get lost,
I'll try to explain what you can do today.
If you are using multi language or another language than english in
frontend you can test it with languages. If not you can test it with an
Article shown only for Guest accounts. In the "Guest case" do not log in
on frontend especially not as Super Admin as he/she should "see it all"
1. Go to your backend and before you log in choose language english on
the log in page.
2. Open a new tab or window in your browser and go to your frontend.
3. Now you can work in english in backend and see your changes in frontend.
4. You can open as many tabs or windows as you like but they will be in
the same language/same user. If you for some reasons want to extend this
you have to open another browser and go through step 1. and 2 once again.

Hope this reduces your confusion.


Ove

[Nick Savov]

For learning git, check out:
http://docs.joomla.org/Git_for_Coders

and:
docs.joomla.org/Git_for_Testers_and_Trackers

It's really easy if you follow those :)

Kind regards,
Nick

[Mathew Lenning]

Dear Nic,

Sorry for the late response (working on an international exchange program at the moment)

Thanks for the link! I tried my first PR today (fail) I'll have to read that Doc a little better and try again this evening

[George Wilson]

There's a nice tutorial for a first time PR here: http://docs.joomla.org/My_first_pull_request_to_Joomla!_on_Github - see if that helps :)

Kind Regards,

George

[crocoast]

Sorry guys but i am on the same side as few of the posters, the problem i have is the security issue.  At front end i have no login modules, nowhere to take users etc, and we have even been playing around with moving /administrator to separate sub-domain to make site more secure, to have it go to something like something.domain.com and totally different virtual server environment.

To me that is for me the most important thing to look at, if you can provide some feedback and tell me how the security standpoint of unified structure would look then i might change my mind because i like the basic idea, just reality is for me different.

[Victor Drover]

great, thanks George.

-V

[Mathew Lenning]

Thanks for the link! I completed my first PR today! 

Nothing big, but I think its an improvement to the legacy controller classes.

https://github.com/joomla/joomla-cms/pull/1271