Facebook analytica leak

[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

DPCalendar 6.2

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.

Resource view

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:

  • Day page
    The day page shows the full day with hourly slots.
  • Week page
    The week page shows the full week, where every day is shown as 24 (hours) slots.
  • Month page
    The month page shows all days of the month, where each slot represents a day.
  • Year page
    The year page shows all days of the year, where each slot represents a day, similar to the month view.

Of course you can control in the settings which view should be shown initially.

resource view

Faster page load

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.

waterfall

Overhaul of the list and map views

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.

map search bar

Small improvements and bug fixes

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:

  • [#4791]   ICAL Link - Goolge Calendar
  • [#4939]   Access to calendars through a OAuth token
  • [#5193]   New event with a new venue in one step
  • [#5227]   Resources view based on locations
  • [#5284]   More search options in the list and map view
  • [#5297]   Tags filter in modules
  • [#5309]   Multiple rooms per location
  • [#5384]   Customise event form view
  • [#5409]   Resource views for locations
  • [#5414]   Lighweight Datepicker
  • [#5432]   Manual payment plugin send information mail
  • [#5281]   Obfuscate passwords of external calendar systems
  • [#5326]   Upcoming and counter modules show/hide
  • [#5367]   Show image in SQL plugin
  • [#5372]   DPCalendar Map search consider live location lookup
  • [#5373]   SQL import events should use plain id for urls
  • [#5427]   Configurable resource default view
  • [#5442]   Lightweight tooltip library
  • [#5443]   Make counter native JS
  • [#5447]   Load JS files in defer mode to improve performance
  • [#5448]   Update iframeresizer lib and move to vanilla js
  • [#5466]   Move loader to it's own layout
  • [#5469]   Allow to disable the filters in the map module
  • [#5332]   Quickadd floats off the screen
  • [#5404]   Mini module clears system messages
  • [#5410]   Change event time in front end update missing
  • [#5449]   System messages are not shown full width on back end
  • [#5458]   Incorrect Ticket Limit For Users
  • [#5464]   Mini and main calendar not showing the list

How to upgrade?

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

Joomla overrides

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.

What are template overrides?

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.

What is the problem?

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.

Is it then not a BC break?

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.

Is there a solution?

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.

JWC17

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.

overwrite jquery version

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.

How to load jQuery

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

The Problem

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.

The solution

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 :-)

Cookies make it easier for us to provide you with our services. With the usage of our services you permit us to use cookies.
More information Ok Decline