It was a turbulent and amazing 2016 for DIgital Peak! We followed our mission to be part of the great Joomla eco system. With this blog post we want to highlight some of our special moments and to give a short preview into 2017.
As the Joomla community is organizing Joomladays all over the world, we didn't want to miss some in our region. We attended Joomla day Germany, J and Beyond in Barcelona and Joomla day Austria. All of these events were really amazing. We met a lot of people from the Joomla community, we just felt on a family gathering.
Here is a link to our presentations on these events.
The biggest change for DPCalendar was the revamped booking system. We made the base to easily implement new payment gateways, getting in different ways of discounts, earlybird or user group discounts. Additionally the layouts got split up to easily override single parts and not whole views.
Our ongoing effort is to support multiple frontend frameworks. In 2016 we introduced 100% compatibility with Boostrap 2 and 3. But that's only the beginning, we have big plans to support more in 2017. Beside that we invested a lot of our resources implementing small features which do make the life of the event manager more convenient. Tons of new configuration options were added to tweak the last bit out of DPCalendar.
DPCalendar is growing massively in 2016. Both in code and in extensions. As for now, we ship 27 extensions in our Premium package. Integrations of external systems like Google calendar has grown to 13 which are developed by us. There are more out there which are developed and maintained by individuals. Our eco system has grown, as more and more developers are integrating DPCalendar into their own extensions.
We invested quite some resources into the next Joomla minor version 3.7. It will contain a new custom fields feature, which is a port of DPFields into the Core CMS. Actually we are stabilizing it and fixing some UX issues. Additionally, Allon joined the new media manager team, to brush up the existing media manager for version 3.8. Development has fully started, where we will introduce some awesome new features.
As development for Joomla 4 has started as well, Allon is helping out with some coding tasks in the closer future. We love Joomla, and that's why we try to help in the core as much as we can.
DPCalendar 6.0 will come with optimized multi frontend framework support. This means, we will provide adapters for Bootstrap 2/3/4 and UIKit for our views. When there will be a need, additional adapters can be implemented with ease. The calendar view will be improved and more payment gateways will be introduced.
As already mentioned, we want to invest some resources into the active development of the core Joomla CMS, to help, making it the best CMS on the planet! We plan to help for Joomla 4 development, spicing up the new media manager and improving custom fields.
So before the year 2016 ends, we want to say THANK YOU to all our existing and new followers, without you, Digital Peak would not exist. Also a THANK YOU to the whole Joomla community. It's so great to be part of it, you make the web really special!!
Kind regards
Allon Moritz aka laoneo
Founder of Digital Peak
We all know about the great flexibility DPCalendar offers but some use cases from our users are quite special. As it was for Sven Scheidler from Ssoft-Solutions. For one of their clients they needed an enhanced notification system when guest visitors are creating events on the front end of the Joomla site. This guest blog post will describe their way with an upgrade proof solution.
DPCalendar integrates Joomla functionality as much as possible, so it makes extensively use of the Joomla event system. It is possible to hook itself into the workflow of DPCalendar with a self written Joomla plugin. The approach from Ssoft-Solutions was, to develop such a plugin and send out notifications based on various criteria.
It is possible to allow none registered users to create events on the front end of DPCalendar. Through permission settings it can be defined that these events should not be published automatically, because an admin needs to approve them first. So an admin needs to get a notification when a new event is created.
DPCalendar has already a notification system, which allows to send out notifications to user groups when events are manipulated. This is enough for most of our user base, but not for Ssoft Solutions. They need to get notifications sent to specific E-Mail addresses and not to whole user groups. Additionally, the notifications should only get out for front end events.
First thing is to disable the notification system of DPCalendar completely, no user groups should be selected in the DPCalendar options. As a second step a new Joomla content plugin was developed which contains the notification logic. This plugin hooks into the process when an event is created or edited and sends out the notifications based on the plugin settings. The plugin contains the following configuration options:
The plugin can be downloaded free of charge from here. Ssoft-Solutions will be happy to get feedback through the contact form on their site.
We would like to say tank you to Digital Peak for their great software DPCalendar!
In September 2012, the Joomla project released the new major version 3.0 of his CMS, including Bootstrap (BS) 2.3.x as frontend framework (FF) library. It was great at that time, Joomla became the first out of the box responsive CMS on the market. The problem was that bootstrap should only be used in the Protostar template on layout overrides. Instead of, the core was soaking Bootstrap up and nowadays the whole Joomla CMS code is filled with Bootstrap 2.3 markup.
Bootstrap did evolve and released some new major versions which did break backwards compatibility. Because of that, the Joomla CMS can't update within a major version to a new Bootstrap major version like BS 3. This article will explain why no upgrade can't be made, the problems with BS 3 templates and how to solve the vendor lock in.
Joomla follows semantic versioning, so we can't change in the Joomla 3 series to Bootstrap 3 or 4 because it would break backwards compatibility. The Joomla CMS needs to stick with Bootstrap 2.3, despite the fact that Bootstrap 2 is end of life since ages. Yes, we are using heavily a not maintained version of Bootstrap as frontend framework.
I'm sure that Joomla 4 would be released already if we didn't get stuck with a Bootstrap major version. Joomla's major releases are some kind bound to the Bootstrap major release cycle, which is a bad situation.
Bootstrap 3 is the most popular version (yes I know, Bootstrap 4 is on it's way) to create web sites with and has a large user base since years. For the template developers it is a selling point when their template runs on BS 3. Now we have the situation that many templates are running on BS 3. Because of the Joomla layout override system, which is great by the way, it is possible to create a template with Bootstrap 3 in Joomla 3 very easily. But the site admin who is installing a BS 3 template will face the following problems:
The Javascript code of Bootstrap 2 and 3 does not work well together on the same page. Javascript errors do happen and can break your site. Through some overloading techniques it can be prevented to load both scripts, but it will be very likely that other errors will happen.
The layouts do need to be copied to the template and adjusted to BS3. New functionality in the views are not automatically ported to the template override. Either way the site admin is doing it or the template developer ships a new release of it's template. Hopefully you didn't change the template override, because then the change got reverted during the template upgrade.
If there will pop up a security issue in a layout of the core, then the templates do need to be adjusted. Updating Joomla with the fix is not enough! The template developer needs to provide the fix to it's user. Pray that you are not using a not maintained template.
Extensions do need to support BS 2 out of the box. You as site integrator will need to find a way to make the extension work properly with BS3 then. Either way you have to create the layout overrides by hand or you are lucky and the extension is supporting BS 3 as well. It can do that by skipping Bootstrap and use a different library, then the extension does not look tightly integrated. Or it can load it's own namespaced Bootstrap CSS, both ways do bloat the site.
It will be very likely that upgrading from Joomla 3 to 4 will be a one click upgrade. This is true for the PHP code, but not for the template. You need to create a new template which works with BS 4, if it is BS2 based. If it is BS3 based, then you need to adapt all the overrides to work with Joomla 4. It's a kind of big bang upgrade, let's cross the fingers and pray that all is going good. Hopefully you don't maintain large Joomla sites, upgrade will be a pain.
Extension developers do need to support in their extensions BS2, need to find a way to work with BS3 and must be compatible with BS4. For quite some time they need to provide their extensions for Joomla 3 and 4. Either way, the extension providers will have the following options to develop their extensions:
It will be almost the same as with Joomla 2.5 and 3.
The goal must be, to isolate bootstrap related code in the core. If that happened, then we can introduce new FF libraries or their major versions much faster within the same Joomla major version. Under every circumstance, the template needs to define with which frontend framework version it want's to work with. The job of the core is to load the right layouts and views then. Good would be if there can be some kind of layout inheritance, where the framework related layout can parameterise and call the default layout. This would avoid duplicated code.
The benefit would be that we are able to introduce in Joomla 3 BS4 and deprecate BS2. The site admin can then make a copy of the template, migrate it to Bootstrap 4 and assign page by page to the new template. If all pages are done, then the upgrade to Joomla 4 will be possible without any issue. In Joomla 4 BS2 can then be removed. If BS 5 comes up, then we can easily introduce it in the core and create layouts for it.
Additionally, the transition to a new frontend framework library like foundation would be then much easier. How such a transition layer can look like is described in this RFC pull request. We made a 100% backward compatible proof of concept with a new Joomla BS3 template in Joomla 3 without any override. It describes one possible way. I'm sure there will be others, all will have their pros and cons. But now is the point to find a unified way to deal with that problem for template devs, site administrators and extension developers. The mess becomes bigger with every new major version of Bootstrap as we have a battlefield already with BS 2 and BS 3.
The problems I'm describing here are real world issues, we at Digital Peak are facing them on our daily business. Talking with site integrators, other extension developers, template devs or just Joomla users, all do suffer from the bootstrap problem in Joomla. It is up to us to provide a way to deal with this situation properly, NOW! Joomla 4 is around the corner and according to the roadmap, the last minor version where we can introduce such a transition layer will be version 3.8. So lets do a decision!
Important is that we learn from the past.
Allon did attend another great Joomladay Germany. He hold three sessions which covered development and custom fields chapters. Thanks to the organisation team for the great organisation, it was truly an inspiring event.
My first Joomla pull request slides can be found here.
The slides for the custom fields end user talk can be found here.
The slides for the custom fields developer session can be found here.
This article explains how to build a member site with Joomla core and DPFields only. For a NGO site I maintain, the board wants to display their members on the front with a simple list. We used Community Builder for quite some time, but it slowed down our site. It loads tons of javascript and CSS files and bloats the content. Additionally it had some features we will never use and the management was quite difficult for the none tech users. Finally the point where we decided to move to a more lightweight solution was, as we wanted to open registration for all visitors. It just didn't work, it always redirected to the login module after registration, but the user didn't get created. So I told myself, either way you are going to fix something you want to get rid of it anyway or look for a different solution. We decided to go with Joomla core. Users will be the user management, Contacts the front end list and DPFields will be the custom fields replacement of Community Builder.
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>';
}
}
I'm sure there are different ways to accomplish a member list site, but this was our way to get it done. Together with DPCalendar, you can spice up your events site with a complete event system where people can book workshos or other events from the different members. If you want to have a look on the live site of this article, head over to cwtach.ch/de/mitglieder/vorstand.
We wish you a nice day with your member site.