The essential news about content management systems and mobile technology.
Powered by Joocial & JoomGap.
UIkit 3 Beta 23 released

UIkit is the work horse behind pretty much all of our products. It's the open source front-end framework we build and use ourselves to create the YOOtheme Pro Builder and all of our themes. Consequently, we are working on improving UIkit. Today we are happy to release the UIkit 3 Beta 23 which is packed with new components and features.


Parallax scrolling is a popular technique in web design to add dynamic effects to a page during scrolling. Now, it is available in UIkit 3. The super flexible Parallax component allows you to animate almost every CSS attribute based on the scroll position on your site. Used in the right way it gives your website a subtle 3D effect, creates the illusion of depth and allows to highlight certain elements. Check out the examples and make sure to show us what you've created with this flexible component.

Parallax component

Grid Parallax

You can easily bring the parallax effect to your grids using the Grid Parallax component. It simplifies the options you need to use and allows to animate several properties to create grids that are something special. See it in action here.

Grid Parallax component

Form Range

The Form component now also styles input elements with the range type. It allows you to drag a handle to select a specific value from a range of numbers.

Form range component

Marker component

With the Marker component you are able to create a marker icon that can be displayed on top of images. A great use case are popovers on visual elements. How about you add some interactive labels to your photos? Use the existing Position component to place the markers wherever you want.

Marker component

More additions

As always, the release comes with many more features, fixes and changes. We've added a new class for xlarge paddings and new visibility classes to hide elements on touch or no-touch devices and much more.

We'd like to know what you think about the release. Please leave your feedback in the comments and join us in the UIkit Gitter chat.

Read more

Updates available for our Joomla extensions

We spent the week addressing minor teething issues and including several new functionality across all of our extensions. I would also like to take this opportunity to stress out that if you are still on Joomla 3.7.0, please update immediately! I have been troubleshooting several sites and noticed that some of these sites are still running on Joomla 3.7.0. 

In case you missed out on the announcement that was posted yesterday, the release of Joomla 3.7.1 addresses a critical security vulnerability and several other bug fixes.

There are quite a number of changes for me to pen these changes on the post but I have cherry picked some of these new cool functionality below:

Komento 3.0.6

The last update for Komento was published on 2nd of March 2017 and it has been pretty stable since then. There are some minor annoying issues and some new features which we have thrown in. Some of the changes includes:

  • Hikashop Integrations. We have added integrations with Hikashop and as soon as they release a newer version of Hikashop, you will be able to pick Komento from their settings.
  • Addressed issues with W3C validation.
  • BBCode library will no longer get rendered if it is not in use.
  • Admin will be able to approve comments in the e-mail that they received.
  • View all changes

EasyDiscuss 4.0.15

This release contains quite a number of bug fixes since EasyDiscuss 4.0.14. In total, there are about 32 fixes that was applied in this release. These are some of the changes in EasyDiscuss 4.0.15:

  • New Amazon S3 region for US East (Ohio) added
  • Fixed issue when branching out replies as questions
  • Smiley urls are now using relative urls.
  • Added default image for opengraph when there is no image in the post.
  • It is now possible to search for posts at the back end using AUTHOR: prefix.
  • View all changes

EasyBlog 5.1.8

This release contains quite a number of new features. In total, there are about 54 changes that was applied in this release. These are some of the changes in EasyBlog 5.1.8:

  • Post notifications can now be configured to be sent to specific user groups.
  • Folders in media manager can now be inserted as a gallery.
  • Reactions visibility can now be set on per category basis
  • Authors may now resend post notifications from the front end dashboard.
  • Added additional ordering options for single category post listing.
  • It is now possible for authors to set a custom css class for each block
  • View all changes

EasySocial 2.0.18

This release contains quite a number of bug fixes as most of the new features are being worked upon in EasySocial 2.1. In total, there are about 45 fixes that was applied in this release. These are some of the changes in EasySocial 2.0.18:

  • Addressed an issue with unrecognized .berlin TLD.
  • Show all featured group button now appears properly in the group listing page.
  • Video upload from story form now stores the description and title correctly.
  • Addressed a conflict between URL shortener plugin and JFBConnect system plugin.
  • Deleting events will now also remove them from the calendar app.
  • Re-uploading videos will now update the video on the respective storage.
  • View all changes

What's Next For Us?

The entire development team is currently focusing on the next generation of EasySocial 2.1. EasySocial 2.1 will be help you simplify your day to day operations on managing a social network. Of course, it'll include some of the state-of-the-art features that I am extremely excited about in EasySocial 2.1. I cannot wait to share it with you guys in due time :)

Happy Updating!

P/S: Should you require any assistance with upgrading your extensions, feel free to get in touch with us on our helpdesk and our support team will be more than happy to assist you. 

Read more

I was boarding my flight from Boston to Madison the other day when my phone buzzed. At first, I assumed it was just another push notification I’ve been meaning to turn off. But it was actually my Delta Airlines app telling me that my bags had just been loaded onto my flight after a tight connection.

Wow, that’s actually pretty awesome.

From an industry that’s not known for delivering great customer experiences, it actually made a big difference to me.

Companies like Delta are figuring out that simple, context-driven mobile experiences are a great way to delight users, and keep them coming back. Of course, the benefits of these mobile moments extend far beyond consumer apps. In the enterprise, mobile is steadily replacing legacy desktop apps with context-driven experiences that make employees happier and more productive.

But here’s the catch: Within most enterprises, demand for mobile development is growing five times faster than internal app dev teams can actually deliver. That’s according to Gartner, but it also squares with conversations we have with our customers who have switched to Ionic as a way to move faster.

At Ionic, we’ve started calling this phenomenon the Mobile Delivery Gap.

What’s behind the Delivery Gap? Well, every businesses is different, but here are a few patterns we’ve observed:

First, building apps the old way is hard. Hiring specialists to write native code – and then designing, developing, testing, and maintaining apps in parallel – is time-consuming, costly, and inefficient. And if you want your app on more than one platform, you need to develop it multiple times, with entirely separate code bases. Of course, for some apps this might make sense, but for most, it’s just overkill.

Second, many enterprise orgs have chosen the wrong tools for the job. I won’t name names, but there are plenty of solutions that — sold top down — seem to meet the CIO’s criteria. But by the time they’re pushed onto dev teams, things fall apart. Devs don’t want to work with crappy software and clunky technology tools (regardless of where they’re placed in some analyst vendor ranking). No wonder customers are pressured into seven figure, multi-year contracts. Ultimately, these solutions go unused and management ends up back at square one.

The last pattern we’ve seen is rogue development. With centralized app dev teams unable to keep up with demand, frustrated stakeholders go it alone. Marketing hires an outside contractor. Finance tries building an app on their own. And so on. Before long, development work is done in silos, with lots of duplicated effort and incoherent tech stacks emerging throughout the company.

We actually love hearing this from big teams and enterprises, because Ionic is such a natural, perfect solution to the problems they’re facing. Bridging this gap is something that inspires us to make app creation a lot faster and easier for everyone. It’s one of the reasons we built Ionic in the first place. It’s also why we strive to continue to build tools developers love and want to use everyday. In future posts, I’ll talk about how we’re progressing on this mission.

In the meantime, is the Mobile Delivery Gap something you’ve encountered in your organization? If so, what are you doing to address it?

Read more


Supra is a powerhouse template loaded with features and uncompromising in its versatility. With a click, activate full page scrolling for a modern user experience. Build beautiful background slideshows in seconds, and customize your site with over two dozen powerful particles that make setting up a complete website a snap.

Read more

Joomla 3.7.1 Security Release Available

Joomla! has just announced the immediate availability of Joomla 3.7.1 which is a critical update for 3.7.x. We would like to strongly encourage and advise anyone that has previously upgraded to 3.7.0 to update to 3.7.1 immediately to avoid any complications that you may encounter. 

As this is a critical security release and it isn't a feature release, you shouldn't be waiting for a day or two before upgrading. You can read more about the announcement from Joomla. All of our extensions and templates works fine with Joomla 3.7.1.

Read more

Some kittens organizing themselves into formatted modules

Howdy folks! In our last blog post we discussed how to configure an app to lazy load pages. In this post we’ll discuss how to better organize the rest of our app to operate with lazy loading; specifically the UI Components, Directives and Pipes.

Setting the stage

Imagine we have an example music app with these use cases:

  • Lazy loaded: HomePage and DetailPage
  • Two components for rendering our music data
  • Custom pipe to convert milliseconds to minutes:seconds
  • Two directives used in the components

I’ve created this sample app we’ll use as reference in this post, it is available on Github (just switch branches to see the different options we discuss below).

Keep in mind, everyone’s needs are unique, so we recommend reviewing the options presented in this post with your team to determine what works best for your app.

Generally, we recommend following one of two different approaches when developing your app:

  • Option 1 – Encapsulated Modules
  • Option 2 – Shared Common Modules

Each approach has unique benefits and drawbacks, let’s see how they differ in greater detail…

Option 1: Encapsulated Modules

Wrapping all your custom components and pipes into distinct modules (one for components and one for pipes)

With this approach every component, pipe, and directive available to your app can become its own self-contained module. Using the master branch of our sample app, here’s how I structured things:


Within the code of our music-card and music-item components (below), we can see how each of these components exports themselves as encapsulated modules.

// music-card moduleimport { NgModule } from '@angular/core';import { IonicModule } from 'ionic-angular';import { MusicCardComponent } from './music-card';import { MsToMinsPipeModule } from '../../pipes/ms-to-mins/ms-to-mins.module'@NgModule({  declarations: [MusicCardComponent],  imports: [IonicModule, MsToMinsPipeModule],  exports: [MusicCardComponent]})export class MusicCardComponentModule { }
//music-item moduleimport { NgModule } from '@angular/core';import { IonicModule } from 'ionic-angular';import { MusicItemComponent } from './music-item';import { MsToMinsPipeModule } from '../../pipes/ms-to-mins/ms-to-mins.module'@NgModule({  declarations: [MusicItemComponent],  imports: [IonicModule, MsToMinsPipeModule],  exports: [MusicItemComponent]})export class MusicItemComponentModule { }

When we import these modules into their respected pages, we can be certain the compiled chunk will contain the minimum required code it needs to function properly.

Now we can also apply the same concepts to splitting out our directives and pipes. Isolating them into their own modules will ensure that we’re not sending any unnecessary code to our chunks.

import { NgModule } from '@angular/core';import { LogElmDirective  } from './log-elm';@NgModule({  declarations: [LogElmDirective],  exports: [LogElmDirective]})export class LogElmDirectiveModule { }
import { NgModule } from '@angular/core';import { LogEvntDirective  } from './log-evnt';@NgModule({  declarations: [LogEvntDirective],  exports: [LogEvntDirective]})export class LogEvntDirectiveModule { }

The down side of this approach is that there’s more to keep track of as your app grows.
Consider an app with many pages and many components/directives/pipes. As you’re working on things, you’ll need to constantly make sure the correct modules are imported in order to use your custom components. Depending on how many of these modules you need in your page, this could be one import, or 30 imports.

There’s also a bit more boilerplate code for each of these individual modules. While most of that boilerplate code is 6-10 lines, it can be quite repetitive to have constantly go through the ritual of creating a new module every time a new feature is added.

Option 2: Shared Common Modules

Creating a shared module for each component and pipe your app may have.

With this approach, instead of splitting things into their own isolated module, everything gets bundled into a shared components.module.ts The same would go for any pipes we have or any directives we might have as well. A real world example of this would be the angular-moment package from Uri Shaked.

Using the common-mmodules branch of our sample app, here’s how I structured things:

The logic here is that instead of micro-optimizing your app and creating multiple sub-modules, a single shared module contains all the components, pipes. and directives your app needs.
For instance, our music-item and music-card components are not overly complicated components.
Instead of splitting them out, we could package them into a shared components.moudle.ts file:

// components.moudle.ts// Note that we also need to provide the// shared PipesModule sice the components use it.import { NgModule } from '@angular/core';import { MusicCardComponent } from './music-card/music-card'import { MusicItemComponent } from './music-item/music-item'import {IonicModule}  from 'ionic-angular'import { PipesModule } from '../pipes/pipes.module'@NgModule({  declarations: [MusicCardComponent, MusicItemComponent],  imports: [PipesModule, IonicModule],  exports: [MusicCardComponent, MusicItemComponent]})export class ComponentsModule { }

Doing this means anytime we want to use either music-card or music-item, they’re automatically available in our chunk. The same concept can be applied to directives and pipes.

For our directives:

import { NgModule } from '@angular/core';import { LogElmDirective } from './log-elm/log-elm'import { LogEvntDirective } from './log-evnt/log-evnt'@NgModule({  declarations: [LogElmDirective, LogEvntDirective],  exports: [LogElmDirective, LogEvntDirective]})export class DirectivesModule {}

Creating shared directives.module.ts and pipes.module.ts will allow you to import these top level modules once, and have all the functionally available.

Of course, this example is not overly complex, but illustrates how developers can apply this pattern.

The down side of the shared common module approach is code is being sent to that chunk regardless if it’s being used. So while we’re using these two components in a single page, any additional components we’re not using still cost us in the price of chunk size. This can be a concern if your app has a lot of components, especially if you’re shipping a web app where everything is sent over the wire. Loading the code for 21-40 components when you only need 4-5 is a big “no-no”.

The key takeaway of these two options for developing components, pipes, and directives for use with lazy loading are:

Option 1
Pro: Easier separation and encapsulation
Con: Additional boilerplate code for each module

Option 2
Pro: Easier to manage multiple components/directives/pipes. They all come from the same shared place.
Con: Extra code is being sent over when it’s not needed. Final chunks can be larger than needed.

So where can you go from here?

There are pros/cons to both of these approaches. Maybe your app is smaller, and wouldn’t benefit from an overly modular approach, then the shared common module solution (option 2, shared common modules) may be of better benefit. Alternatively, your app might contains large quantities of pages, components, directives, and pipes; in this situation you would want to consider making your app more modular (option 1, encapsulated modules).

What we’ve discussed here is only 2 options that we have landed on, but this doesn’t mean you’re limited to just that. You can feel free to experiment and find a balance that fits your team and your app. Whatever approach you land on, the goal will be the same, send as little code as possible per chunk.

And now that we’ve addressed code structure…what else is left?

Since our goal is to send as little code as possible per chunk to the user, and we’ve already split our code into smaller module, the only code left to look at is our libraries. We’ll focus on the some of the most commonly used libraries people include in their apps and some alternatives that are much more mobile friendly.

Links for the sample app:

Read more

When we asked the Ionic developer community to Become an Ionic Jedi Hackster on May the Fourth, we expected only two – maybe three – developers would have the free time to invest developing and completing an app using the Ionic 3 CLI for this hackathon. The results exceeded our expectations…

Imagine our surprise when we received not two or three, but ten (10) finished hackathon applications from our developer community!

Within a few hours notice of the hackathon, our developers began hacking on their apps, and quickly submitting those apps for judging. During our internal judging at Ionic HQ, we were astonished at the high-quality of the entries, and realized this deserved additional perspective from our community. So, last week we opened community judging on Ionic Worldwide Slack so we could learn your favorites.

We then averaged the community and internal judging rank results to determine who will Become the 1st Ionic Jedi Hackster!!!

Before we tell you who the winner is, let’s take a moment to review the awesome hackathon submissions.

NOTE: You can experience these apps for yourself by downloading and installing the Ionic View app for your mobile device, and preview by entering the respective ID from the list below…

  • 10th place: ionic-lightsaber
    ID = fac1f536

  • 9th place: Star Wars Wikipedia
    ID = b8d5d510

  • 8th place: Tinder Wars
    ID = ec4dd7b3

  • 7th place: chewTravel
    ID = 0f7a34b0

  • 6th place: Guess Who: Star Wars
    ID = 8eb764a5

  • 5th place: SW-Jokes
    ID = af9e9892

  • 4th place: R2 Communicator
    ID = 6A045E00

  • 3rd place: STAR LOVE
    ID = 157de8d7

  • 2nd place: Star Wars Trivia
    ID = 189a7fc2

Plans were to announce the winner last Friday (May 12), but with all the great entires we wanted to say “Thank you” for our developer’s hard work. So after some thought we decided, EVERYONE who participated will receive the following participation gift from Ionic:

  • 4 – Ionic stickers
  • 1 – Ionic magnet
  • 1 – Ionic bottle opener
  • 1 – Ionic head/sweat band
  • 1 – Ionic t-shirt

Of course, we still haven’t announced the winner of the grand prize (the light saber in the head of this post), and who the first Ionic Jedi Hackster is yet, have we!?

Without further ado…

Congratulations to the 1st Ionic Jedi Hackster —
Yann B. from Brazil
1st Place: “Star Warnic”
ID = 7769d217!!!

Read more