Joomla news about Digital Peak

As user management we are using Joomla's user manager. We organize the users in the groups we needed with different access levels and so on.

To have custom fields for the users, we installed DPFields. Like that we can create as many custom fields we need for our users. More documentation about DPFields can be found here. These custom fields can then be edited by the user itself on the front when editing his/her profile information. Through the permission levels we can also control who can edit the values of the custom fields. This was not possible with Community Builder as they don't use the Joomla's ACL features.

As we have only a menu item type to show a list of contacts and not users, we need to create for every user a contact. There is a Joomla core plugin Contactcreator which creates for every new user a contact automatically in specific category, we could use that one for sync. By commenting out that line the plugin created a new contact for the updates also. As we had to manually update every user by hand to move the custom fields data from community builder to DPFields, contacts were created for the existing users.

To create the member list for the front, we created a contacts category menu item. To have the list with the fields we need from the user including the custom fields, a template override was needed. Template overrides let the admin to adapt the views to their needs, more information can be found in the official Joomla documentation. In our case we had to copy the file components/com_contact/views/category/tmpl/default_items.php to templates/{template}/html/com_contact/category/default_items.php.

To put the custom fields into the list, we used the following code snippet:

JDispatcher::getInstance()->trigger('onContentPrepare', array ('com_users.user', &$user, &$item->params, 0));
foreach ($user->dpfields as $field)
{
	if ($field->note != 'front')
	{
		continue;
	}
	echo '<br/>' . $field->value;
}

The if condition allows us to display only the fields which have as not value "front" on the member list site. With some more code changes we got a stripped list and nice avatars. How we implemented avatars will be explained later.

For the contact details page, we used again a template override and some configuration options from the contacts manager. Like that you can control if the contact form should be displayed or not, to let the visitors get in touch with the members.

To adjust the details page, we had to create a template override for that file components/com_contact/views/contact/tmpl/default_address.php by copying it to templates/{template}/html/com_contact/contact/default_address.php. On the top of the file after the first doc block, we put the following code to display the custom fields:

$user = JFactory::getUser($this->item->user_id);
$user->text = '';
$dispatcher = JDispatcher::getInstance();
$dispatcher->trigger('onContentPrepare', array ('com_users.user', &$user, &$this->item->params, 0));
$output = $dispatcher->trigger('onContentBeforeDisplay', array('com_users.user', &$user, &$this->item->params, 0));
foreach ($output as $content)
{
	echo $content;
}

The avatar field is somehow special as we had to do some quirks to get it properly working. We created a Media field and set the Home parameter to yes. With that parameter the media manager is loading to a folder with the user name of the current logged in user. When a member is editing his avatar on the front, then he/she sees only his/her folder and not the rest.

With the following CSS code snippet, the folder selection is hidden for the member:

#imageForm .span12.control-group
{
    display:none
}

 It is not the securest way, but it is enough for our members as we need to prevent them from changing the folders because of inexperience and not abuse.

As most of the members upload images with different sizes as their avatars with used again some CSS magic to make them look equal and nice. The object-fit CSS command helps in that case. If you give the avatar field the avatar image class then you can use the following CSS piece of code that the avatars will look like in our screenshots on this page:

.contact-category .avatar {
	height:100px;
	width:100px;
	vertical-align: top;
	object-fit: cover;
	border-radius:50%
}

 To get the avatar as image in our template, you can use the following code:

if (!isset($user->dpfields))
{
	$user->text = '';
	JDispatcher::getInstance()->trigger('onContentPrepare', array('com_users.user', &$user, &$user->params, 0));
}

if (isset($user->dpfields))
{
	foreach ($user->dpfields as $field)
	{
		if ($field->alias != 'avatar')
		{
			continue;
		}
		echo '<a href="' . JRoute::_('index.php?option=com_users&view=profile') . '">';
		echo '<img src="' . $field->rawvalue . '" width="32" alt="' . htmlentities($user->name) . '"/></a>';
	}
}

Despite the fact that Joomla is based on Bootstrap 2, more and more templates are shipped with Bootstrap 3. This makes sense as BS2 is end of life and BS3 is nowadays the state of the art. DPCalendar was working properly with BS 3 since the beginning but 100% compatibility was never guaranteed. In DPCalendar 5.5 we added the missing classes for the bs3 grids and changed the default settings of the modal popup to Joomla, to not conflict with the BS3 modals anymore. We tested to implementation with some of the most common BS3 templates like Purity III from JoomlArt. Let us know if it works with your BS3 template as well.

A long outstanding feature of DPCalendar, the Joomla event manager, to have multiple prices per event, got finally implemented. You can define per event as many prices you want. Per price you can define the label and a description. These information will be shown on the event details page.

If the visitor wants to book tickets for the event, then an amount of tickets per price type can be selected. If there are tickets already booked for an event, then the pricing values can't be changed anymore.

To offer some discount for visitors who book early, the site admin can define unlimited early bird discounts. For every discount a value, type and date must be set. The value defines the amount of discount. The type if the value should reduce the price as fixed value or percentage of the original price. The date specifies till when the discount is valid. The date can be relative to the event date or absolute.

The biggest change in the booking part is to set an end date where no more bookings are allowed. This date can be set in the event settings and can be an absolute or relative date to the start date of the event. Further changes are that the event limit is now globally per user or mail address. This means a person can not book on the second booking more tickets when the limit is already reached on the first booking.

When the event changes, the ticket holders will get notified about the changes. It is also possible now to download the invoices and tickets in the back end. They can also be resent.

A check can be activated in the DPCalendar options when editing an event if it should be checked if there is already an event in that time frame. A warning will then be displayed above the input controls.

The CSV plugin got a bunch of new settings. Per CSV file the admin can define now which column represents the field of the event. Additionally the delimiter and the enclosure can be set.