Site Blog

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.

In common with many other systems, E107 currently stores passwords as an 'MD5 hash'. This is a 'one-way' encoding which makes it difficult to recover the original password, or one which will also work. For many systems this is perfectly adequate.

Needless to say, if you can recover the 'hash', it is possible to 'crack' these passwords given enough time and computing power. You can use the 'dictionary' approach, which works if the user has chosen a normal word for their password. Or you can use 'rainbow tables' (http://en.wikipedia.org/wiki/Rainbow_tables) - in principle, for each possible hash value you precalculate a value which will work as a password. This is a one-off operation. Cracking passwords then becomes a simple matter of looking up the hash in the rainbow table - much faster than doing lots of calculations.

0.8 gives an option to improve security by using a 'salt'. This salt (which is a text string) is combined with the entered password prior to calculating the hash function. The salt is different for each user, and is 'public' information (in that it is stored 'in clear' in the database).

This makes password cracking, especially bulk password cracking, much harder, since its no longer possible to use a standard rainbow table. Its necessary to calculate the rainbow table for each password you want to crack, which greatly increases the computing effort needed. So still crackable, but much harder to do. So hopefully any hacker will go and annoy someone else.

Salted passwords aren't needed by everyone - they do complicate password management in a number of ways. The option is there if you need it.

Sometimes you want to restrict or monitor the activities of a new user. You can do just that with the 'New User' class, which is one of the 'core' classes.

To activate it, set the 'New user probationary period' on the user admin options page.

Once set, all newly signed up users are automatically assigned membership of this class.
The 'new user' status is cleared the first time the user logs in after the probationary period has expired.

How you make use of this information is up to you - it may be as simple as doing more detailed monitoring of user activity.
Its another option available to plugin writers, too - you may give admins the option to restrict features to members of this class (which is named 'e_UC_NEWUSER')

A new core plugin has been added to the 0.8 development tree: the tagwords plugin, which you can see in action right here! Just look on the right side and you'll the tagwords menu (which leads you to the full tagwords page as well).
The Tagwords plugin allows you to add tags to item you create. Currently tagwords has been added to news, content, links_page, download and calendar_menu. A form field will be present in the admin pages when creating or editing and item. This has been achieved through the use of the Triggerhook event as described in another post. you can install the plugin through the plugin manager page in your admin area. The admin page of the tagwords plugin has some preferences. These won't be discussed here, but will (in time) be added to the wiki.

A plugin that wants to allow for tagwords to be added needs to have the following requirements:
- first of all it needs to have a correct implementation of the TriggerHook event feature (for more detail see the post on it)
- secondly, it needs to have an e_tagwords.php file in the root of the plugin folder. The e_tagwords.php file consists of a class named 'e_tagwords_myplugin' (in which myplugin needs to be replaced with the real name of the plugin) and two mandatory methods getLink and getRecord (See the core parts mentioned for more detailed examples).

Besides the Tagwords plugin page which displays all tagwords, you can display the tagwords belonging to an item with the item itself as well (eg. beneath a news item). While this has not been added to all core parts by default, the implementation is not too hard. There is a global shortcode within the tagwords plugin you can use to retrieve the specific tagwords for the item. You can do so by using the following call (of course you need to correctly set the myplugintable and myitemid variables):

of course you can also use the shortcode within your own templates like so:

This will return a list of tagwords belonging to the item in question.

During the process of improving e107 we wanted to create a way to hook into existing pages.
We needed a way to let plugins hook into admin form screens, like create and edit pages of a news item for instance). Further, not only did we need form elements, also the handling of the save, update and delete statements needed to be addressed accordingly. We've developed the TriggerHook event for this purpose. If a plugin has this feature implemented, it allows for hooked-in events as described above.

A plugin that wants to add form elements to other plugins can do so by adding an e_event.php file in the root of the plugin folder.
This e_event.php file consists of a class with the naming convention 'e_event_myplugin' (in which myplugin is the name of your plugin). The class contains (a constructor and) four methods (form, create, update, delete) with the naming convention 'event_mymethod' (in which the mymethod is one of the four methods listed). Not all four methods are mandatory, but in most cases they should all be present.

The TriggerHook feature has already been implemented into several core parts. News, content, links_page, download and calendar_menu currently support it. So any plugin could potentially hook into any of those core parts!

There is currently one core implementation of the usage of the Triggerhook feature within a plugin: the new TagWords plugin.

While it made sense to implement the Triggerhook event feature into the tagwords plugin, other (new) plugins could use it just as well. Think about a geo plugin that lets you add longitude/latitude coordinates for each news item or content item just to name an example. Any plugin for that matter that wants to interact with other plugins could make use of it in a simple, clean and powerful way.

Ever needed some basic site access stats - pages viewed, render time, maybe user info? Or an analysis of how consistent your server/host is?

0.8 has a simple option to give this.

Under 'Preferences, Advanced' simply enable 'Log all page accesses'

This creates a text file in CSV (comma separated variable) format in the e107_files/logs directory. One file per day.

At present information logged is: time/date, IP, page+query, render time, DB time, query count, memory use.

You can then import these files into a spreadsheet for further analysis in any way you choose.

This feature has been in the SVN repository for a while now, but it's one of those things that only a site admin can love - users won't really know any difference. Still, I think it's one of my favorite new features so far so I thought I'd give it a bit of publicity.

So, pre-v0.8 you could assign users to user classes to give them access to areas of your site. This was all well and good but it's tiresome when you have lots of areas that you want a slightly different group of people to access. You would need a user class for each area and then you'd need to assign the users to those classes - yawn!

v0.8 has improved on this 10? 20? 100? fold by introducing a hierarchy to the user class system. So, if you, as a site admin, take a bit of time up front and plan your user classes you can make your life a lot easier (and spend more time on adding that content you know you so need to add, if only you had the time ). Simply put, a user class can now have a parent and members of a user class with a parent inherit all the permissions and privileges that the parent has.

Now, I'm no gamer, but it's a common request that I see in the e107 forums that admins want to be able to assign clan roles as user classes and have clan members, clan leaders, clan bosses and clan wives (for all I know!) with similar but ever increasing in power (obviously the wives have the most power!). And this is what you will now be able to do from v0.8 onwards.

The screen shot shows an example user class list as you would see it in the admin pages and is taken from the list of new features in v0.8 in the e107 wiki.

As a consequence of this change, other parts of the core have changed where you get to select user classes. Not all are as nicely formatted in a tree structure like this, but that's because it's not always needed. We've tried to make sure that a representation of the hierarchy is shown where it makes sense, though - such as when you can select multiple user classes).

I'd also like to take credit for this change, but I think the only credit I might be able to squeeze out of this is having the idea in the first place (along with a multitude of other users) way back before 0.8 was even a SVN twig.

I hope you will get as much benefit from this feature as I'm expecting to.

P.S. Take a look at the user class names in the screen shot - now, if you know your e107 devs well enough you should be able to guess who created that particular example. No cheating by looking at the wiki page's history, though

At some point the world is going to run out of IP addresses. Depending who you believe, this could happen as soon as next year, or it could take a little longer.There's already a solution, known as IPV6 (the existing one is IPV4). http://en.wikipedia.org/wiki/IPV6 tells you more.

As an e107 user, you're unlikely to see much difference, except that IP addresses won't always be in the familiar 192.168.54.34 format - they'll be much longer! In the worst case they could look like this:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

but can typically be shortened a bit:

2001:db8:85a3::8a2e:370:7334

An address of the form ::ffff:0c22:384e is an IPV4 address mapped to IPV6 notation.

The most obvious effect of this on users is that IP addresses are going to be much longer than previously, which could mess up display (and, initially, maybe cause confusion). On 0.7 many of the storage spaces aren't big enough to hold a full IPV6 address, which could lead to partial addresses being stored.

0.8 is, of course, IPV6 ready - all core (and core plugin) database fields have been sized to hold a complete IPV6 address.

From the programmer's or themer's perspective, there are a few points to bear in mind:

• Displayed strings will obviously be longer, so page layouts may need to be adjusted to take account of this.
• Database fields may need to be extended - the 'new' requirement is 45 characters. IP addresses are stored in a 'normalised' form as per this example:
  
  2001:0db8:85a3:0000:0000:8a2e:0370:7334
  
  While the colons are not, strictly, necessary, they do assist with readability.
  (Its necessary to have a standard storage form to facilitate comparisons. IPV4 addresses are stored in their IPV6 format).
• When reading the current IP address, $e107->getip() already returns it in normalised form. (and you can use $e107->ipEncode() to format other IP addresses).
• IP addresses should be passed through the $e107->ipDecode() routine prior to display - this converts it into a minimum length string, and returns IPV4-format addresses where appropriate.

At this stage few people have access to systems using IPV6 for real (I certainly don't) so there's no real test platform yet. No doubt there will be a few things to tweak as IPV6 catches on - at least e107 is ready.