Site Blog - Development (v2.0)

One of the more flexible aspects of e107 are themes, the Theme Manager of e107 V2 pre-release demonstrates more user control over layouts and styles while theme.xml allows theme creators to "preset" pages and preferred menu assignments, suggest plugins to install and recreate the layouts as they were originally designed. If that's not enough, most of that provides the ability for administrators to make on-the-fly changes at the push of a button.

Where prior versions of e107 themes use CUSTOMHEADER and CUSTOMFOOTER to apply layouts to CUSTOMPAGES, Version 2 introduces a new theme file, theme.xml, which allows the theme designer to assign pages to layouts but gives Theme Manager the ability to change those pages to different layouts or add pages to others. In theory, a site owner with a 10 page website could create an e107 theme with 10 layouts named One thru Ten and never show their visitors the same layout or graphics twice. Other related information that a designer can suggest through theme.xml are to allow administrators to install plugins that are currently available in the plugins folder and menu activations per layout so that a new site can be installed and easily matched to the preview image. "Use Preset" buttons are accessible through Menu Manager as well.

Theme Manager itself has evolved into a multi page design separating the front-end and administration themes. For front end themes with multiple layouts, the site owner can select the layout that should be used by default for unspecified pages and any other layouts can accept the input of specific page names, or patterns, with the same effect as naming pages in CUSTOMPAGES of theme.php. Themes with multiple stylesheets will have them displayed and available to select as the default front-end stylesheet.

Older and custom themes can still be used though some may need modifications to function properly. Many fancy features of premium themes also require that those plugins or functions to be installed but V2 pre-release is not different from the current version in this respect. For those interested in the overall development of the latest version of e107, developers are hard at work and uploading SVN updates when they are available, please check the V2 changelog for more details.

Development of PHP scripts without a preconceived plan to manage them is asking for a headache. The goal of a framework is to make the process of writing web-based applications simpler. Due to e107 popularity, things got a bit out of hand during the development. It is time to iron some things out that slipped in during these past years. Currently the e107 devs just 'make things work' and 'make things a bit more secure', but old legacy code is still there and it's procrastinating security and performance improvements. The e107 devs see a need to get rid of old procedural code and provide permanent solutions for the e107 system.

An application designed around MVC is easier to manage because it is split into tiers, which allow for independent development. This promotes code re-usability by building models, which are reusable throughout the application. That is why we would like to embrace MVC and single entry point (Front Controller) in the e107 0.8 version.

What is MVC?

Model-View-Controller (MVC) is a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (GUI), permitting independent development, testing and maintenance of each.

MVC is often seen in web applications where the view is the HTML or XHTML generated by the app. The history of e107 was working with classes, but not really in an MVC efficient way. Working with MVC will bring better OOP (object oriented programming) standards closer.

What's in it for you?

Applying MVC will bring you more security enhancement (possible 'sandbox-ed' environment, possibilities to implement security mechanisms on different application layers/request stages, etc).
Please note that the code producing will not take so much time. The time consuming process is the design and analysis - the code preparation phase to implement all this.

To summarize all benefits for you: a better, safer and much more flexible CMS platform, that will provide plugin writers to integrate even better in e107, with an architecture ready for future developments. The catch? Well, it might take a while; but that's an old story.

Relevant links

http://en.wikipedia.org/wiki/Model-view-controller
http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
http://www.mustap.com/phpzone_post_73_top-10-php-mvc-frameworks

Plugins can now contribute email addresses to the bulk mailout facility.

A typical example is a name and address list (separate from your list of site members).

For coders, this is achieved by adding an e_mailout.php file to your plugin directory. There are examples in the event calendar directory (which is probably about as simple as you can get, and not very useful!), and the newsletter directory. The core mailout selector is also a pseudo-plugin file in the same format, and is in e107_handlers/mailout_class.php - this is a good example of a more complex file.

For users, you can configure which plugins are active - this helps keep screen complexity down. So if you don't normally want to mail your subscribers to events, just untick the box on the mailout options page.

One mostly for coders, here - and unlikely to be used frequently, if at all.

Although the log display normally shows times to the nearest second, all the system logs (admin, user, rolling) in fact store times to a greater accuracy. This will depend on the server, but at least 10-20ms resolution is likely, and microsecond resolution may be available.

The 'detailed' display option on the system logs display combines entries on all three logs, and displays time as accurately as possible. This allows you to see the precise sequence of events, and also exactly how long certain operations take.

Not sure how useful this is going to be, but if it wasn't there, we'd never know!

Mostly a tool for coders, this one. Its a separate log intended for events where you don't need a permanent record. So you can add debugging entries which write to the rolling log, for example - useful for those situations where echoing variables to the web page would cause problems.

Some anomalies detected by the core code also write to the rolling log - for example, combinations of values which shouldn't occur (and might therefore indicate a hacking attempt).

The rolling log can be enabled on the options page of the System Logs - and you can determine how long events are kept for. I find 7 days to be a good value to use - events are auto-deleted after this time, so your log won't grow for ever.

Banning users becomes quite popular sometimes. Especially on e107 websites that have a massive community, the chance on abuse is luring and inevitable. The v0.7 ways on banning were sufficient, but the devs recognized some improvements should be part of v0.8.

It is possible to create 'Ban Types'. Each Ban Type can contain an optional message that will be displayed to the banned user. Besides that it is possible to make 'internal' notes; that won't be displayed to the banned ones. Visitors can be banned on IP address, Reverse DNS, email or host address. Wild cards can be defined for any of these as well. To ban a user by user name, one can go to the users admin page. New functionality for a temporary ban has been introduced. Each Ban Type can be bound to an exclusion period, which can be set in hours, days, weeks or (of course) indefinite.

Besides the blacklist method it is also possible to white-list visitors; by doing so you can prevent certain users from being excluded to access of your website. White-listing is possible on IP address or e-mail address which are explicitly permitted.
The whitelist takes priority over the ban list - it should not be possible for an address from this list to be banned. All addresses must be manually entered. Of course a certain responsibility comes with this administrative function. It should be handled with extreme caution.

Furthermore in e107 0.8 the banlist has been extended with an interface for banlist import/export. It should become more easy to import existing banlists into your specific (starting) e107 environment. This opens the possibility for sharing community banlists, copying banlists between your sites, etc. All in all the new banlist provides some nifty features to even better protect your e107 website.

Just a quickie to start off the New Year.

You now have more choice as to how your users log in. Depending on how you set the options, they can now specify either user name or email address in the login box (how many of your users just assume the site'll accept an email address there?)

The alt_auth plugin is almost invariably the solution when you want to add users to your site by validating them against some other database. In 0.8 its had a major facelift, although some features will still be recognisable to those using the 0.7 version.

You can still validate users against various sources, including LDAP, Active Directory, eDirectory, and an alternative database - no change there, except that there are now separate menus for e107 databases and other databases.

There are two new authentication methods. The first is fairly straightforward - Radius authentication. This requires PHP's Radius extension to be loaded.

The second method is perhaps a little more difficult to follow, since it is used only when you have imported your users into the local e107 database from a 'foreign' system. The problem with importing users is often that the other system uses a different method of 'hiding' passwords - e107 uses MD5 encoding by default, some systems use SHA-1, and others use a variety of 'salted' encodings (see an earlier post for a description for this). A few systems even store passwords 'in the clear' - a jolly good reason for changing. Alt_auth can now check these passwords using a specified alternate encoding, and once validated converts them to the e107 standard. The support for other password encodings is also available when accessing external databases.

Historically alt_auth was intended to be used as a slave - the other system was the 'master' and you couldn't edit certain things (in particular, passwords) on the e107 system. You now have an option to set e107 as the 'master' system - so once a user has validated once against the other system, its not needed any more (for that particular user). That user can change things as normal on the e107, and doesn't care about the foreign system. Think of it as a pre-authorised list of potential users. New users can also sign up as normal, so potentially very flexible.

The other main addition is the ability to copy user information from the 'foreign' database into the e107 user record - both 'core' and extended user fields can be copied, and there are some conversion options which could fairly readily be extended.

Finally, setting up the connection has become easier - at the bottom of each method's setup page is a test area, where you can attempt to log on to the foreign system with a user name and password of your choice. The test feature returns a pass/fail indication, and on a successful test also shows the data which would be used to update the user information. So you can check out your settings without enabling alt_auth.

In conclusion, its not easy to test this kind of thing (and bits aren't fully tested yet); thanks to Father Barry and Cameron K for their help.

You'll be getting the idea that the userclass code has had a fair amount done to it for 0.8. It's probably not obvious from the name, but there are two ways in which permissions can 'accumulate' when using hierarchical user classes. Its important to understand the difference.

The first way we shall call 'organisational', because it mimics the typical structure of an organisation. You have the all-powerful being (CEO, Managing Director, God, or whoever) at the top, and beneath him or her a layer of managers, who have lesser managers beneath them.... This is achieved by giving the user class at the top of the tree (often Main Admins) a parent of 'No One'. Permissions then accumulate as you get higher in the tree, culminating in this 'all-powerful' class that has all the permissions of everyone below them in the tree.

The second way we shall call something else (suggestions welcome). Here the 'lowest' class is the ordinary site member, and permissions accumulate as you go down the tree. A typical use is to have different grades of membership, or memberships covering different specialities.

Another little feature is the idea of a 'group' userclass - quite simply a class which 'contains' a number of other user classes. For example, if you have a userclass to represent each country, you may wish to have a group for Europe, a group for Asia...

For those who like to see what happens under the hood, log in as main admin (on a 0.8 site, naturally), go to the user class admin pages, and manually specify the page yoursite/e107_admin/userclass2.php?debug. This will show you the tree, including the class numbers used, class numbers below each class in the tree, accumulated permissions and so on. It also lists the first 10 users with their 'raw' permissions, and the class permissions they acquire due to the hierarchy.

Wish I was there

The 1st (? maybe) e107 Developers Conference is happening now.

OK, so headline hitting stuff over, Cameron has ventured in to Europe and landed on the doorstep of SecretR. No more typing, they can discard keyboards and speak to each other.
I don't know if this is a first amongst e107 devs, but it is in my short involvement. And here's to more of this sort of thing for e107 generally.