Feb 27 2019
Feb 27

If you’ve spent time looking for a website support partner, you’ll quickly realize that while there are a lot of options out there, they’re not all created equal. Keeping your goals in mind will help you find an agency with an approach that best meets your needs.

If you’re simply looking for software updates and security patches, there are a lot of options out there. But if you’re looking for a strategic partner to support your site, the search for the right fit can be a bit more challenging.

At Kanopi Studios, we cover the basics, but that’s just the beginning. Our support team focuses on continuous improvement and growth-driven design, ensuring long-term growth for your website. We can jump in at any stage of your site’s lifecycle to make sure you’re meeting your goals and getting the most out of your investment. And when it’s finally time for an upgrade, we can help with that too!

Here are a few details that set Kanopi’s support services apart:

Customer service is our #1 priority.

Our team goes the extra mile to provide stellar customer service. We’re here to make your life easier, regardless of the size of your account.  

Added value and strategic guidance

As part of your monthly support budget, you’ll gain access to experienced designers, user experience strategists, developers and more. When it’s time to go beyond bug fixes, you’ll have experts in your corner to help your site respond to changes in the market or shifts in your business priorities.

You’ll work with real humans!

Our full-time support team manages every detail of your account. We analyze incoming requests, make sure we have the details needed to get the job done right, and respond within an hour, all without a single bot in sight.  

A dedicated, senior-level team

Our support team focuses on support. We know that it takes a different set of skills, energy, and dedication to handle rapidly changing priorities and keep the issue queue clear. Our experienced team has identified and resolved nearly every issue imaginable. We encourage you to check out their bios so you can see their qualifications for yourself!

A partner you can trust

Kanopi Studios supports more than 135 active websites. Due to the great relationships we’ve built, we’re still working with some of the very first clients that signed on for our services. In fact, most of our work comes through referrals from happy customers. We welcome you to check out our five-star reviews and get in touch to learn more about ensuring long-term growth for your website.

Feb 22 2019
Feb 22

Whether you’ve just recently built a new site, or you are in charge of maintaining an existing one, it’s critical to leverage the most you can out that site on an ongoing basis. As the internet grows and audience needs change, your site needs to be maintained and adapted over time. Sites can also be expensive to upgrade if not properly cared for (think of not performing regular maintenance on your car for several years until finally it breaks in an expensive way).

And yet, most organizations don’t have the money to redo a site more than once every three or four years. Sometimes they often don’t have the money to hire someone in-house to maintain the site beyond content updates. Who takes care of your security updates, or changes to modules or plugins so that your site doesn’t break?

That’s where quality website support and maintenance comes in. A good support agency can make your site last a long time past its creation date and keep it fresh until it’s time for the next rebuild and redesign.

Here’s are the top five things to look for when hiring for outside website support:

  1. Make sure they have a dedicated support team or department. Don’t go with an agency that simply pulls people off of regular design or development build projects to do support tickets on the side. Your site won’t get the same attention or care, since they consider support more of a side gig rather than an important part of their business model. Make sure the agency has a dedicated team that is committed to and organized around supporting sites.
  2. Look for transparency in billing. Make sure you understand the billing options. Most companies will offer different levels of packages, each with a set number of hours. If you have a site with a lot of traffic and ecommerce for selling items to customers, you’re going to want immediate service if something goes wrong vs. a site that’s more informational and can wait a few hours before a fix is implemented. Understand the levels of service you’re getting and the differences in costs for the timeliness of the response. Also ask what happens with any unused hours paid for in advance: do they rollover to the next month, or are they “use it or lose it?”
  3. Ask if you can talk to a human if needed. All agencies use (or should use) a ticketing system in order to track support requests. Ticketing systems allow for transparency, accountability, and clarity on what is being addressed and when. While these systems are tremendous for tracking the progress of an issue as it gets fixed, using them exclusively can be frustrating if something is hard to explain via text. Ask the agency if you’re allowed to hop on a call with one of their support staff, or the Project Manager, for advice and guidance. Often you can save time and increase clarity to simply have a conversation with a human. Plus it’s nice to establish a relationship with the person in charge of keeping your site running smoothly.
  4. Check that there’s a diverse range of talent within the team. Most developers can do module, plug in and security updates. But can they do any front-end work? What if the theme breaks, or you need a new page design? You might need more than code updates. Go for a more diverse and creative team that has experience with feature development as well as creative enhancements to cover all the range of items you might need.
  5. Determine how important it is if they work in your time zone. Talented designers and developers are all over the globe, but it can be tough to get fast responses from people in time zones very far off from yours. What happens if you need something right away, but it’s the middle of the night for them? If you’re in Hawaii, for example, you may not want to have an east coast agency handle your support. Ask the agency what their hours are, and try to get serviced in as close to your time zone as possible.

Following these tips will help give you confidence that you are asking the right questions and finding the right support services to fit your organization.

If you’re interested in learning more about Kanopi’s support offerings, contact us. We have dedicated support teams for both Drupal and WordPress, with a diverse staff who can cover anything you need. We also do it very well. Our hours are 9:00 am to 5:00 pm your local time in North America . . . and that counts for Hawaii!

Aug 29 2018
Aug 29

Image of a task board with MVP tickets

Image of a task board with MVP tickets

Congratulations! Your Boss just gave you approval to build the website you’ve been pitching to them for the past year. A budget has been approved, and you have an enthusiastic team eager to get started. Nothing can stop you… until you receive the deadline for when the website has to go live. It’s much earlier than you planned and there just simply isn’t enough hours in the day, or resources available to make it happen. Whatever will you do?

Let me introduce you to the minimum lovable product, or MLP.

What is an MLP?

You may have heard of a minimum viable product (MVP). Where a minimum viable product is a bare-bones, meets your needs solution; the minimum loveable product can be described as the simplest solution that meets your needs and is a positive step toward achieving your goals. It’s easy to view every aspect, every deliverable, as being fundamental to a project’s success. But when you actually look at each nut and bolt with a more discerning eye, you begin to realize that each component is not fundamental to the overall product’s success.

So basically the MLP is the sufficient amount of features your site needs to be satisfactory to your business goals for launch.

It’s important to note that an MLP is not necessarily a reduction in scope. It’s more a prioritization in the order for which things are addressed. The project team can circle back on anything that wasn’t part of the MLP. The goal behind an MLP is to deliver a functional product that you’re excited about, within the confines of the project.

When should you consider an MLP?

An MLP isn’t for every project, but is usually best leveraged when there is a restraint of some sort. I used timeline as an example in my opening, but as you know restraints can take many forms:

  1. Timeline: Maybe the deadline you need to hit, simply won’t provide enough time to complete all the work you have queued.
  2. Resource Availability: Perhaps there are scheduling conflicts, or limited resource availability during your project.
  3. Budget Constraints: Another possibility is that the budget just isn’t sufficient to get to everything you have on your list.

Regardless of the restraint you’re facing, an MLP can help you realign priorities, and expectations to compensate. But how do you go about evaluating your project for an MLP?

Need help with defining your MPL? Contact us.

How do you create an MLP

When you’re able to parse the individual elements that are crucial to your website’s success into user stories and features, you’ll have effectively identified your project. But how do you actually go about separating the core building blocks that will comprise your MLP from the bells and whistles?  It all starts with goals.

Goals

Chances are that you already have a set of goals describing  what you’re hoping to achieve with the project. These ideally should be as specific as possible (ie. increase traffic) and ideally measurable (analytics). Without realistic, concrete goals you set the project up for failure. For example if your goal is to make people happy; chances are you’re going to have a hard time measuring whether you were successful. Establishing measurable goals will set the project up for success.

It’s not enough to know your goals, you have to be able to prioritize them. It’s simply not realistic that every goal be top priority. Try to narrow your priorities down to no more than three goals. Goals in hand where do we go from here in our quest to define an MLP?

Definition

Begin by thinking of all the factors that are needed for a User to accomplish a given goal. These could include anything from Layouts, to Features, to Content. Start a list of these factors:

  1. What are the things a User sees?
  2. What copy does a User read?
  3. What actions is a User taking while they navigate through the site?

Everything you write down while asking these questions should be in the interest of one of your priority goals. If an item isn’t directly contributing to accomplishing the goal, then it should not be on the list. If you’re not a subject matter expert that will be directly contributing to the work, you should connect with your team to determine the specific work that needs to be carried out for each of the items you’ve identified. Additional refinement, and further simplification may be needed to compensate for the restraint you’re up against.

By this point, you’ve probably realized that defining the MLP is a difficult task. The choices will be tough, and ultimately everyone is not going to get their way. What’s important is that the work you do strives to meet the goals you’ve set. This sometimes means detaching personal wants from the needs of the company. If you can tie the work back to this core philosophy, you’ll always have a strong direction for your product.

Time to get to work!

All done? Congratulations! You’ve now defined your MLP. Now you’re off to the races. Best of luck on the journey of building out your minimum loveable product.

Jan 18 2018
Jan 18
January 18th, 2018

What are Spectre and Meltdown?

Have you noticed your servers or desktops are running slower than usual? Spectre and Meltdown can affect most devices we use daily. Cloud servers, desktops, laptops, and mobile devices. For more details go to: https://meltdownattack.com/

How does this affect performance?

We finally have some answers to how this is going to affect us. After Pantheon patched their servers they released an article showing the 10-30% negative performance impact that servers are going to have. For the whole article visit: https://status.pantheon.io/incidents/x9dmhz368xfz

I can say that I personally have noticed my laptop’s CPU is running at much higher percentages than before the update for similar tasks.
Security patches are still being released for many operating systems, but traditional desktop OSs appear to have been covered now. If you haven’t already, make sure your OS is up to date. Don’t forget to update the OS on your phone.

Next Steps?

So what can we do in the Drupal world? First, you should follow up with your hosting provider and verify they have patched your servers. Then you need to find ways to counteract the performance loss. If you are interested in performance recommendations, Four Kitchens offers both frontend and backend performance audits.

As a quick win, if you haven’t already, upgrade to PHP7 which should give you a performance boost around 30-50% on PHP processes. Now that you are more informed about what Spectre and Meltdown are, help with the performance effort by volunteering or sponsoring a developer on January 27, 2018 and January 28, 2018 for the Drupal Global Sprint Weekend 2018, specifically on performance related issues: https://groups.drupal.org/node/517797

Web Chef Chris Martin
Chris Martin

Chris Martin is a support engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Dec 22 2017
Dec 22

Designers mapping out a website.

Designers mapping out a website.

So your site isn’t working the way you want it to. Maybe it’s sluggish, or you’re not seeing the conversions you want, or customers are complaining. Before you drop a huge chunk of your budget on a complete rebuild, consider that there might be a simpler (and more affordable) solution to your website woes.

We see a lot of Drupal 7 and WordPress websites here at Kanopi Studios, and we often discover that it’s more cost-effective for our clients to simply update their sites rather than rebuilding them. Making targeted updates can allow you to focus on addressing a few key issues, while still leveraging the investment of time, energy and funds that went into your site’s foundation.

In this series, we’ll look at three key topics to consider:

1. How do you know when it’s time for a change?
2. Is your website optimally organized and designed to be user-friendly?
3. How strong is your technical foundation?

How do I know it’s time for a change?

Do any of these problems sound familiar?

  • Low conversion rates
  • Site pages take more than 3 seconds to load
  • Site doesn’t work well on mobile or other devices
  • Updating content is a difficult and frustrating process
  • Users struggle to find what they need on the site or have shared negative feedback
  • Site crashes when updating
  • Too many bugs
  • Building new features is difficult or may not even be possible
  • Site is not loading on https and triggers security warnings

If your answer to any of these is yes, it’s time to take action.

But first … is it really that important for me to address these issues?

Yes! A website that isn’t working optimally can dramatically affect your bottom line. An out-of-date or poorly designed website can:

  • Damage your credibility. If your website loads slowly, is crowded with clutter or is just plain not working, you are sending the message that your company is unprofessional.
  • Make you appear out of touch. A dated website tells your customers you are behind the technological times, or worse – you don’t care enough to stay up-to-date.
  • Cost you customers. Every customer who leaves your site in frustration due to broken links, complex forms, slow pages or confusing navigation is a customer you won’t get back. If your competitors offer similar services and have a stronger website experience, your loss will be their gain.

Decision time. If you want to avoid the damage that a dated website can cause, you’ll need to either rebuild your site or update it. If you’re ready to take action, we can help you find the best and most cost-effective approach.

There are two primary things to consider when maximizing your site’s ROI: your user’s needs and the technology that drives your site. If you can identify and fix problems in both of these categories, you can most likely avoid a costly rebuild.

Venn diagram showing optimum website health at the intersection of smart user experience and strong tech foundation.

Venn diagram showing optimum website health at the intersection of smart user experience and strong tech foundation.


Next, we’ll dive a bit deeper into tips to help you level up your user experience and update your website technology without starting over from scratch. Consider it the non-surgical, diagnostic approach to improving your website experience right where it needs it the most. 
Dec 22 2017
Dec 22

Now that you’ve decided that it’s time to take action to improve your website, It’s time to see if any user experience upgrades could help. Take a look through our list of issues below, and the tips to help resolve them.

Having a hard time converting leads or getting sales?

If you’re not sure why you’re not generating business from your website, it’s time to get serious about strategy. Here’s how:

  • Add a survey to your website to understand what users are looking for
  • Take a look at your analytics to understand where you are losing your users. If you don’t have analytics installed, get either Google Analytics or Tag Manager set up on your site.
  • Try an online user testing platform like Hotjar to help you go beyond standard analytics with heatmaps, visitor recordings, conversion funnels and more.
    Complete a User Experience & Conversion Optimization Audit with Kanopi Studios. We can make a whole range of insightful recommendations within your budget. Contact us to learn more.

Does your site take forever to load?

If it takes longer than three seconds, you have a problem.

  • Use Google PageSpeed or Pingdom to test your site’s speed, understand what might be slowing it down and take action to resolve any issues.
  • Make sure you have a reliable hosting company backing your site at the right level for the amount of traffic you receive.

Does your site work on mobile? Is it accessible?

It’s vital to make sure your site is accessible to everyone, no matter what device or screen size they are using. Here’s how to check:

  • Try using your site on a phone or a tablet. If you have to pinch or zoom to interact with the content, it’s time for a responsive design.
  • Make sure you can tab through all navigation and content on your site using only your keyboard, that all images have alt tags, and that you are able to use a voice browser to “read” your pages out loud. If not, you are missing key elements of accessibility.
  • Contact Kanopi Studios about an accessibility audit. We can help you identify the issues and build a plan for how to resolve them.

Is it frustrating – or impossible – to update content on your site?

If it’s a major undertaking to change even the simplest thing, something needs to happen.

  • Define your ideal workflow, then ask an expert to take a look and see how you can optimize the backend.
  • Consider the types of content that your site needs to support. Do you have templates in place that meet your needs? If not, it may be time to consider a bit of design and development time to build additional page types on your site.

Getting negative user feedback?

If the people visiting your site are taking the time to complain, chances are they might also take the time to help you make things better. Here’s how:

  • Collect feedback by sending out a survey, or document your customer service calls.
  • Always thank people for taking the time to help you improve.
  • Look for trends in the information you are receiving from users and build a plan to address any issues to help meet their needs

If none of the issues above apply, congratulations! Your user experience is likely more solid than many of the websites out there! But there are still more things to consider before committing to rebuilding your site. In our next post, we will walk you through a number of common technical issues and some helpful fixes for them.

Dec 22 2017
Dec 22

Website developers considering code.

Website developers considering code.

Now that you’ve considered your user experience, there are a number of possible technical fixes that might help resolve your website problems.

What version of Drupal or WordPress are you using?

  • WordPress 2, while old, may or may not require a rebuild. You might be able to get by with updating and refactoring.
  • If you’re using Drupal 7 or WordPress 3, a rebuild is likely not needed. 
  • However, if you are on Drupal 6, it is at the end of its life, which may make rebuilding more cost-effective and viable for the long term.

Does your site use a lot of custom code?

If so, what does that code do, and are you still using that functionality? Look for ways to streamline where possible.

Is your site’s code a nightmare?

Did you use a professional firm with a North American team? An offshore team? A freelance developer? Or an internal employee who no longer works at your company? It’s a good idea to get the code reviewed so that you can determine its quality and understand whether it will be easy to update or if you’d be better off starting from scratch. Contact Kanopi for a low-cost assessment.

Are you up to date with the latest security patches and updates?

Lapses can expose the site to hacks and backdoors. Often just updating your site and modules/plugins can solve many issues.

Want to learn more about how we can help you understand every aspect of your site and determine if you need to rebuild or update to help achieve your goals? Contact us to book a free 15-minute consultation. Click here to book a time.

Nov 13 2017
Nov 13

Business people working on project in office

Business people working on project in office

By now you have likely heard quite a bit about Drupal 8. But do you have a good sense of when and why to make the switch?

Switching to Drupal 8 will make new features and functionality available for your site and help you stay current with the latest best practices. But it will take time and effort, and may mean a bit of refactoring as well.

What’s new in Drupal 8?

Drupal 8 adds a number of helpful features into core, making it possible to build fully-featured websites out of the box. Drupal 8 takes care of basic needs, so contributed modules can be reserved for specialized functionality.

There are more than 200 new features in Drupal 8, including built-in support for multilingual and mobile-friendly sites, a simplified content authoring experience with in-place editing, native web services, Views integration into core, stronger HTML5 support and much more.

In addition, Drupal 8 is written in well structured, object-oriented PHP based on the Symfony framework. And it leverages the Twig templating system, making design patterns simpler, faster, more logical and more secure.

Once you are on Drupal 8, you can easily take advantage of minor releases that will add powerful functionality on a predictable schedule, without requiring you to reinvent your site. And the focus on backwards compatibility beginning with Drupal 9 means upgrading between major versions won’t be a massive headache like it has been with past versions of Drupal.

Time to switch?

There are a number of factors to consider when deciding to switch to Drupal 8. In general, the sooner you can bring your site up to the most up-to-date standards, the better. But it’s also important to consider your objectives when deciding on the best time for an upgrade.

If the functionality in Drupal 8 would revolutionize the way you do business, or you are considering rolling out significant new functionality, now might be a good time to switch. But if your Drupal 7 site is running well and there aren’t any solid business reasons to make the switch, you may consider holding off until Drupal 9 becomes available.

To help clarify your decision, we’ve created a quiz to help you determine when it’s time to make the switch.

May 18 2016
May 18
teaser image for blog post

In this blog post I'll discuss some methods of ensuring that your software is kept up to date, and some recent examples of why you should consider security to be among your top priorities instead of viewing it as an inconvenience or hassle.

Critics often attack the stability and security of Open Source due to the frequent releases and updates as projects evolve through constant contributions to their code from the community. They claim that open source requires too many patches to stay secure, and too much maintenance as a result.

This is easily countered with the explanation that by having so many individuals working with the source code of these projects, and so many eyes on them, potential vulnerabilities and bugs are uncovered much faster than with programs built on proprietary code. It is difficult for maintainers to ignore or delay the release of updates and patches with so much public pressure and visibility, and this should be seen as a positive thing.

The reality is that achieving a secure open source infrastructure and application environment requires much the same approach as with commercial software. The same principles apply, with only the implementation details differing. The most prominent difference is the transparency that exists with open source software.

Making Headlines

Open Source software often makes headlines when it is blamed for security breaches or data loss. The most recent high profile example would be the Mossack Fonseca “Panama Papers” breach, which was blamed on either WordPress or Drupal. It would be more accurate to blame the firm itself for having poor security practices, including severely outdated software throughout the company and a lack of even basic encryption.

Mossack Fonseca were using an outdated version of Drupal: 7.23. This version was released on 8 Aug 2013, almost 3 years ago as of the time of writing. That version has at least 25 known vulnerabilities. Several of these are incredibly serious, and were responsible for the infamous “Drupalgeddon” event which led to many sites being remotely exploited. Drupal.org warned users that “anyone running anything below version 7.32 within seven hours of its release should have assumed they’d been hacked”.

Protection by Automation

Probably the most effective way to keep your software updated is to automate and enforce the process. Don’t leave it in the hands of users or clients to apply or approve updates. The complexity of this will vary depending on what you need to update, and how, but it can often be as simple as enabling the built-in automatic updates that your software may already provide, or scheduling a daily command to apply any outstanding updates.

Once you've got it automated (the easy part) you will want to think about testing these changes before they hit production systems. Depending on the impact of the security exploits that you're patching, it may be more important to install updates even without complete testing; a broken site is often better than a vulnerable site! You may not have an automated way of testing every payment permutation on a large e-commerce site, for example, but that should not dissuade you from applying a critical update that exposes credit card data. Just be sure you aren't using this rationale as an excuse to avoid implementing automated testing.

The simple way

As a very common example of how simple the application of high priority updates can be, most Linux distributions will have a tried and tested method of automatically deploying security updates through their package management systems. For example, Ubuntu/Debian have the unattended-upgrades package, and Redhat-based systems have yum-cron. At the very least you will be able to schedule the system’s package manager to perform nightly updates yourself. This will cover the OS itself as well as any officially supported software that you have installed through the package manager. This means that you probably already have a reliable method of updating 95% of the open source software that you're using with minimal effort, and potentially any third-party software if you're installing from a compatible software repository. Consult the documentation for your Linux distro (or Google!) to find out how to enable this, and you can ensure that you are applying updates as soon as they are made available.

The complex way

For larger or more complex infrastructure where you may be using configuration management software (such as Ansible, Chef, or Puppet) to enforce state and install packages, you have more options. Config management software will allow you to apply updates to your test systems first, and report back on any immediate issues applying these updates. If a service fails to restart, a service does not respond on the expected port after the upgrade, or anything goes wrong, this should be enough to stop these changes reaching production until the situation is resolved. This is the same process that you should already be following for all config changes or package upgrades, so no special measures should be necessary.

The decision to make security updates a separate scheduled task, or to implement them directly in your config management process will depend on the implementation, and it would be impossible to cover every possible method here.

Risk Management

Automatically upgrading software packages on production systems is not without risks. Many of these can be mitigated with a good workflow for applying changes (of any kind) to your servers, and confidence can be added with automated testing.

Risks

  • You need to have backups of your configuration files, or be enforcing them with config management software. You may lose custom configuration files if they are not flagged correctly in the package, or the package manager does not behave how you expect when updating the software.
  • Changes to base packages like openssl, the kernel, or system libraries can have an unexpected effect on many other packages.
  • There may be bugs or regressions in the new version. Performance may be degraded.
  • Automatic updates may not complete the entire process needed to make the system secure. For example, a kernel update will generally require a reboot, or multiple services may need to be restarted. If this does not happen as part of the process, you may still be running unsafe versions of the software despite installing upgrades.

Reasons to apply updates automatically

  • The server is not critical and occasional unplanned outages are acceptable.
  • You are unlikely to apply updates manually to this server.
  • You have a way to recover the machine if remote access via SSH becomes unavailable.
  • You have full backups of any data on the machine, or no important data is stored on it.

Reasons to NOT apply updates automatically

  • The server provides a critical service and has no failover in place, and you cannot risk unplanned outages.
  • You have custom software installed manually, or complex version dependencies that may be broken during upgrades. This includes custom kernels or kernel modules.
  • You need to follow a strict change control process on this environment.

Reboot Often

Most update systems will also be able to automatically reboot for you if this is required (such as a kernel update), and you should not be afraid of this or delay it unless you're running a critical system. If you are running a critical system, you should already have a method of hot-patching the affected systems, performing rolling/staggered reboots behind a load-balancer, or some other cloud wizardry that does not interrupt service.

Decide on a maintenance window and schedule your update system to use it whenever a reboot is required. Have monitoring in place to alert you in the event of failures, and schedule reboots within business hours wherever possible.

Drupal and Other Web-based Applications

Most web-based CMS software such as Drupal and Wordpress offer automated updates, or at least notifications. Drupal security updates for both core and contributed modules can be applied by Drush, which can in turn be scheduled easily using cron or a task-runner like Jenkins. This may not be a solution if you follow anything but the most basic of deployment workflows and/or rely on a version control system such as Git for your development (which is where these updates should go, not direct to the web server). Having your production site automatically update itself will mean that it no longer matches what you deployed, nor what is in your version control repository, and it will be bypassing any CI/testing that you have in place. It is still an option worth considering if you lack all of these things or just want to guarantee that your public-facing site is getting patches as a priority over all else.

You could make this approach work by serving the Git repo as the document root, updating Drupal automatically (using Drush in 'security only' upgrade mode on cron), then committing those changes (which should not conflict with your custom code/modules) back to the repo. Not ideal, but better than having exploitable security holes on your live servers.

If your Linux distribution (or the CMS maintainers themselves) provide the web-based software as a package, and security updates are applied to it regularly, you may even consider using their version of the application. You can treat Drupal as just another piece of software in the stack, and the only thing that you're committing to version control and deploying to servers is any custom modules to be layered on top of the (presumably) secure version provided as part of the OS.

Some options that may fit better into the common CI/Git workflows might be:

  • Detect, apply, and test security patches off-site on a dedicated server or container. If successful, commit them back to version control to your dev/integration branch.
  • Check for security updates as part of your CI system. Apply, test and merge any updates into your integration branch.

Third-party Drupal Modules (contrib)

Due to the nature of contrib Drupal modules (ie, those provided by the community) it can be difficult to update them without also bringing in other changes, such as new features (and bugs!) that the author may have introduced since the version you are currently running. Best practice would be to try to keep all of the contrib that the site uses up to date where possible, and to treat this with the same care and testing as you would updates to Drupal itself. Contrib modules often receive important bug fixes and performance improvements that you may be missing out on if you only ever update in the event of a security announcements.

Summary

  • Ensure that updates are coming from a trusted and secure (SSL) source, such as your Linux distribution's packaging repositories or the official Git repositories for your software.
  • If you do not trust the security updates enough to apply them automatically, you should probably not be using the software in the first place.
  • Ensure that you are alerted in the event of any failures in your automation.
  • Subscribe to relevant security mailing lists, RSS feeds, and user groups for your software.
  • Prove to yourself and your customers that your update method is reliable.
  • Do not allow your users, client, or boss to postpone or delay security updates without an incredibly good reason.

You are putting your faith in the maintainer's' ability to provide timely updates that will not break your systems when applied. This is a risk you will have to take if you automate the process, but it can be mitigated through automated or manual testing.

Leave It All To Somebody Else

If all this feels like too much responsibility and hard work then it’s something Ixis have many years of experience in. We have dedicated infrastructure and application support teams to keep your systems secure and updated. Get in touch to see how we can ensure you're secure now and in the future whilst enjoying the use and benefits of open source software.

Nov 11 2015
Nov 11
teaser image for blog post

Launched in 2008 Drupal 6 has served a large base of sites for the past 7 years even with the more recent Drupal 7 launched in 2011.

As a provider of Drupal support and hosting services Ixis still look after a number of clients who are running the latest up to date Drupal 6 codebase. However, with the announcement of Drupal 8 launching on November 19th 2015 this starts the countdown to the end of the extended support policy - which is 3 months after the launch of Drupal 8. The final 3 months will only cover security updates - not functionality or bug fixes.

Drupal 6 Security Updates end on February 24th 2016

The 3 month window won't be long enough to allow upgrading of Drupal 6 sites to Drupal 8, especially as we'd always advise allowing a new major Drupal Core release to be tested by early adopters before upgrading and migrated your site to it.

What are the implications of this?

From Drupal.org

  • The security team will no longer provide support or Security Advisories for Drupal 6.
  • All Drupal 6 releases on project pages will be flagged as not supported.
  • At some point in the future update status may stop working for Drupal 6 sites.

From Ixis

  • We will continue to provide our support services to Drupal 6 sites and where necessary apply any security updates provided by 3rd parties.
  • We cannot guarantee your Drupal 6 site would not become vulnerable over the coming years as new attack vectors are discovered in web based applications and applied to old Drupal 6 sites.

What if I have a Drupal 6 site still?

If not already in progress, begin planning a site upgrade or rebuild. Web technologies have progressed a lot since 2008 which may mean reviewing how your Drupal 6 site works and what the business needs are - which may be better addressed in a more modern techniques thanks to the functionality of Drupal 8.

As with many of our long standing clients Ixis can assist with your journey from Drupal 6 to Drupal 8 with our in-house development team services. Now is the time to be making plans!

Any short term solutions?

  1. Reducing your sites functionality to content only would allow a quicker path to migrate to Drupal 8, and then as contrib modules are upgraded to 8.x re-introduce the functionality during 2016.
  2. Archive the site as static HTML pages - although this will remove interactive elements such as logins and comments.

What about upgrading to Drupal 7?

Depending on the timeframe and functionality required for site delivery Drupal 7 may still be the better option due to the sheer number of stable additional contributed module components available, such as Ecommerce.  At Ixis we're still developing Drupal 7 solutions for the next few months at least.

Speak to us

If you're unsure where the Drupal 6 support end of life announcement leaves you and your business website please do get in touch with us to discuss how Ixis can help in the short and long term. We're happy to chat!

Apr 28 2015
Apr 28

Lately, I have found myself involved in several discussions on improving the performance of Drupal sites. This can be a deep subject, with many different ways to approach it. In this blog post, I want to highlight three very simple methods to boost the speed of your site and share some raw data to show how much of a boost these measures can provide.

In a nutshell: Use Views Caches, the Page Cache, and CSS/JS Aggregation for better site performance. If you work in Drupal development every day, you know this all too well, but for some actual, benchmark comparisons, read on.

Before I go on, I will recognize that this is a fairly well-covered subject. People talk a lot about site performance. Perhaps it’s because at least one study has demonstrated that a 2-second delay in site load times can increase abandonment rates from 67% to 80%. The reason to bring these three methods up, however, is that they are such simple measures, they are often overlooked. It could be that no one remembered to turn these settings on, or perhaps developers were debugging an issue at one point and disabled something during their investigation, which they never re-enabled. It happens. What I would like to drive home is the importance of these simple measures, backed up by hard data. Also, for these reasons, I recommend using modules like Prod Check, or Site Audit, which will alert you when your Drupal site is not as well optimized as it should be.

For the analysis below, I used a tool called Apache Benchmark. It is well known in the development community, and can simulate large volumes of traffic visiting a site. One option the tool provides is the ability to output results in a csv file that provide a range of percentages (0-99) with a corresponding number of milliseconds (ms). This means that for each percentage, that percentage of requests were served under the corresponding time. These graphs are cumulative, e.g. 20% were served in 500 ms or less, 60% were served in 800 ms or less, and so on. I enjoy using this tool so much, I’ve incorporated it into a script I am developing to provide a consistent suite of tests to evaluate a site’s performance. In each of the following examples, I’ve simulated 1,000 requests, with 10 concurrent requests at a time.

 If you are running a Drupal website, you are almost certainly using the Views module. Views provides a lot of options for building and rendering lists of content. However, probably the most overlooked option in Views is its caching ability. By default, caching in Views is disabled.Turning it on gives you two options: (1) caching the query results and (2) caching the rendered output. You should use whichever timing you are comfortable with. Be aware that longer cache times will delay the appearance of new posts in the View. One helpful module to get around this is the Views Content Cache, which will expire cached views whenever similar content is updated. This might be often if your site is really active, so consider simply being at peace with semi-stale content. Your site will perform a lot better and your users will be happier for it.

So what kind of boost does this provide? Let’s compare three views. In a clean install of standard Drupal, I’ve created 1,000 article nodes through devel_generate and created three different views — one view with the default 10 items per page, another with 100 items per page, and a third with 1,000 items per page. Here is the result comparing each page with no caching whatsoever and versions using the cached views (using Views Content Cache, not that this matters).

cachetable

The 10 items per page saw a decent decrease in response time. The actual means were 1,626 ms for no cache and 1,407 ms for the views cache, a 219 ms decrease. The effect is significantly more pronounced as we raise the number of items rendered on the page.

cachetable2

The change here in mean request time was from 3,741 ms to 1,483 ms, a 2,258 ms difference. Note the spike at the end represents early requests made before the cache was “primed.”  Better still, look at the effect when we have 1,000 items per page.

cachetable3

When we talk about caching, we usually talk about caching in layers. If one layer of the cache is bypassed, then the layer below is always available to catch it. If you want to take the deep dive in caching in Drupal, here is a great video from DrupalCon 2014. A layer above the Views cache would be the Drupal page cache. This is the mechanism that will actually store the rendered page in a database, which Drupal will serve to the next user until the page expires or the cache is cleared. Let’s just look at the effect of the 100 items per page.

cachetable4

We managed to cut down the mean response rate to 178 ms, a 1,637 ms difference or a 90% decrease in response time! You probably can see that I forgot to clear all the caches prior to the Page Cache test run as it’s priming started at the level of the views cache.

If you have enabled the page cache and don’t feel like you are getting any improvement, you can look at your http headers to confirm that it’s working. Remember, this will only work for anonymous users. If you see:

X-Drupal-Cache: Hit

Then you are hitting the page cache! But if it says Miss, then something may be amiss (see what I did there?). A quick note to developers: if you ever use the $_SESSION global variable in Drupal, then users, including anonymous ones, will be given a session cookie, which means that pages will not be cached for that or any user with a session. A full code review of a site can turn up any usages of this.

Thus far, we’ve focused on improvements that can be described as “back-end enhancements.” They alter the way the software behaves to reduce the time it takes to render the page, which shortens what we call the “time to first byte.” This signifies the point at which the end user begins receiving data from the site. This value is critically important, because it is the initial request that will initiate all the other assets your end user will still need to download, including CSS, javascript, images, fonts, animated gifs of cats, and whatever else you might need to deliver to the user. Each of these items also has its own time to first byte, but until the initial page begins to download, your browser won’t even know to go fetch those items.

Another point to consider is that most browsers only download five to eight assets at a time. So if your page has 80+ items that need to be downloaded, they will need to wait in turn until all assets before them have been downloaded and an asset download slot is available. This means that pages with a lot of assets can take a while to download. Which brings us to the next absurdly simple way you can increase site speed.

Aggregation is the act of taking several of the assets used on a page, combining them into one file, and directing the user to download that file instead of the source version. In Drupal, if you look at the page source, without aggregation, you will see that it includes something like this:

 <script type="text/javascript" src="http://localhost:8080/misc/jquery.js?v=1.4.4"></script>

With aggregation turned on, it will change to something like this:

<script type="text/javascript" src="http://localhost:8080/sites/default/files/js/js_xAPl0qIk9eowy_iS9tNkCWXLUVoat94SQT48UBCFkyQ.js"></script>

With much fewer of these individual references. Now here is where we run into issues with the tools we are using to measure performance. The benchmark tool we have been using doesn’t actually download secondary resources like the javascript and css assets we are aggregating. In general, getting consistent, reliable, benchmark data is pretty difficult. So in my attempt to demonstrate what aggregation can actually do, I need to turn to more anecdotal evidence.

The Procedure

In my own browser, I’ve opened up the developer tools network tab, performed five hard refreshes, and recorded the load time for each. I performed this same procedure for both an un-aggregated and an aggregated page.

Without Aggregation

The Data: 232, 254, 310, 236, 216

Average Page Load: 249.6 ms

With Aggregation:

The Data: 209, 247, 188, 194, 213

Average Page Load: 210.2 ms

It appears that on average, my test site provided a 39.4 ms reduction in total load time, or 15.79%. So there you have it, we started with a page requiring over 1.5 seconds to load and brought that down by nearly 90% with just the simple tools available by default in Drupal. Do you know when it gets even better? When Drupal successfully serves a cached page, the visitor will then start using the “If-Modified-Since” header, so future requests aren’t even downloaded. Average load time for these types of requests was around 130 ms.

It’s 2015, so we can’t talk about Drupal without talking about Drupal 8. What’s new in the world of performance in the next big release of Drupal? The promise is faster loading across the board, thanks to the symfony framework. As far as the configuration options, like the ones we described above, are concerned, all the same tools are still available. The new exciting feature here is tag-based caching available, by default, in Views. This has the potential to provide functionality, like the Content Cache to core, to Drupal 8 views, but in a much more sophisticated way. Cache-based tagging will allow tagging of cache entries with arbitrary values, e.g. a node id, or a language to a view. This allows us to clear the caches later when appropriate, without clearing unrelated caches. This blog post by Dries summarizes the strategy perfectly.

These three suggestions, which anyone with administrative access can do, can make the difference between your site handling a few simultaneous users to handling hundreds and possibly even thousands at once. The above are just the basic, quick wins that any site administrator can perform, with some data on just how much of a boost the three steps can provide. If you are a developer looking for more advanced techniques on improving your site’s performance, below are a few additional ideas. If you aren’t sure how to go about these, get in touch with us, and we can talk about what Forum One can do for you.

  • Optimize images/reduce number of images used
  • Reduce number of social media widgets
  • Enable compression
  • Disable database logging or use syslog instead
  • Keep software up to date
  • Change backend cache to Memcache or APC
  • Use the Entity Cache (which complements the above suggestion nicely)
  • Use a reverse proxy caching tool like Varnish
  • Lazy load images
  • Defer javascript loading
  • Use a CDN
  • Configure webserver to serve serve static assets directly, i.e. avoid routing requests for images and javascript files through Drupal.

Previous Post

What do HeroRATS Have to do with Social Media?

Next Post

Why You Should Help the Nepalis, and How to Start

Mar 11 2015
Mar 11

Come and join our well established UK team as a senior Drupal support engineer. We support interactive sites and applications of all kinds, so every client can offer different challenges and solutions each month.

You'll have the opportunity to be involved with projects ranging from international brands, enterprise public sector organisations through to charities and media sites. We also run several internal projects which you'll have chance to provide input and development for if you wish - this is where we often experiment with new ideas, techniques and technologies first!

The technical skills we're looking for:

  • Excellent knowledge of Drupal & its configuration.
  • Extensive experience with Panels, Views, Features.
  • Experience of working with a source code version control system.
  • Comfortable using a terminal command line.

The type of person we’re looking for:

  • Strong analytical, problem solving, and debugging skills.
  • Ability to forge strong relationships with colleagues, clients and suppliers.
  • Calm, considered and methodical.
  • Excellent verbal and written communication.
  • Excellent time management with the ability to handle a varying workload, while maintaining a high quality of wor

Ideally you'll have 1+ years commercial experience of working as part of a team.

Your work will cover a variety of areas, including:

  • 3rd line support for complex cases from our clients.
  • On-boarding of large Drupal sites to our service desk and platform.
  • Preparation and participation in regular client Service Reviews.
  • Extending existing Drupal projects which may have been designed and developed by a 3rd party agency.
  • Internal projects to create or improve our services.

As you may notice, we love Drupal! There's a chance to play with the latest tools and contribute back to the Drupal open source community as part of your daily work.

Most importantly we’re looking for somebody who is friendly, positive, enthusiastic and hungry to learn as part of our team.

Training

We actively encourage staff to further their web skills by attending and presenting at conferences, camps and training days.

Ixis have sponsored, organised and attended Drupalcon Europe, DrupalCamps and DrupalDevDays.

Location

Ideally we would like your work to be carried out on-site at our lovely office in Warrington, Cheshire, UK, but we may consider remote working depending on experience and ability. You will be required to visit the office throughout the year so ability to travel is necessary.

There may also be some occasional travel involved for client meetings from Scotland to the South East and anywhere in-between. Therefore this position will only be suitable for UK residents.

Why Work For Ixis?

We've been in the Drupal business for over 10 years, it's all we do, whether it's providing consultancy, architecting solutions, providing support services, developing sites or hosting large scale projects. We think it keeps our staff focused and highly skilled experts in our industry. We care about the open source software we use - and ensure we contribute our time and code back to the projects in our day to day job.

Our business is always growing and this is the perfect time to get onboard, helping us to shape the future of Drupal and its implementation in the UK and Europe.

We work with a wide range of high calibre clients and are well respected by both the Public and Private sector in consultancy, development, support and hosting. We host and support some of the biggest UK public sector sites.

We run a fun, friendly, and relaxed office environment as well as regular evening and weekend activities with the team.
As a perk of working on site you’ll be treated to the very best development environment hardware in the shape of a well specced 27” display iMac.

The Details

Position: Full-time.
Apply: Submit your cover letter and CV using the form at http://www.ixis.co.uk/job-application
Hours: We work 35 hours per week with a flexible start or finish time to fit around busy traffic periods and family commitments.
Holidays: 33 paid days per year.
Salary: £25,000 - £32,000
Training: An individual budget for training/conference/event ticket fees, accommodation, travel and time off for learning is provided each year.

No recruitment consultants to contact us please.

Oct 25 2014
Oct 25
teaser image for blog post

We are delighted to be working with the British Council on a new Drupal hosting and infrastructure support project. The British Council are valued clients, and we have worked with them for more than 6 years managing both the global suite of 150 country sites, and the prestigious suite of Drupal teaching and learning sites.

We will be working to to create four individual platforms for hosting key Drupal websites on, moving away from just one main infrastructure, to improve resilience, efficiency and increase availability to the sites which generate more than 35 million page impressions per month and are used by more than 65 million people each year alone.

Will also continue to provide 24/7 Drupal website support to the sites which include Learn English, Teaching English and Premier Skills English.

Martin Heineberg, websites and media coordinator for the British Council, said: “Having worked with Ixis for more than six years, we knew we could rely on them to provide the right solution for hosting the websites. As Drupal hosting and support experts, they are always quick to respond and resolve any rare instances involving technical issues.”

We are looking forward to getting started with this hosting and support project, which will be one of the largest Drupal infrastructures in the UK.

Read more at on the Prolific North Website

Jan 21 2011
Jan 21

The Problem

We lack a clear and inviting path from discovering Drupal and learning how to use it to becoming an active and productive contributor. As a result, our most active developers are plagued by the support demands of intermediate users who have outgrown the Drupal.org forums and don't know where to go. This effect is compounded both by our failure to attract and assimilate new highly qualified support-givers, and the myriad bad behaviors that newbies are learning in "newbie ghettos" such as the forums -- behaviors that make it difficult-to-impossible to adequately support them and bring them into the wider Drupal community.

The Solution

  • Phase out the Drupal.org forums in favor of a more straightforward Q&A format resource.
  • Treat posts that resource as not just the answering of this question here and now, but building a useful searchable reference into the future. Be brutal in eliminating off-topic chatter and duplication (but as kind as possible in explaining why a question was closed) ala StackExchange.
  • Provide easy gateways from that resource to more active participation in the Drupal community: IRC, issue queues, doc team, translation teams, GDO, etc.
  • Improve the consistency of IRC and Q&A moderation by setting up a venue for moderator docs and discussion.

Rationale

Why is this important?

Most users' first community interaction will be in the form of seeking support. That support-seeking experience will form the basis for how they interact with the Drupal community in the future.

If we can sufficiently improve our primary support venue, we can expect:

  • Fewer people trying to get support in inappropriate ways, such as by clogging the issue queues or demanding the personal attention of our most active devs every time they have a problem.
  • More new Drupal consumers to eventually evolve into active Drupal contributors.
  • Fewer behavior problems in IRC and the issue queues.
  • Users utilizing a search engine to solve their Drupal problems to get more useful results more often.
  • The Drupal learning curve to seem a little less onerous to new Drupallers.
  • Giving support on Drupal.org to suck a lot less for the support-givers.

What is wrong with what we have now?

  • The most active, experienced Drupallers are not active in the Drupal.org forums due to:

    • Poor signal:noise ratio
    • Too much overhead (read: time suck) in following discussion on the webforums
    • A format that does not lend itself to passive participation (i.e. following well enough, with a minimum expenditure of energy, that one would know if a question one actually wants to answer has come up)
  • The support mailing list suffers from the above, plus:

    • Poor searchability
    • Publication of participants' email addresses
  • Intermediate and advanced questions in the venues above get too few helpful responses. There is no clear path to the "next level" of community participation and support. Thus, the post-newbie spillover tends to land in the issue queues, developers' inboxes, and other places where it interferes with active development.

  • Though the forums especially, and to a lesser degree the support mailing list, are sometimes praised for their low barrier of entry due to the lack of behavior corrections present on IRC and the issue queues, this comes at an enormous cost. These newbies visit our supposedly newbie-friendly support venues, learn behaviors (reinforced in the forums) that are exactly what keep the experienced folks out, then are shocked to be treated with less than total acceptance in more active venues. After all, they learned the behaviors we taught them. Why shouldn't they fit in? They're doing it "right".

  • Of course, some newbies never make it that far. Many get caught in the forum cul-de-sac and never find their way to the vibrant, geeky community that really powers Drupal.

What could we be doing better?

A new support venue should:

  • Make it easy for participants to understand the venue's expectations, and how to best get support.

  • Encourage behaviors and approaches (RTFM, search, ask smart questions) that will serve one well throughout one's entire Drupal career, not just among other newbies.

  • Be thoroughly indexed and easy to search. Ideally, this should be part of the main drupal.org search so that the support-seeker has as few places to search as possible.

  • Reduce duplication as much as possible so that answers are clearer and easier to find, and volunteers aren't needlessly burnt out by having to explain how to log in to a Drupal site in maintenance mode 4,000 times.

  • Have extremely low participation overhead (that is, how much time you have to invest clicking around in order to ask/answer questions).

  • Have an extremely good signal:noise ratio.

  • Provide easy, obvious bridges to other parts of the Drupal community.

  • Be a great example of the culture surrounding Drupal, rather than an isolated ghetto not particularly representative of or connected with our community.

  • Address support questions across a broad range of skill levels and subspecialties within the Drupal ecosystem.

  • Successfully help people with their problems and questions regarding using, theming, and developing for Drupal.

Conclusions

  • In order to successfully address questions in all areas and at all skill levels, the support venue must be attractive to Drupallers with all levels of experience.

  • In order to be of the greatest utility to both individual Drupallers and the Drupal community as a whole, a community support venue should go beyond just answering the question at hand: it should act as a reference for future support-seekers to find, and nudge people toward the behaviors and attitudes that will make their Drupal experience successful in the long run.

  • The Q&A format would be a huge improvement over current venues for Drupal support, specificially because it:

    • Has a good track record. Drupal questions are frequently asked and answered on StackOverflow, and there are nearly 200 people committed on a proposal to add a drupal sub-site to Stack Exchange. (No, this site isn't going to be created, for reasons beyond the scope of this post.)
    • Has low participation overhead, while still being very searchable.
    • Helps teach newcomers the mindset that this venue is a place to get things done, rather than a place to visit (as forums tend to lead them to believe).
    • Puts moderators in the position of being able to close questions for not being real questions, for being duplicates, etc. without the lashback of confused forum users (who generally have expectations based on experience with discussion forums, not support venues).
    • Is an easier format from which to bridge users to proper IRC and especially issue queue behavior: the Q&A format is, in a way, an issue queue designed solely around support issues rather than coding, docs, etc.
  • NO support venue will serve the purposes described above without consistent, appropriate moderation. Consistency would be greatly increased if moderation procedures were documented, and if moderators had a place to privately sanity-check borderline situations before acting. Additionally, moderation standards should be set with the focus on encouraging the right attitudes and behaviors all the time, rather than letting things go until these poor attitudes become expectations and these poor behaviors become habits.

Dec 28 2010
Dec 28

Through out this series, the cost of labour has been identified as one of the biggest risks for this project. As most people who have run a tech business know, support can turn into a massive black hole of wasted time. Today we will look at how to manage support in a way that helps you avoid any direct customer contact for support.

Documentation and Online Resources

People like documentation, or even better videos, to walk them through a process. Invest the time up front to create documentation to help your customers use your platform. Only offer a single admin theme, such as Root Candy or Rubik or something you create yourself, this way the UI remains consistent and users are less likely to get confused. When developing the documentation, assume the user has no Drupal experience and talk in generic lay person terms, not "Drupal babble". You should include links in the Drupal interface back to your help system, so people can access contextually appropriate help. Consider having a FAQ for each discrete piece of functionality so people can get some idea of what it does without having to play with it for half an hour.

A lot of the documentation you generate will be specific to your business and only available to your paying customers, but some of it will have generic value to the Drupal community. For the more generally useful content, publish it in a public place, such as your blog, company website or contribute it to the appropriate section of the documentation on drupal.org. You will be benefiting greatly from the work of the Drupal community, you should be looking for opportunities to give something back.

The flexibility of Drupal means that you should be able to build a documentation system that suits your needs. You probably want to start by extending the book module.

Forum

From time to time people won't be able to find what they need using your online documentation. If you have a solid user base, a forum can be a good way of crowd sourcing your support resources. This doesn't mean you can just put up a forum and hope that your users will all help each other solve their problems, you need to be in there responding in a timely manner too. If you have some users who are contributing regularly in the forums, acknowledge that in their profile and even offer them some free time on the service - after all they're saving you money.

Support Tickets

Some users will want a more personalised approach to support. This will most likely involve email. When a user emails support directly, they will expect a timely response. This has the potential to add significant costs to your business, especially if you have a global customer base. One way to deal with this additional cost is to charge for it, offer packages of X incidents per month for Y dollars and put them on recurring billing. Most customers will forget to remove the recurring billing, but stop asking questions once they are up and running. There are various support systems available, I'll leave you to find the one which works best for you.

Chat and Telephone Support

Real time support channels such as chat or telephone can really eat into your bottom line. You need to have people sitting there waiting to take the "call", whatever time the customer contacts you and they may not call for a day. Accents and cultural issues can make it difficult to communicate effectively via the telephone. I would avoid offering any telephone support to customers.

Mailing Lists

A mailing list can be an effective way of communicating with your users. I'm not suggesting something like MailMan or Google Groups, I am talking about a one way announcement list. Check out MailChimp or Campaign Monitor to take care of this for you. Each month send out a newsletter with some useful tips, new features or announce other improvements to the service. Consider including case studies in the newsletter, which you can also feature on your sales site.

Customer Service

The cheapest way to build a business is through referrals or word of mouth. You need to look after your customers, so they become your sales team. Manage their expectations in terms of the support you offer them. Don't be afraid to cut a time sink loose, apologise, give them a refund and encourage them to find another solution. Support vampires can cost you a lot more than they're worth.

What's Next?

We are almost in the home stretch now. In the next post I will cover some of the business considerations in terms of what you offer to customer and how to upsell. The final post in the series will come later this week and will be a summary of the previous posts.

Jan 05 2009
Jan 05

forum icon

At last, I'm happy to announce the Code Sorcery Workshop support forums! These forums will gradually become the official support channel for our Mac products Meerkat and Pukka, as well as a place to discuss what's on your mind with regard to our website, potential future products, our services, or happenings in the Mac & Drupal communities.

The forums have been open for a week or two in unannounced form, but have quite expectedly not garnered much activity, so consider this the official "word". Feel free to go to it!

Feature Run-Down

We are using Drupal for the forum solution, which is what is used for the rest of the website as well. I'd like to take a moment to go over some of the features that this provides. In the near future, I also hope to make another post about the more technical details, such as which modules were used, what kind of custom solutions were implemented, and what administrative features are provided on the backend.

Main Page

The main page gives an at-a-glance view of the latest topics, much like any forum software. Posts are organized into containers, such as Mac OS X Products, and below that, forums addressing a particular product or group of topics, such as Pukka. When new topics are posted under a forum, they bubble up to the top.


Forums main page (click to enlarge)

Your Account

To participate in the forums, you must register for an account. With this account, you can maintain a unique identity across all of the posts. You can include as much or as little information as you like, currently including real name, photo or avatar, physical location, and website. This information is only available to other forum users -- only your username is available publicly.


Account page (click to enlarge)

In addition, you get a box in the right sidebar with easy access to My forum posts (posts created by you) and My forum votes (posts you've voted on).


User box

Search

Just like the blog archives and all of the pages on the site, forum topics are searchable. And these searches are able to be bookmarked, so you can easily check back frequently for updates related to a topic you are interested in.

Topic Voting

Aside from easy access to any forum topics that you may have created yourself, you can also vote on anyone else's topics using a zero- to five-star rating system. Perhaps the best use for this feature is that you can use this to flag topics that you are interested in periodically checking back on. Another use might be a tip that you really want others to see or a feature request that you'd like to weigh in on.

The popular topics get aggregated to a special page called top forum topics where they can be easily tracked. I'm hoping that this can be a useful way to chart the future direction of our applications, as well as to more easily resolve important issues affecting many customers.


Topic voting

Feeds, Feeds, Feeds

One of the strongest features of the forums is easy and plentiful RSS feeds. Currently, you can access feeds for:

  • Container activity: For example, all posts about Pukka. Just add /feed to the end of any container URL.
  • Topic activity: If you make a post, you subscribe to all comments on the post by clicking the link on the topic page or adding /feed to the URL.

Forum feeds (click to enlarge)

Conclusion

In conclusion, I'm happy to launch the forums and I hope that they will be of benefit to users of our products, Mac, iPhone, and Drupal enthusiasts, and folks interested in our services, for starters. Please, if you have any suggestions or feedback, consider using the General Discussion forum topic.

Enjoy the forums!

http://codesorcery.net/trackback/161

Jul 10 2005
Jul 10

The Drupal website has been down for two days now. They haven't received a response from support and hence cannot fix it (sounds familiar to me).

On the long run, Drupal will migrate to the Open Source Lab (OSL) which offers lots of services and already hosts many popular Open Source projects like Mozilla, Apache, and Debian.

To be able to do this, they need a new server (free rack space and bandwidth are provided by OSL) for which they are seeking donations now.
It's also planned to create a non-profit organization which will hold the funds, so the donations will be tax-deductible...

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