[Typo3-dev] Re: The future of typo3

[Thomas Svenson]

Hi All,

I have been reading this thread with much interest. I am new to Typo3 (I'm
in the process of installing the 3.6.0 alpha/beta to test it) and I plan to
build a site with lots of member/client interactive features. Previously I
worked as technical expert (pre-sales) for a company with it's own CMS
product, so I have about 4 years experience of what customers need and how
this market has matured.

There are a couple of things in this discussion that is very interesting for
me, both for the site I'm going to build and for other reasons.

I will focus on User Management and the BE/FE debate since I believe these
are two of the cornerstones in building a usable and flexible system.
Specially the user management is very important in my experience.

Managing users
--------------
Note: With users I mean everyone with an account - including administrators,
content editors, members and so on.

In my experience it is not easy to create a user management that offer full
flexibility regarding issues such as security, detailed control of roles and
at the same time be easy to manage when you get lots of users.

Personally I prefer to have one user database (table) for all users. My main
reason for this is that it will allow much more flexibility in
administration. For example giving a FE-user rights to use the BE without
forcing them to create another user account (and yet another login/password
to remember).

Even if everyone is stored in the same table(s), it is easy to identify
certain standard roles.

For example:
  - Main Administrators (those who will have access to everything)
  - Section/Department Administrators
  - Developers
  - Content Editors
  - Members
  - Anonymous

New roles must be easy to create. It should also be possible to make one
role a member of another role. That would make it possible to divide the
roles into sub-roles that are easier to handle. For example you have the
anonymous role. This is applied for anyone who do not login to the system.
Members will then inherit it, plus then add the right a user will have as a
member. Then when you need to change the right for anonymous users it will
automatically be applied to every role that it is inherited to. This will
make it much easier to administrate than if you hade to change 5-10
different roles.

In the user table(s) it would be easy to apply filters to shorten the list
of users for the particular need. Thus even if there is 50k users and only 5
has BE rights, you would only se these 5 when managing BE users. A user
though should be able to be a member of all roles if needed.

To this I would like to see two APIs. One for the users and one for the
administrators of the site.

User API:
This will have two main purposes. It will have a user page, where the user
can manage it's settings and information stored on the site. Such as
personal details, password and so on.

It will also offer a way of plugins/extensions to hook on new settings.
Examples of this is eCommerce, newsletter subscriptions, forum settings and
so on. This would give the user one place on the site to manage their
account and at the same time provide a uniform interface.

Administration API:
This will give the administrators of sections or features (such as forums
etc) access to easily manage users and features on the site. For example a
moderator of a forum can see a list of the members in his/her forum, they
can ban users or restrict them from posting into the forum.

It would also make it easy to develop your own applications to manage users.

The basic rule should be that developers will never access the tables
direct, it should only be done through these API:s!

Both API:S above will provide two things. They will have options for the
role administration that tells who will have access to do what, and the
GUI:s for users or administrators to manage them. Note that a user very well
can be both a user and an administrator.

By using API:s it will make it easy to design the UI for the users using for
example TypoScript. It will also make it dynamic. That is you can design it
so the users only see what they have the right to see based on their role.

Question:
How well does the current system scale regarding number of users? Is it easy
to administrate if there is tens of thousands of FE users?


BackEnd/FrontEnd
----------------
I have noted in the thread that there are different opinions about if it's
best to have a BE/FE or just one integrated system. I very much favour the
BE/FE model. I agree that code/features can be shared between them. However
in the installed system they should be separate applications since they both
have separate purposes and very well could be on different servers.

For me the BE and FE have very different purposes. The BE is for
administrating the site, the FE is to provide the interface for the
visitors. As people have pointed out, the FE does not have to be a website.
It can be servers that provide access for WAP, PDA:s or even SMS.

Another reason for separating is when you have a very popular site and need
to use load balancing, thus needing to have more than one FE.

If you have a site where you sell information it would be easy to create an
FE where you customers can login and administrate their account, as well as
customize how they will retrieve the content.

Question:
How well do Typo3 scale in regards to content and traffic? Is there any
installations using load balancing and/or different FE:s for different
purposes?



In my view, the above would provide a good framework to build a flexible and
module-based system. It might also make it easier to tailor Typo3 to the
particular needs, i.e. only install what you need, but easily add/develop
new features when you need it.


I hope my view is any help in the discussion. If it will help a great
product to be even better it would please me.

/Thomas