Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Apr 13 2015
Apr 13

finalrest
The future of the web is inarguably mobile. Mobile use is clearly increasing as people spend more time on their phones, and the rate that people are using dedicated mobile apps rather than their mobile browser is also increasing. But with web services, mobile apps can integrate popular web-based content management systems and in the process save hundreds of development hours while providing enhanced user experience for both the end user and web editors. This also creates tremendous, largely untapped business opportunity for agencies.

View our conversion service.

Drupal and WordPress power 2.1% and 23.3% of the web, respectively. There are many contrasts you can make to decide “which is better,” but in the end it comes down to the question of “what is the right tool for the job?” Drupal runs a smaller percentage of the web so it is targeted less by hackers, thus making it less vulnerable. In Drupal all contributed code or “modules,” are peer reviewed at http://drupal.org, helping to ensure quality and stability. Conversely, because of the smaller community and the strict review process there are less modules that get released than WordPress “plugins.” This puts Drupal at a distant second in the volume of contributed plugins/modules that are available. Still, Drupal 8 (the next release of Drupal), shows foresight into the future direction of the web, taking into account “the web of things” or to many web developers the “elephant in the room” Mobile Apps.

Drupal has fully mature projects that turn it into a powerful backend or RESTful “web service” that can be used to provide data to mobile apps via API calls. Drupal 8 comes with the very powerful and stable “Services” module built into D8 core, meaning it will come bundled in every new site of Drupal 8.

To put it simply, your Drupal or WordPress website could be powering the next best mobile app. “The web of things” is another way to say web services, the things that make the apps we use every day “do” things or “talk to” things. Snapchat for example is a popular app, but the native code, the kind written by an iOS or Android developer in the languages Java or Objective C, is quite simple. The heavy lifting is done by a web server somewhere which exposes data through “REST endpoints”;” this web server could be a web app like Drupal or WordPress running the ubiquitous language PHP.

PHP runs on about 75% of websites today, it can be looked at as a big ship – it takes a while for it to turn around (incorporate latest innovations) but it eventually does. While newer languages innovate quicker, PHP has proved to have a dedicated community that eventually does evolve with the times. For these reasons PHP is here to stay.

There are a variety of methods to utilize Drupal or WordPress to create an app that can be purchased on the iOS and Android app stores. For larger budget projects or projects started from scratch, the best method is to code the entire front-end presentation layer of the app in a native language, then use a web service to pull data in from a Drupal/Wordpress web app on “the cloud.” Some people may be able understand this by thinking in the terms of “feeds,” though the technology is quite different. The benefits are clear — you could have a powerful website and also a mobile app for less effort than it would cost to develop each individually with completely unique data sources. It also allows editors to login to their familiar Drupal/Wordpress editors and push out content that will then go to the app and website simultaneously.

Another hybrid method I developed which is very useful for smaller budget projects and for websites that already exist, is to create an API only for the login interface. I created a very simple API and native front-end to handle the login and password reset functionality. The rest of the app is a web view or “wrapper,” meaning that after you login, you just see the website. What makes this so cool is that it does feel quite “appy.” The native feel is enhanced by native navigation and custom offline messaging. After the user enters their email and password into the native interface they never have to login again, thus giving an experience identical to an app in every way. They simply click the icon on their homescreen and they are in. What is happening behind the scenes is that the email and password are getting saved and the user is being logged into the website via the API every time they click the icon.

Through the growth of RESTful web services we can have it all. We can build both web and mobile apps with greater ease than ever before, by simply reusing the same backend infrastructure for multiple platforms.

Jan 25 2015
Jan 25

Preface

Our fourth  multilingual site and significantly more of a challange.  When in the past I had dealt with latin alphabet only, this time I was dealing with Arabic and there were some major differences here. In the Arabic language everything reads right to left. So through simply checking a setting in i18n admin panel you can add the attribute dir="rtl" to the <html>  tag. This conveniently moves all your content to the right side of your page and changes text highlight from this direction as well. This caused quite a few issues mainly with CSS.   Sprites were off on the Arabic version by a few px, but luckily this was easy to fix, as Drupal adds the class i18n-ar to the body tag, so it was easy to target Arabic only views. One other major issue I had was a large left margin of > 1000px when language was set to Arabic, this was fixed by setting body tag to overflow:none;

Translating Fields and Taxonomy

First enable translation on the content type you want to translate.  You can find this  at the bottom  in the  ‘Publishing options’ tab.  There you need to select ‘Enabled with translation’ . After saving  you will see a new tab – ‘Multilingual settings’.  Afterwards select checkbox ‘Set current language as default for new content’ – This makes it easier for editors creating a post if they primarily post in a certain language, it will be set to that language by default without having to manually choose a language.

To translate fields in content type (labels, descriptions etc.) –  enable ‘Field translation’ module. After this we can go to the field in the ‘manage fields’ section.

and click translate tab –

and there you can translate needed title

Replace text

and click ‘Save translation’.

To translate taxonomy terms enable – ‘Taxonomy translation’ module. After this we can go to the vocabulary and edit it.

With this method we can translate terms via the admin panel. If we need different terms for each language – we must choose ‘Translate.  Different terms will be allowed for each language and they can be translated.’ – this method can also be used too in some cases. You must decide before development what method you want to use.
Now we can translate the term in admin section. Go to yoursite.com/admin/config/regional/translate/translate and search term –

now we can see the term in the translation interface.

and translate –

Jan 03 2015
Jan 03

Need to control which users can access a node/page of a particular content type on your Drupal site?

The Drupal Node API provides us a quick way to do this. It provides the hook_nodeapi function to react to the actions affecting all kinds of nodes. We can easily implement this hook in our module or theme. A prototype of this hook looks like this:

function myCustomModuleName_nodeapi (&$node, $op) {

/*Your code and conditions here*/

}
Here myCustomModuleName is the name of the module in which this hook is defined. The two parameters are $node, which represents the node on which the action is being performed and the other one $op,  is the kind of action which is being performed. The $op can have values like view, alter, delete, print and so on…

As an example, I was looking to design such a condition for my website:

  • If enrolled user creates content type for "recipe", restrict access to recipe except for node author and admin.

So, I needed to develop a mechanism through which for each node of type “recipe”:

  • Everyone can see nodes created by admin including Anonymous user.
  • Only site admin and node author can see nodes created by users other than administrator.


I created a custom module for and used the nodeapi hook to implement the mechanism as follows:

—————————————————– ————————————————–

function custom_hook_implements_nodeapi (&$node, $op)

{

global $user;

if(($node->type == ‘recipe’ and $op == ‘view’))

{

$author=user_load($node->uid);

if(!array_key_exists(3,$author->roles) and $author->uid!=$user->uid and !array_key_exists(3,$user->roles))

{

drupal_access_denied();

}

}

}

—————————————————– ————————————————–

As you can easily observe here that I have only created an if condition that first checks, if the node type is “recipe” and operation performed is “view“. Thereafter, if conditions are found to be true, it further checks for the following:

– if the author of the node is NOT an administrator user (3 being the role ID of administrator user).

– if the author of the node is NOT the user accessing the node himself.

– Finally, the user accessing the node is not an administrator user himself.

 

If these conditions are met, it shows the drupal access denied error message, thus, denying the user access to that node.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web