Mobomo webinars-now on demand! | learn more.

WordPress and Drupal

President of Mobomo, Ken Fang, recently sat down with Clutch for a Q and A about all things WordPress and Drupal.

What should people consider when choosing a CMS or a website platform?

They should probably consider ease of use. We like open-source because of the pricing, and pricing is another thing they should take into account. Finally, for us, a lot of it revolves around how popular that particular type of technology is. Being able to find developers or even content editors that are used to that technology or CMS is important.

Could you speak about what differentiates Drupal and WordPress from each other?

Both of them are open-source platforms, and they’re probably the most popular CMS’s out there. WordPress is probably the most popular, with Drupal running a close second. Drupal is more popular in our federal space. I think the main difference is that WordPress started off more as a blogging platform, so it was typically for smaller sites. Whereas Drupal was considered to be more enterprise-grade, and therefore a lot of the larger commercial clients and larger federal clients would go with Drupal implementation.

They’ve obviously both grown a lot over the years. We’re now finding that both of the platforms are pretty comparable. WordPress has built a lot of enterprise functionality, and Drupal has built in a lot more ease of use. They’re getting closer and closer together. We still see that main segregation, with WordPress being for smaller sites, easier to use, and then Drupal for more enterprise-grade.

Could you describe the ideal client for each platform? What type of client would you recommend each platform for?

Definitely on the federal side, Drupal is a much more popular platform. Federal and enterprise clients should move to the Drupal platform, especially if they have other systems they want to integrate with, or more complex workflow and capability. WordPress we see much more on the commercial side, smaller sites. The nice thing about WordPress is that it’s pretty quick to get up and running. It’s a lot easier for the end user because of its limited capability. If you want to get something up more cost-effectively, that’s pretty simple, WordPress is a good way to go.

Could you speak about the importance of technical coding knowledge when building a website on either platform, from a client’s perspective?

Most of these main CMS’s are actually built in PHP, and most of them have a technology stack that requires different skillsets. So, on the frontend side, both of them require theming. It’s not only knowing HTML, CSS, and JavaScript, but it’s also understanding how each of the content management systems incorporate that into a theme. You usually start off with a base theme, and then you customize it as each client wants. As such, you need either WordPress or Drupal themers to do that frontend work. For any backend development, you do need PHP developers. For Drupal, it’s called modules. There are open-source modules that people contribute that you can just use, you can customize them, or you can even build your own custom modules from scratch. For WordPress, they’re called plugins, but it’s a very similar process. You can incorporate a plugin, customize it, or write your own custom plugin.

In between all of this, because it is a content management framework and platform, there are site builders or site configurators. The nice part about that is that you can literally fire up a Drupal website and not have to know any PHP coding or whatever. If you’re just doing a plain vanilla website, you can get everything up and running through the administrative interface. A Drupal or WordPress site builder can basically do that, provided they are savvy with how the system actually works form an administration standpoint. So, those are the technical skills that we typically see, that clients would need to have. In many cases, we’ll build out a website and they’ll want to maintain it. They’ll need somebody in-house, at least a Drupal site builder or a themer, or something like that.

Do you have any terms or any codes that clients should be aware of or should know prior to trying to launch a project in Drupal or WordPress?

PHP is definitely the main language they should know, and then HTML, JavaScript, and CSS for the frontend stuff. Drupal 8 has some newer technologies. Twig is used for theming as an example, so there’s a set of technologies associated with Drupal 8 they need to know as well.

Is there a particular feature of WordPress or Drupal that impressed you and potential users should know about?

I’m going to lean a little more into the Drupal world because a lot of people are starting to move to Drupal 8, which was a big rewrite. There are now a lot of sites starting to use that in production. They did quite a bit of overhaul on it. It is more API-driven now. Everything you do in Drupal 8 can be published as a web service. You can even do a lot of what they call headless Drupal implementations. That means you can use some of the more sexy frameworks, like Angular or React, to build out more intricate frontends, and still use Drupal as a CMS, but really as a web service.

Are there any features of the two platforms that could be improved to make it a better CMS?

I think they’re pretty evolved CMS’s. On both of them, platforms are getting into place to build right on the CMS’s without having to install them. Platforms like Acquia, WordPress.com, Automaticc. These platforms are profitable because from an enterprise standpoint right now, it is hard doing multisite implementations at that scale, managing all of the architecture, and stuff like that. From a technical standpoint, if you get into an enterprise, clients who says they want to be able to run a thousand sites on a single platform, that becomes difficult to do from a technical perspective. They both have the ability to support multisite implementations, but advancements in there to make those types of implementations easier to use and deploy would be a significant advancement for both platforms.

What should companies and clients expect in terms of cost for setting up a website, maintaining it, and adding new features?

For a very basic site, where you’re just taking things off the shelf – implementing the site with a theme that’s already built, and using basic content – I would say a customer can get up and running anywhere from two to six weeks, $20,000-30,000. Typically, those implementations are for very small sites. We’ve seen implementations that have run into the millions, that are pretty complex. These are sites that receive millions of hits a day; they have award-winning user experience and design, custom theming, integration with a lot of backend systems, etc. Those can take anywhere from six to twelve months, and $500,000 to $1 million to get up and running.

Can you give some insight into SEO and security when building a website?

The nice thing about Drupal and WordPress is that there are a lot of modules and plugins that will manage that, from Google Analytics to HubSpot, all sort of SEO engines. You can pretty much plug and play those things. It doesn’t replace the need for your traditional content marketing, analyzing those results and then making sure your pages have the appropriate content and keywords driving traffic into them, or whatever funnel you want. All your analytic tools usually have some sort of module or plugin, whether it’s Google, Salesforce, Pardot, or whatever. A lot of those things are already pretty baked in. You can easily get it up and running. That’s the nice thing about the SEO portion of it.

The other nice thing about it being open-source is that there are constant updates on sort of security. Using these CMS systems, because they tie to all the open-source projects, if you download a module, anytime there’s a security update for it, you’ll get alerted within your administrative interface. It’s usually just a one-click installation to install that upgrade for security patches. That’s nice, as you’re literally talking hundreds of thousands of modules and millions of users. They’re usually found and patched pretty quickly. As long as you stay on that security patching cycle, you should be okay. You could still do stupid stuff as an administrator. You could leave the default password, and somebody could get in, so you still have to manage those things. From a software perspective, as long as you’re using highly-active, contributed modules and the core, security patches and findings come out pretty regularly on those things.

As a company, because we do stuff with some regulated industries like banking and federal agencies, we usually have to go a level above on security. Take a WordPress site or whatever, we would actually remove that form the public so it couldn’t be hit from outside of a VPN or internal network, and then have it publish out actual content and static pages so the outside just doesn’t even connect to the back-end system. That does take some custom programming and specialty to do. Most people just implement your regular website with the appropriate security controls, and it’s not a big issue.

Are there any additional aspects of building a website or dealing with a CMS that you’d like to mention? Or any other CMS platforms you’d like to give some insight on?

For us, because we are such a big mobile player, we typically would say that, whatever you build, your CMS, obviously focus on user experience. Most people are doing a good job of that these days. One of the areas that is still a little weak is this whole idea of a content syndication. There’s still a big push where the content editors build webpages, and they want to control the layout, pages, etc. They get measured by the number of visitors to the website and all that stuff. I’m not saying that’s not important; however, we’re trying to push an idea of a web service content syndication. So, how you use these CMS’s to do that, so your content gets syndicated worldwide. It doesn’t necessarily have to be measured by how many people hit your website. It should be measured by the number of impressions.

For instance, with the work we’ve done at NASA, they announced the TRAPPIST-1 discovery of potential Earth-like planets. That drove a huge amount of traffic to the website, probably close to nine million hits that day. If you look at the actual reach of that content and NASA’s message – through the CMS’s integration with social media, with API’s that other websites were taking, with Flickr, that sort of thing – it hit over 2.5 billion social media posts. That’s an important thing to measure. How are you using your content management system more as a content syndication platform, opposed to just building webpages? USGS has also done a really solid job of this ‘create once, publish everywhere’ philosophy. I think people should be looking at content management systems as content management systems, not as website management systems.

We ask that you rate Drupal and WordPress on a scale of 1 - 5, with 5 being the best score.

How would you rate them for their functionalities and available features?

Drupal – 5 – We have a bias towards Drupal because it’s more enterprise-grade. It fits what a lot of our clients need. I think they’ve come a long way with both the 7 and 8 versions and have really brought down the cost of implementation and improved the ease of use.

WordPress – 4 – I think it’s fantastic. It’s obviously extremely popular and very easy to set up and use. I give it a 4 and not a 5 because it’s not as easy to extend to enterprise-grade implementations. For some functionalities, you still have to dig into core, and nobody wants to be modifying core modules.

How would you rate them for ease of use and ease of implementation?

Drupal – 4.5 for ease of use, because it’s not as easy as WordPress, and 4.5 for ease of installation.WordPress – 5 for ease of use, and 4 for ease of implementation. If you want to go out of the box, it’s a little more difficult. Configuring multisite is a real difficulty in WordPress.

How would you rate them for support, as in the response of their team and the helpfulness of available online resources?

Drupal – 4

WordPress – 4

Being open-source projects, there are a ton of people contributing. They’re very active, so you usually can get your answers. In many cases, to get something embedded into core, it does have to get reviewed by the organization, which is a bunch of volunteers for the most part. Because of that, it does take a while for things to get embedded.

How likely are you to recommend each platform for a client?

Drupal – 5

WordPress – 5

I think they’re the strongest CMS’s out there for the price.

How likely are you to recommend each platform for a user to build their own DIY website?

Drupal – 3

WordPress – 4  

If you’re going to build your own website, and you have zero technical skills, you might want to look into a Weebly, Wix, or something like that. There is a need to know how to do site-building if you use Drupal or WordPress. Somebody has to configure it and understand it.

How would you rate your overall satisfaction collaborating with each platform?

Drupal – 5

WordPress – 5

We implement on both of them regularly, and they’re really great. They solve the need for a lot of our clients to migrate from much more expensive legacy systems.

Clutch.co interview: https://clutch.co/website-builders/expert-interview/interview-mobomo-drupal-wordpress

Categories
Author

Magnifying glass over Google search bar

A few tweaks and modules later, Drupal has easy to build SEO friendly websites. To achieve it, there are two sides involved:

Below are a few things you can do to improve SEO on your website just by working with content (texts, images, files).

Text content

Title

When you create a page on a website, the page title you decide on is used in several different places so it's important to get it right and make sure it's clear and useful.

Page title will appear:

All of above are picked up by search engines, so it's important to include relevant keywords in your titles.

Page titles should be clear and descriptive. If titles are too long to fit into a menu, or if you want to have a different menu link then the page title you could use the 'menu link title' field to display.

Drupal has a feature that allows you to specify a 'menu link title', you can find this at the bottom of the edit page form in the “menu settings” tab > “Menu link title”.

Please note, spaces in titles will be converted into dashes in the url, so do not use  dashes in titles. Maybe you could replace dashes with a colon to avoid “double dashed” urls.

Meta description tag

The meta description is the excerpt that displays under the page title and site name on the search engine's results page. If it's not filled in, the body copy will be used instead. This may lead to a cut off excerpt, but you could manually fill the ‘meta description’, or use the ‘summary’ field to avoid it.

In Drupal, the body text field on a page is accompanied by a summary field. It is important to fill this in. Sometimes, it's used on the site as a teaser to promote users to click the page and read the full copy.  Remember, it will be picked up as the meta description for the page if no meta description was manually added.

Headings

When adding or editing content to the Body, in the WYSIWYG toolbar at the top of the text field, you'll see a dropdown with a few headings options. Commonly, you will have a choice of heading 2, heading 3, heading 4, and normal/paragraph.

When starting a new section on a page, use one of the headings defined in the dropdown. Headings are picked up by search engines and will contribute to your search rank.

Besides helping out with SEO, headings are designed to draw the reader's eye so that they are able to find what they were looking for much easier. They are also useful for good content structure if the copy is long.

For SEO purposes you should only have the h1 tag used once on a page. H1 is commonly the page title.

Anchor Texts

This is the text that links to something else. For example, if I would like to point you to the about us page, then the anchor text is the (commonly) blue text you see.

Search engines compare the text written in the anchor to the link “behind” it. So if they anchor text includes keywords or phrases that will add value over time.

Anchor text is read by screen readers so it plays an important role in complain with accessibility requirements.

Please make sure that your anchor text is also descriptive.

Length

As a general rule the copy should be as long as it needs to be. Online content is not read in the same way as printed content, so keep things concise, clear and straightforward bearing in mind the user experience, not only the SEO.

As a reference, some SEO advisers recommend around 200 words as a minimum for page copy.

Files (Images, documents)

Filenames

Filenames should follow the following convention to eliminate technical problems and to improve SEO.

Filenames should be also descriptive.

Some good examples are: mobomo-logo-red.jpg, partnership-agreement-2017.pdf

Reference: https://support.google.com/webmasters/answer/114016?hl=en

Alt Text

This is a descriptive text that appears if an image cannot be loaded and is also used by screen readers. So here SEO is directly implicated with Accessibility. It's especially important if the image also acts as a link.

This text should clearly describe the image.

Filesize

Main thing you should know about files in web: Large file sizes slow down page load.

Users tends to abandon pages if the load time is greater than 3 seconds. So search engines “don’t like” to direct users to slow sites.

So, you can help to keep the page speed to a minimum by making sure the files you add are light.

A general rule is to try to keep images filesize below 70k, this sometimes is hard especially with large images (banners for example), so let’s say images should not ever be larger than 600k.  

Format

All images should be saved in jpeg format.

Documents should be saved as pdf or doc (for editable documents).

Other

404 and 403 pages

We are going to set up these pages for you, but it’s important that you fill them with accurate content given your audience. For example, you could add a link to your Homepage here or to an Archive / Search page to help your audience finding what they were looking for.

Please note these points listed above are changes you can apply without any tech support, they are just Content edits you can apply by yourself when adding / updating content for your website.

Here’s a few SEO related Drupal modules that makes developers lives easier.

Categories
Tags
Author

code

You know the old saying: “This is how the world ends: not with a bang, but with a misplaced DROP TABLE.” Working directly with Drupal 7’s database is an arduous task at best.  It’s a sprawling relational system and it uses many space and memory saving tricks to be as speedy as possible.  Thankfully, there is a robust system of functions built into Drupal to help you change almost any setting from code--perfect if you want to automate changes upstream and features doesn’t do it for you.  Let’s go over a situation in which you may have been utilizing some of these functions.

Let’s say you finished your product (congratulations!), launched, and are onto fixing bugs and planning exciting new features for the future.  You’re knocking out bugs left and right like some high-flying Drupal ninja and you discover that using a field collection with conditional fields causes the field collection data to not save and all of your metadata is getting erased when certain conditions are fired.  With Cthulhu's hot breath on your neck, you talk to the client and realize a ray of hope: you don’t actually need a field collection there, a normal set of Drupal fields will do.  How do we go about creating the new fields, copying existing data, and deleting the old fields?

The first thing we do is create the new fields and attach them.  For this, we’ll need two functions: 'field_create_field()' and 'field_create_instance()'.  Both of these take an array of settings: field_name and type are we need for creating the field (also cardinality if you want to have multiple values for the field), field_name, entity_type, and bundle are required for creating the instances, though you will likely also want label, or it will otherwise default to the machine name.  So, we should have something that looks like this:

 

$name = [
  ‘field_name’ => 'photographer_name',
  ‘type’ => ‘text’,
];
field_create_field($name);

$instance = array(
  'field_name' => $name['field_name'],
  'entity_type' => node,
  'bundle' => article,
  'label' => 'Name',
);

field_create_instance($instance);

 

If you go check out node/add/article, you should see your new text field there.  Congrats!  Next, we need to get the data from the old fields and copy it into our new field.  For this, we’ll rely on the nifty function 'entity_load()'.  This takes two arguments, bundle name and an array of ids.  Since we are getting field collection items, we know the bundle name is ‘field_collection_item’.  We’ll need the IDs, but we’ll also need the field collection value that references the fields in each collection for later, so we’ll get them both at once.  It might be tempting to use 'entity_load()' to get them, but in this case you are quite safe using straight SQL, which also happens to be significantly faster.  That looks like this:

 

$entity_ids = array();
$field_collection_ids = array();
// Select the field collection id and the attached entity id from the db.
$query = db_query('SELECT field_producer_value, entity_id FROM field_data_field_producer');
$results = $query->fetchAll();
// Separate the ids
foreach ($results as $result) {
  $field_collection_ids[] = $result->field_scald_producer_value;
  // We need to reference the entity ID by the field collection value for simplicity later
  $entity_ids[$result->field_scald_producer_value] = $result->entity_id;
}
// It’s possible that you might get duplicate Field Collection IDs, so we make sure they are all unique
$field_collection_ids = array_unique($field_collection_ids);
// Load all of the field collection entities.
$field_collection_results = entity_load('field_collection_item', $field_collection_ids);

 

Now that we have all of the entity ids and field collection ids, we can get to the fun part: copying data! (You know you have been doing this too long when that is exciting.) What we want to do is loop through the field collection ids, load the the entity (that has the new field on it) by the id associated with the collection, copy the data from the collection to the new field, and save.  It seems like a lot, but it’s fairly simple:

 

foreach ($field_collection_ids as $field_collection_id) {
  // Load the entity the field collection is attached to
  $entity = entity_load('node', array($entity_ids[$field_collection_id]));
  // Copy the data from the collection field to the new field
  $entity[$entity_ids[$field_collection_id]]->photographer_name['und'][0]['value'] =
  $field_collection_results[$field_collection_id]->field_producer_name['und'][0]['value'];
  // Save!
  entity_save('node', $entity[$entity_ids[$field_collection_id]]);
}

A word of warning: depending on how many entities you are processing, this could take a long time.  As of Drupal 7.34, there is a memory leak in entity_save()--this means that each save will take slightly longer than the last. This is not a problem if you have only a few hundred fields, but when you get up into five and six digits, this script will take many hours. At that point, unless you have the time (and/or can run the script as a process in the background), you might want to consider investigating other options.

Okay, so the data is copied, the nodes are saved, and the elder gods have hit the snooze button.  Last thing you have to do is delete the old field.  We’re not going to do that, at least not yet. Instead, we’re going to delete the instances of the fields.  This will preserve the old field collection data, but remove the fields from the edit forms. This way, if something goes wrong, you don’t lose the data in the old fields and can try again if needed. You can go back at a later time, if you wish, after you have confirmed that everything is correct and delete the fields. Luckily, this is the easy part:

 

$instance = array(
  'field_name' => 'field_scald_producer',
  'entity_type' => node,
  'bundle' => article
);
field_delete_instance($instance);

 

And that’s it, crisis averted!  You no longer lose data and no longer have to worry about supernatural madness and death!  All you need to do now is run your script upstream with 'drush php-script' and watch the magic.

This sort of scripting can be daunting at first glance, but Drupal’s rich entity API can keep you from pulling out your hair or inadvertently causing an otherworldly alien intelligence from rising from the deep.  There are many more functions to take advantage of, and just about anything you can set with a click in the interface you can set in code, perfect for automation or locked down production environments.

Happy Drupaling !

Categories
Author

drupal-development-sketch-mockups

Navigating the administrative backend of Drupal can be daunting.  Here are some helpful things to consider while managing a Drupal development project.

Clearing cache

Knowing how to clear cache on Drupal is critical. During the development phase, chances are you will be looking at the site as developers are working simultaneously. Clearing Drupal cache should be the first step in troubleshooting as changes such as theme or module changes might not take place immediately. The easiest way to clear cache from the administration menu is Administration > Configuration > Development > Performance > click on ‘Clear Cache’. If your site uses the admin menu module, a shortcut easily accessible at all times on the top menu bar. So the next time something doesn’t show up as expected, try clearing the cache first!

 

Basic Drupal terminology

A lot of scary words can be thrown around while describing project requirements and needs. In order to get a better understand of the inner workings of Drupal development, here are some common Drupal terms you should familiarize yourself to.

 

Be aware of different user permission levels

Keep in mind that what you see while logged in might not reflect what other users might see. A lot of times when a client does not have access to something, it is most likely a permission problem. It is always helpful to have test accounts with various user roles so you can log into them and see exactly what other accounts are seeing.

Expecting manual configuration changes on production is risky
Things can become a bit sticky once a client is needing manual configuration changes made on production environment. If the right processes are not in place, the development environment can get out of sync very quickly. Always note the changes needed and make the changes to all the environments across the board so nothing gets lost. Another way is pulling the production database downstream periodically. You can also use the Features module to capture certain configuration changes so it is committed in the codebase (however, there are limitations to this module).

Categories
Tags
Author

/drupal-8-migration/

First things first, what is Drupal 8? Well, Drupal 8 is the biggest update in Drupal history. It is said to be way easier to create content and every built in theme is responsive design. With over 200 new features, Drupal 8 has made its appearance. Drupal 8 is an improved suite of tools and features not seen in Drupal 7 and can be the application backbone for your projects. A few months ago we discussed how you can benefit from Drupal 8 . But now, let's talk about migration and things you may want to consider. 

Drupal 8 Migration:

Apple comes out with a new iPhone every how many months? Joking, but we all know that it seems like they are constantly creating a mad rush for people to upgrade to the next best thing. Same is true with Drupal, there is no right or wrong time to migrate to Drupal 8, however, if you want to be up-to-date with the latest cutting edge technology you typically choose to migrate just as you would get the newest version of the iPhone.

Things to consider whenever migrating to Drupal 8:

What are your Drupal needs? Feel free to get in touch so we can discuss your next Drupal project.

Categories
Author

drupal-nasa-website-monitor

A content management system, or CMS, is a web application designed to make it easy for non-technical users to add, edit and manage a website. We use Wordpress and Drupal the most for CMS development, but it is all dependent on our clients' needs. Not only do content management systems help website users with content editing, they also take care of a lot of behind the scenes work.

Whenever it comes to developing a website from scratch, and for a client who wants to be able to manage the site after the launch it is important as a developer to find a tool that the client will be able to use. When we think about web development it’s always better for the client and for the company to find a good content management system or CMS, because it solves problems that you will never have to worry about from the UI of the backend to the front-end wanted features it solves a lot of issues upfront that you will not have to worry about later.  As a website evolves, it will never stay in the final version you delivered to your client, when we develop we need to always think to the site’s future.

Wordpress is one of the most popular tools because it is very adaptable. The amount of plugins (solutions to your problems) are endless. Not only does it have great features but it has a friendly UI backend. All of the advantages mentioned lower the development time, which helps the client to lower their costs. In short, Wordpress saves time and money! The most recent example is our very own website Mobomo.

Another resource for a CMS is Drupal. Drupal may be a little more difficult to develop with because it can handle bigger sites with much more data and a ton of users but this system is better for newspapers or government sites such as NASA. 

Each CMS will have their own advantages but our first priority is making it adaptable to the client’s needs.

 

Categories
Author
‹‹ 4 ››
Subscribe to Drupal