[UPDATE 14. August 2018: The DPCalendar FB plugin is working again since version 7.0.4 as we upgraded to the new platform API 3.1. There is still an issue with pages where you are not an admin or developer of. But it looks like a problem on the FB platform as mentioned in this ticket.]
Since the Cambridge Analytica leak, the Facebook developer team takes some measures that this can't happen again. One of the tasks is to review their app platform. A consequence is that apps do stop working and API access is not possible anymore. The DPCalendar plugin relies on the API as it is the official way to access the event data from your Facebook pages. Here is a link to the restrictions they do put in place.
As Facebook is also putting some restrictions for events fetching, it can happen that your DPCalendar plugin is not pulling the events anymore into Joomla. This happened to one of your app too while another one is still working. The problem is that we can't do anything on that part as the API is fully managed by Facebook. We can just wait till an official statement comes out what the proper steps would be to make your Facebook app and the API work again. When you log in on https://developers.facebook.com, you will see an announcement that they are not reviewing any app at the moment. But for the events API your app must be reviewed as stated here when you want to go public with it. At the moment we are not sure if the apps will still work in development mode as they did before the leak. You can find here more information about the different steps in the life cycle of a Facebook app.
What you can do in the meantime, except to wait? You can create new events in DPCalendar itself or move to another system like iCloud or Google calendar.
Here is a list of links which do provide more information regarding the progress of the platform review:
We are aware that this is a frustrating situation and are monitoring the progress of the platform review very closely. As soon as something changes we will update this article and push status updates on our official twitter account. Thanks for understanding.
Sincerely, Allon and the Digital Peak team
Right before the end of year, we have a great present for you. DPCalendar 6.2 has arrived which comes with a lot of new features and better performance. The biggest new feature is the resource view for locations which allows all subscribers to show a horizontal resource view in the location details and list. Read on for detailed explanation of all the main features.
Many DPCalendar users do use it as a resource management tool or as event calendar. A missing peace in their workflow was to have . It is now possible to define multiple rooms per location and assign events to these rooms, before you could only assign an event to a location. On the location detail page a new resource view is displayed which gives a detailed overview about the rooms and which events do happen in these rooms.
The events are loaded trough ajax to not block the page load and are rendered by a similar script as the main calendar view. The new view comes with four different pages:
Of course you can control in the settings which view should be shown initially.
As fast pages are nowadays critical for the sccess of a web page, we made our hands dirty for you to improve the performance of DPCalendar. A lot of old JQuery based scripts got replaced by smaller plain vanilla libraries. This has the advantage that thy require less bandwidth, are faster executed and do not have any external dependency. For example we were completely rewriting the counter plugin and do have now a 600 Bytes script loaded with a tiny date library instead of a full blown jQuery related timepicker.
All the scripts are minified and loaded in defer mode, means they do not block the page rendering and are fetched during the rendering process of the browser and executed at the end. More stuff is done then in parallel.
We do not combine the scripts as HTTP/2 is supported by every major web server and it is faster to have many small scripts instead of a big one.
The list and map views got some tiny markup changes. But the biggest diffference are the new filter options. Beside the search feild, you can now define the date range and a location and radius to search events within. If the site visitor wants to search for events near him, then there is a new button which determines the current location and searches for close events.
Beside the great new features, we fixed some bugs and added many little goodies to DPCalendar to make your life as administrator easier and to offer your visitors a neat event experience. The following list represents the full changelog of the new 6.2 version:
We tested this version extensively, so you can be safe when upgrading. Just install the whole package from our download site or trough the Joomla update manager, DPCalendar will take care about the rest. We touched a lot of layout files because this new features had a big impact on them, so please double check your layout overrides!!
BUT we recommend always to make a backup first and do the upgrade on a test clone of your production site to have no unexpected downtime. Also clearing the Joomla cache is a good advice when upgrading extensions in general, not just when upgrading the Joomla CMS.
Kind regards
Allon Moritz aka laoneo
Founder of Digital Peak
Before we start, Joomla template overrides are a very good tool for site integrators to adapt the core to their needs. But it is a pain for extension developers like us. Why? We will tell you, read on.
Template overrides do require some basic PHP, HTML and CSS knowledge. So it is not a tool for everybody who uses Joomla. It allows site integrators to override the output of any extension in a template. It helps when you have a special requirement which can't be controlled by an option or when you need to change the HTML markup. Basically you can copy the view file (mostly default.php) from the extension view folder to your template html folder. The Joomla view renderer will then automatically pick the one form your template instead of the one from the component. It works for core and 3rd party components, modules, plugins and layouts. More documentation can be found on the web or in the official Joomla docs.
As the view file is a copy of the original file, the problem comes on upgrades. When the original file has changed after an extension is upgraded. For example when new code is added, then the override doesn't get adapted. This can lead to errors or missing features. This is not a problem only for extension developers, also the core is affected. As we introduced custom fields, some templates had an override for the front end article editing form from an old version which was not able to display custom fieldsets in the form. But this are not regular cases in core as new features get added on a much slower pace.
For extension devs it becomes a real problem as we ship new features more often. For example in the release of DPCalendar 6.2, we replaced some javascript libraries with new ones and added the defer attribute to load them faster. All of this happens in the template files (eg. default.php). If you have an override in place, then it still tries to load the old files and can crash your site.
You can argue that it is a BC (backwards compatibility) break. But it is hard to expand BC in layout files, otherwise they will become bloated. It would then also mean that every new feature would require a new major version which would be insane.
Don't do overrides! Wait, really? It is not that dramatically. But you should really consider if an override is needed or if the changes can be done trough CSS as well. We have many customers who want to do overrides, but then we figure out that it is possible to make the changes with CSS commands too. Or we have already an option which does the job. Yes we have a lot of options, so you can control a lot within DPCalendar.
Joomla has a very minimalistic override management UI which doesn't help here much. So what we did, for Google Summer of Code 2018, added a proposal to spice up the override management. Basically you need a diff viewer and an override detector when an extension or the core is upgraded and inform the site owner that layout files have changed where an override exists in the template.
We hope to shed some light into the biggest issue of Joomla overrides.
Allon, the main developer of Digital Peak, was attending the Joomla World Conference to meet the community and share knowledge. It was another great event with amazing people. We are proud and happy to be part of the this awesome community.
As we are part of the Joomla 4 working groud we are very amazed to have released the first alpha version of Joomla 4, the next great thing in the Joomla land. You can read more about it here. Allon was also holding a session about how to convert your Joomla 3 extension to Joomla 4. You can download the slides here.
After telling dozens other extension developers how to correctly load your own version of jQuery in Joomla, we got this week into a conflict with a big community extension. They just load their own copy without care. So it's time to write a blog post how to do it correctly. A side note. In this post we provide very simplified code examples, they should give you a starting point. Please read the Joomla docs carefully and also the Joomla core code itself, that you know what you are doing.
The Joomla CMS comes with it's own unmodified jQuery script in version v1.12.4. When loaded, it executes it in no conflict mode together with jQuery migrate to be compatible with older versions. So every extension which needs jQuery in Joomla MUST load it with the following PHP code. This ensures that the right jQuery script is loaded only once.
JHtml::_('jquery.framework');
More documentation can be found in the official docs.
When you are loading in your extension a jQuery plugin, then you do it mostly that way:
JHtml::_('jquery.framework'); JHtml::_('script', 'com_foo/myJqueryPlugin.js', array('version' => 'auto', 'relative' => true)); JFactory::getDocument()->addScriptDeclaration("jQuery(document).ready(function() { jQuery('#selector').myJqueryPlugin(); })");
In Joomla are all Javascript files loaded from all extensions before the inline Javascript code. When after your extension is executed another one is loading it's own copy of jQuery like:
JHtml::_('script', 'com_bar/jquery-3.2.1.min.js', array('version' => 'auto', 'relative' => true));
Then the head will look like
<head> <script src="/media/jui/js/jquery.js?56690c624209a47cb536df0eac0a28f3"></script> <script src="/media/jui/js/jquery-noconflict.js?56690c624209a47cb536df0eac0a28f3"></script> <script src="/media/jui/js/jquery-migrate.js?56690c624209a47cb536df0eac0a28f3"></script> <script src="/com_foo/js/myJqueryPlugin.js"></script> <script src="/com_bar/js/jquery-3.2.1.min.js"></script> jQuery(document).ready(function() { jQuery('#selector').myJqueryPlugin(); }) </head>
This would result in the Javascript error "Function myJqueryPlugin not found". The problem is that the second load of jQuery overwrites the first global jQuery object where the plugin myJqueryPlugin is attached to. So all plugins do not work anymore which are attached to the old jQuery object.
So why this strange way of loading jQuery trough JHtml? It offers the possibility to overload that function in a plugin. What you have to do is to create a Joomla plugin according to the docs for the group system. Then add a function onAfterInitialise and register your own jquery service like in the following code snippet:
public function onAfterInitialise() { JHtml::register('jquery.framework', function ($noConflict = true, $debug = null, $migrate = true) { JHtml::_('script', 'com_bar/jquery-3.2.1.min.js', array('version' => 'auto', 'relative' => true, 'detectDebug' => $debug)); // Check if we are loading in noConflict if ($noConflict) { JHtml::_('script', 'jui/jquery-noconflict.js', array('version' => 'auto', 'relative' => true)); } // Check if we are loading Migrate if ($migrate) { JHtml::_('script', 'jui/jquery-migrate.min.js', array('version' => 'auto', 'relative' => true, 'detectDebug' => $debug)); } }); }
This ensures that only your jQuery script is loaded. It reduces the page size as not two jQuery scripts are loaded and it will not break all other jQuery based extensions. The head of your page will then look like:
<head> <script src="/com_bar/js/jquery-3.2.1.min.js"></script> <script src="/media/jui/js/jquery-noconflict.js?56690c624209a47cb536df0eac0a28f3"></script> <script src="/media/jui/js/jquery-migrate.js?56690c624209a47cb536df0eac0a28f3"></script> <script src="/com_foo/js/myJqueryPlugin.js"></script> jQuery(document).ready(function() { jQuery('#selector').myJqueryPlugin(); }) </head>
So we at Digital Peak hope that all extension developers are on the same page and the jQuery errors are history. Time no to turn vanilla :-)