CAll Us: +1 888-999-8231 Submit Ticket

How To Protect Your WordPress Business From Insider Threats

How To Protect Your WordPress Business From Insider ThreatsIn January, users of the popular WPML WordPress plugin received a concerning email. It warned that there were serious security vulnerabilities in the plugin. The email came from a genuine WPML address, and customers had no reason to think it wasn’t legitimate. WPML is used on tens of thousands of WordPress sites, and a critical unpatched vulnerability could have been a security nightmare.

Except there was no vulnerability, and the email had been sent by a disgruntled former employee who had gained access to WPML infrastructure. The attacker used an old SSH password to gain access.

Insider attacks are not as rare as you might think. In a recent survey, 53% of respondents said that their organization had suffered an insider attack in the last year. Insiders are implicated in just under a third of all cybercrime breaches. A PwC survey showed that employees, service providers, and contractors are responsible for a huge number of security breaches. A third of executives reported that online crimes perpetrated by trusted insiders caused financial and reputation losses to their organization.

Insider threats are challenging to defend against. A certain level of trust is required for employees to do their jobs. If they choose to abuse that trust, there’s little a business owner can do about it until the damage is done. But there are steps that security conscious business owners can take to limit the risk of insider threats to their WordPress business.

Give Every Employee Their Own Account

Every employee and freelance developer, designer, or marketer should be given their own user account if they need an account at all. For every application or server they need access to, a unique account should be created just for them. There should be no shared accounts.

It is often more convenient to use shared accounts, which is perhaps what happened in the case of WPML. There should be no “old SSH” accounts to be used by anyone who happens to know the password. Consider how many other ex-employees and contractors may have had access to the same account.

Limit Access Using WordPress’ Roles And Capabilities

WordPress comes with a range of user roles, each of which has associated capabilities. A user given the Administrator role has full control over all admin features on a site. An Editor can publish and manage their own posts and the posts of others. An Author can only publish and manage their own posts.

Because you give everyone their own account, you can restrict their privileges to those they need to do their job.

Delete Accounts As Soon As An Employee Leaves

The main benefit of giving everyone their own account is that it can be deleted immediately if they leave. Once the departing employee’s accounts are deleted, they no longer have access to do mischief. When you hire a writer and give them access to publish content on your WordPress site, it’s a bad idea to let them keep their access forever.

Keep a record of which accounts an employee has access to, and delete them as soon as possible.

Educate Employees

Giving everyone an account with limited privileges is security commonsense, but it doesn’t help if employees share their passwords. There are many reasons to share passwords, and it is often convenient to give a co-worker a password so that they can access features and data they wouldn’t ordinarily be able to. But sharing passwords undermines security. Employees and contractors should be made aware of the risk and discouraged from sharing authentication credentials.

The security precautions we have covered are widely acknowledged to be the right thing to do, but they are rarely implemented. Why? Because it is inconvenient, creates extra work, and costs money. However, taking security precautions is not as inconvenient as the financial and reputational havoc of a security breach caused by an insider.

Posted in:
Hostdedi

Source link

Building Your Drupal 8 Site

Welcome to Part 3 of our series, Getting Started with Drupal 8. Go here for Part 2.

Last entry, you learned the basics of creating content, adding images, and dabbled in your first themes and modules. Before we start adding more your content — and we will in Part 4 — let’s look at some other fundamentals of managing your Drupal site.

 

Contents

Tailoring Your Site’s Identity

Although we installed a theme in Part 2, Navigating Drupal, this section uses the default theme, Bartik. If you are currently using a different theme, you can revert by selecting Manage > Appearance, locating the Bartik theme, then clicking Set as default.

 Tip: To stay focused on Drupal basics, this article does not explore Cascading Style Sheets (CSS), which are a powerful and effective way for a developer to customize a website.

Site Details

To start, view your current site as a user by opening an alternate browser where you are not currently logged in as an administrator. There’s a few ways to confirm you’re viewing it as a user, but the easiest is to check for the Log in option on the upper right.

It’s possible to move this, but we’ll cover that in a later entry.

First, let’s change your site name. From your admin menu, select Configuration > System > Basic Site Settings. In the SITE DETAILS section, fill the Site name and Slogan fields with whatever appeals to you.

The Email Address field is the email for the site itself, though it currently shows whatever email you provided when creating the site. You can change this later. This address will receive automated emails, such as password resets and other notifications. It is not what site visitors will use to contact you, which we will set later.

Scroll down to see areas to designate your site homepage (FRONT PAGE) and 403 (access denied) pages. Note where to find these, but leave them blank for now.

Click, then click  to view your changes as an admin. While you’re at it, check out your browser tab. This is your first step in search engine optimization (SEO), which makes it easier to search engines to find your site.

Regional Settings

From your admin menu, select Configuration > Regional and Language > Regional Settings.

Make necessary changes to the Default Country, First day of week, and Default time zone drop-down options.

Click  when done.

Adding Your Logo

If you don’t already have a logo, save the “FEARTHESQUIRREL” logo to your local device. You can always change this later.

From your admin menu, select Appearance, then click the Settings tab.

In the LOCAL IMAGE section, clear the Use the logo supplied by the theme checkbox. In the Upload logo image section, click   to upload your logo. Click   when done, then return to your homepage.

It’s a welcome replacement for the Drupal logo, but it clashes with the default blue at the top of the page. To fix it, select Appearance, then locate the Bartik theme and click Settings.

You will now see a COLOR SCHEME and Preview section.

 TipIf you are using a theme other than Bartik, this page may look different from our screen captures.

The Color set drop-down list is currently set to the default Drupal appearance, Blue Lagoon. It provides a handful of other options, but ignore those for now.

For the sake of learning the basics, we’re adopting a minimalist approach:

 TipAs you make changes, view the Preview section to see their effects.
  1. Set the Header background top and Header background bottom fields to pure white. You can use the color grid, or just enter FFFFFF in both fields.  
  2. Oops! The white background washed out our slogan and some of the other text. Change the Title and slogan field to black. Either use the grid, or enter 000000.
  3. Adjust the Sidebar borders field to black, just as you did in step 2.
  4. Click , then return home to check your work.
  5. As you can see in the preview, the site name next to our logo is redundant. Let’s remove it. Click  on the upper right.
  6. Click the   by the site name, followed by Configure Block.
  7. In the TOGGLE BRANDING ELEMENTS section, clear the Site name check box, then click .
  8. You can view your site from your home page, but now would be a good time to view it from your alternate browser so you can see it as a visitor would.

    Sparse but clean!

Adding Your Favicon

Let’s replace the Drupal favicon appearing in your browser tab with our own.

If you don’t already have a suitable Favicon, download the one shown below to your local device.

Select Appearance from your admin menu, then once again locate the Bartik theme and click Settings. Scroll down to the FAVICON section, then clear the Use the favicon supplied by theme check box.

In the Upload favicon image section, click  to upload your logo. Click when done.

Return to your home page to view your new favicon!

Setting Permissions and Roles

Drupal is designed for teams of multiple users. It is possible to tailor specific roles and permissions without adding modules.

Access your permissions and roles by selecting People from your admin menu.

Permission Fundamentals

 TipUse caution when assigning permissions, especially ones saying “Warning: Give to trusted roles only; this permission has security implications.”

Click the Permissions tab.

Drupal’s default installation provides three types of users; anonymous, authenticated, and administrator. Take a few moments to scroll through the list and take a glance at the default permissions for each type. You can customize any of these roles.

Anonymous users

Anonymous users are unregistered. Anyone visiting your site for the first time will be this type, and the View published content permission means they can view your site. Otherwise, they have very few permissions, but we recommend going one step further: disable their ability to contact the site using the site form. This will help prevent spam.

Authenticated users

Authenticated users represent users logged in with registered accounts. Unlike anonymous users, they can use shortcuts, contact the site, view basic HTML, and post comments. We’ll save the topic of comment moderation for a later entry in this series.

To set up the process by which anonymous users become authenticated users, go to your admin menu and select Configuration > People > Account Settings. Scroll to the REGISTRATION AND CANCELLATION section.

The default settings achieve a good balance of security and convenience for many sites. The current option under Who can register accounts?, Visitors, but administrator approval is required, means admins must approve any user attempting to become an authenticated user. The top option, Administrators only, means visitors wanting to become authenticated users must contact an admin directly, who will create the account on their behalf. Your choice will depend on the purpose and volume of your site.

Administrators

Administrators have access to all areas of the site. This role can be given to anyone. As the site’s creator, however, you are the superuser and it is not possible to change the superuser’s permissions.

 Tip: Protect your site by keeping the superuser role to yourself. Don’t share your superuser login credentials with anyone!

If you plan to have several people helping you work on your site, it is best practice to avoid handing out this role to everyone. Continue to the next section for details.

Creating Roles

You can designate different “flavors” of administrators by creating new roles. While the “how to build a site development team” question is outside of our scope, possible roles include:

  • Site builder: Researches and maintains modules, structure, and configuration
  • Site designer: Creates CSS and maintains appearance and aesthetics
  • Content manager: Writes, edits, and manages all site content; may oversee content writers
  • Community manager: Oversees content, permissions, and the comments
  • System administrator: Monitors and maintains site performance, security, and uptime

Drupal makes it easy to tailor permissions on an as-needed basis. To create a role, go to your admin menu and click People, then click the Roles tab. Click to get started.

In the Role Name field, enter a name, like “Content Manager.” Click when done.

Any new role you create begins with the same permissions as Authenticated Users. To customize them, click the Permissions tab.

For a content manager, we’d likely want them to have any permissions related to creating, editing, or maintaining content. Many of these are found in the Node section. The exact permissions for each member of your team will vary according to your needs, your team size, and other factors.

 TipAlways assign permissions with care, particularly any that change content or contain the phrase, “Warning: Give to trusted roles only; this permission has security implications.”

Giving Users a Way to Contact You

It is usually in your interests to make it easy for authenticated users to reach you with feedback about your site.

Go to your admin menu and select Structure > Contact forms.

For now, ignore the Personal contact form, which allow users to contact one another, not you. Go to the Website feedback option, then click .

In the Recipients field, specify the email addresses to receive the feedback. In the Message field, enter the message viewed by the user after they send you feedback. Click when done.

Test your work. Return to your homepage, click Contact, and walk through the process to see if it unfolds as you planned.

You can create additional forms, but without modules, you can only have on default feedback form at a time.

Reports to Rememgber

Your default installation of Drupal 8 provides you with reports to help you maintain your site troubleshoot issues. To view your options, go to your admin menu, then click Reports.

Available updates serves as a reliable way to check if you site is out of date. Running anything other than the latest stable version can expose your site to malicious activity. You can also subscribe your email address to update notifications by clicking the Settings tab. We also recommend following @drupalsecurity on Twitter and subscribing to RSS feeds for core security updates, contributed project updates, and public service announcements.

Recent log messages can help you monitor or troubleshoot your site. Use the Type and Severity filters to refine your search as necessary.  

Status report a general assessment of the “health” of your site and provides other system information. If you have a more serious error or warning, it will often, but not always, be found here.

Next Steps

See you soon in Part 4 of our series, Getting Started with Drupal 8! On deck is trying our hand at graphics, metadata, newsfeeds, sidebars, and a few other squirrely surprises.

Posted in:
Hostdedi

Source link

Miguel Balparda’s Adobe Summit recap

Miguel Balparda's Adobe Summit recap After a week in Las Vegas as a Summit Insider for the Adobe Summit, I’ve learned quite a few things about Adobe and their plans for Magento 2.

Adobe invited all of the Magento Masters to assist their annual event as Summit Insiders, a program that includes top executives, industry experts, major media correspondents, and pioneers in technology from around the globe.

 

 

 

 

Disclaimer: As a Magento Master, I attended the event for free, but these opinions are my own.

Day 1

The week started with an Insider’s presentation, reviewing previous years and also showcasing some of the new Adobe tools we should be using already, like Adobe Rush and Adobe Sign with its Office 365 integration. One of my favorite takeaways of going to this non-Magento event was getting to know the rest of the influencers and how they apply their different backgrounds to eCommerce.

After the introductory session, we headed to The Mirage for the Experience Maker Awards, an incredible private event including a reception and acts from The Beatles Love theatrical production by Cirque du Soleil. Several companies walked away with awards, with Platypus Shoes, a Magento 2 site, winning Best Commerce Experience.

Day 2

Day 2 started with the opening keynote, where Shantanu Narayen explained how Adobe sees the market and how their analytics point to retention as “the new growth.”

Right before the keynote, a new Techcrunch blogpost dropped, highlighting Adobe Commerce and how it integrates with Magento 2. Right after Santanu, Jason Woosley jumped on stage and explained to an audience of 16,000 what this meant for Adobe and Magento. Adobe Commerce is not a rebrand or a substitute for Magento 2, but a bundle of Adobe, Magento, and Adobe Experience Manager (AEM). This new product integrates with the Amazon marketplace to try to close the last gap in Adobe’s experience offering.

Right after the keynote, the Community Pavilion opened. This pavilion was immense, with huge demos showcasing integrations between Adobe products with VR and AR. I paid extra attention to the Adobe Experience Manager and Magento2 GraphQL integration, an interesting proof-of-concept that creates product pages using drag-and-drop predefined blocks with the Venia theme.

The day continued with sessions about different technologies. I assisted one with Magento Cloud, but my favorite was from Dr. John Grotzinger, chief scientist for the NASA Curiosity rover mission to Mars.

Right after, we were invited to go back to the 90s by experiencing the thrills of Rolodexes, floppy disks and VHS movie rentals.

After a long day, we moved to the Influencers and Media reception at CHAYO for some beers, tacos, and enchiladas. We met several Adobe enthusiasts and chatted about the future of Magento, with everyone agreeing we had much to be excited about!  

Day 3

Day 3 started with more sessions, with Shantanu Narayen and Microsoft CEO Satya Nadella taking the stage stage to talk about how Adobe and Microsoft work together to integrate their offerings.

Right after them, Reese Witherspoon and Adobe CMO Ann Lewnes took the stage to discuss how Reese launched her own production company and self-funded it for 5 years, making it possible to make her own decisions without shareholder interference.

After the keynotes, we headed back to the community pavilion to visit sponsors and take part in a Magento Masters Mixup meeting with Adobe employees. In this meeting, we met David Nuescheler, one of Adobe’s open source advocates and a key figure to follow if you’re interested in the future of Magento 2 open source.

 

The day wasn’t over yet and we headed to Sneaks, where Adobe showcases what’s to come in the near future. Hosted by actress, writer, and producer, Mindy Kaling, and Steve Hammond, Adobe’s Sr. Director of Experience Business in APAC, much of the focus was on AI and VR technologies.

After Sneaks, we gathered up some more Magento peeps and headed to the T-Mobile arena for Adobe Bash, the closing party featuring The Killers. There is not much to say about this, other than it was by far the coolest closing party I’ve ever attended! The Killers played all their hits in an arena just for Adobe, with plenty of food and drinks to go around.

After the party was over, I headed back to the hotel to rest up and start packing, but we had one day to go!

Day 4

Day 4 was all about Marketo and their Marketing Nation Summit, which is now part of Adobe Summit. I assisted with a couple of sessions, but took most of the day to get to know more Adobe integrators and developers and their ecosystem. One the day ended, I headed back home to Argentina to rest up and get ready for Magento Imagine in May.  

The biggest takeaway was how Adobe wants to include and integrate Magento into their offerings, and how we can work with other platforms to create a unique experience for our customers. Witnessing this first-hand helped me understand the size of Adobe (it’s HUGE), its potential for customers, and how those customers differ from the customer base we’re used to.. I’d say our builds will now become bigger and more complex, but with the correct developers and integrators, we can continue to consider Magento the leading eCommerce platform worldwide.

See you in Las Vegas next month for Magento Imagine!

Posted in:
Hostdedi

Source link

Hostdedi WAF Update Protects Against Magento Core SQLi PRODSECBUG-2198

Hostdedi WAF Update Protects Against Magento Core SQLi PRODSECBUG-2198On March 28th, a set of vulnerabilities for Magento Core were disclosed, one of which can allow an unauthenticated visitor to execute a SQL injection attack. These vulnerabilities are addressed in the most recent Magento security update and affect the following versions:

  • 2.1 (fixed in 2.1.17)
  • 2.2 (fixed in 2.2.8)
  • 2.3 (fixed in 2.3.1)

What Does This Mean?

A SQL injection attack can allow malicious actors to make requests against your website which execute queries on the Magento database. These requests can potentially read or write to the Magento database, allowing unauthorized access or changes such as adding an administrative user or reading hashed passwords, encryption keys and encrypted credit card data.

This particular vulnerability is troubling due to the fact that it requires no authentication and any website visitor can potentially execute a malicious SQL injection request against your web store.

How Is Hostdedi Handling This Disclosure?

Soon after receiving notification about this vulnerability, our System Operations team immediately started investigating mitigation strategies.

We found that our existing Web Application Firewall (WAF) rules were successfully mitigating a proof of concept of this vulnerability. However, there was room for improvement and possible conditions under which the vulnerability could still be taken advantage of.

Our System Operations team created an improved set of WAF rules for this vulnerability and successfully deployed them across our managed platform on the morning of March 29th.

To be clear, this mitigation only filters the currently known attack strategies for this vulnerability. It still remains critically important that you patch your Magento installation as soon as possible.

What Should I Be Doing?

While we’ve implemented the mitigation strategy, we would highly recommend still ensuring that you update your Magento installation to the newest version or that you patch (via the patch “PRODSECBUG-2198”, which is available here) your site to ensure that you’re completely protected.

Additionally, we’d recommend that you or your development team review your existing codebase to ensure that no malicious code was injected into your site prior to this vulnerability is disclosed.

As always, if you have any issues with doing so on your own or run into any problems there, please reach out to our Support team directly and we’ll do our best to help.

Posted in:
Hostdedi

Source link

Fixing Mixed Content Warnings On WordPress Sites

Fixing Mixed Content Warnings On WordPress SitesLast year, Google announced that over 75% of Chrome traffic was protected by HTTPS, a large increase on the previous year. The pace of HTTPS adoption accelerated as the cost, complexity, and performance implications were addressed. With Let’s Encrypt, anyone can get a domain-validated SSL certificate for free. Configuring a WordPress site to use an SSL certificate is easier than ever. Performance overheads are negligible for all but the largest sites. But there are still challenges to HTTPS adoption on established WordPress sites: mixed content warnings top the list.

What Is A Mixed Content Warning?

Browsers display mixed content warnings when an HTML page contains both HTTP and HTTPS content. They won’t load unsafe content in a supposedly safe environment. A fully-protected page is safe from snooping, but that can’t be guaranteed if there are non-protected elements on the same page. Browser developers want users to be aware of the risk to avoid instilling a false sense of security, so, in addition to blocking unsafe content, they display a warning. Google’s Chrome displays a warning icon in the space a padlock icon would appear for a secure site and a warning notification instructing users not to enter sensitive information such as passwords.

Mixed content warnings are caused by lingering HTTP links on a WordPress site that should serve content over HTTPS. It is challenging to make sure every link to every script or image is changed to HTTPS. Theme and plugin developers are sometimes less careful than they should be when including assets. A single errant image file can raise a mixed content warning and give visitors a reason to doubt the security of a page that is, in fact, perfectly secure.

Fixing Mixed Content Warnings

The first step in solving mixed content problems is to find the offending URLs. On a WordPress site with only a few pages, it can be done manually. Open each page and look for a mixed content warning. When you trigger one, open the browser’s developer tools. In Chrome you will find them under the More Tools submenu of the main menu. At the far right is an indicator of errors and warnings; click on it and Chrome shows a list of errors, including the assets that caused the mixed content warning.

Changing the URL protocol from HTTP to HTTPS should eliminate the warnings. If the content is not available over HTTPS, which is unlikely, you will have to provide an alternative source that is available over HTTPS.

For larger sites, checking each page is not an option. Tools like the free SSL Check crawl a limited number of pages and identity problematic URLs. Fixing the URLs can be done via a search and replace tool such as the one built into the WP-CLI utility. Read this guide and be careful; try this out on a test installation before running it on your live site.

In most cases, the following command will do the job:

wp search-replace 'http://example.com' 'https://example.com' --precise --recurse-objects --all-tables

Finally, a less permanent but easier solution is offered by the Really Simple SSL plugin, which dynamically alters URLs to include HTTP rather than rewriting database tables.

Posted in:
Hostdedi

Source link

Introducing the Hostdedi Product Life Cycle

Introducing the Hostdedi Product Life cycleWe’re proud to introduce a new approach to product releases, one that offers improved transparency and provides merchants and developers with increased peace of mind concerning the products and services we offer.

Our new product life cycle incorporates three main release stages and a retirement protocol. Each of these stages provides different levels of support, production readiness, and availability. Continue reading for more information and information on when a product is eligible for retirement.

Public Beta

The public beta is the first stage of the product life cycle. It is an early release of a product that may or may not become widely available at a later date. The public beta allows clients to provide feedback and for us to anticipate further product requirements before it becomes more widely available.

Because the public beta is an early release, we will only offer limited support. Our support team will try to help as much as they can, but limited experience with new products means it will not officially be offered.

Due to a lack of official support, these products will be available for free during the public beta period. This will change once products advance to the next stage: limited availability. We will notify all users before this happens.

We do not recommend public beta releases for use on production sites. They are primarily designed for testing and experimentation. There is a change that there will be bugs and unforeseen issues with public beta products, and it is possible that sudden changes will be made on the platform.

Limited Availability

Once we feel that a product has been suitably tested and is ready for a wider release, we will push it to stage 2: limited availability. During this release, specific user groups or regions will have access to the product/feature.

Limited availability releases will be ready for production workloads, but this is not guaranteed. This means that our SLA will apply in some cases, but will not be backed by credit issuance.

All limited availability releases will come with full support. That means that pricing will also be rolled out.

Once a product reaches the limited availability stage of its life cycle, the retirement protocol (as outlined below) will be applied. This means that we will not retire the product unless we can offer a suitable replacement. We will also be fully transparent about any upcoming changes to the product.

Public Availability

Once a product has reached the public availability stage of its life cycle, it will become available to all Hostdedi clients. This stage is a fully stable release that offers a production-ready product, with full SLA support and a standardized pricing model.

The Retirement Protocol

The retirement protocol applies to all products in either the limited availability or public availability stages of their life cycle. At these stages, we will only retire a product when we believe we are able to provide our clients with an alternate product that offers better value.

Because we understand that retiring a product can have a large impact on your site, we provide the following:

Reasonable Advance Notice

For minor changes, we will provide at least 1 months’ notice. In the case of major changes that will have a larger impact on client sites, we will provide at least 6 months’ notice.

Effective Alternatives

We will try our hardest to ensure that an alternative product is available for those impacted by one being retired. This may include a product or service offered by Hostdedi, or one provided by a reputable third party.

100% Support Until the Retirement Date

During the retirement process, we will not dial down support for products. This means that up until the last minute of a product’s availability, our support team will actively help you to get the results you need.

Note: that there are extenuating circumstances where we may have to accelerate the retirement protocol. This may be due to security issues or decisions made by third parties.

Summary of the Hostdedi Product Life Cycle

For more information on the Hostdedi product life cycle, please visit the knowledge library.


About the Author

Ryan “Master of the Web” Belisle

Ryan has worked with the internet and technology for around a decade. He currently works at Hostdedi helping to make the Product, WebDev, and Support teams awesome. Awesome technology and awesome people go hand-in-hand in building amazing things.

When he’s not working with the brilliant Hostdedi team, you can generally find him at a rock concert, behind his piano, or practicing mixed martial arts… or you can just find him on Twitter: @_ryebell


 

Posted in:
Hostdedi

Source link

What is Data Center Operations?

What is Data Center Operations?Be it Magento, WordPress, CraftCMS, or anything in between, your application needs reliability. It is our job in Data Center Operations (DCO) to make that a reality. The DCO team works around the clock to ensure our data centers and your websites remain online.

 

 

What is Data Center Operations?

The DCO team deals with infrastructure, security, power and cooling, and management. We build out and maintain server racks, monitor building security during non-business hours, actively monitor power and cooling systems to ensure they stay online, and perform maintenance on the servers that host your website.

The Equipment We Use

In DCO, we pay close attention to the status of every piece of equipment; from the Dell PowerEdge servers powering the thousands of websites we host, to the HVAC equipment cooling the data center. We’re able to keep track of everything with the help of our monitoring systems. These systems actively watch a large array of sensors, which alert us to potential or active issues as soon as they appear. Upon receiving an alert, the DCO team immediately takes action to resolve these issues.

In our servers, we also utilize a technology known as RAID (Redundant Array of Independent Disks). RAID helps us ensure that our clients’ data remains safe and intact. RAID allows us to replace faulty hard disk and solid state drives without any noticeable impact to our clients. For the most part, our clients will never even know anything has changed with their environment following a replacement.

Minimizing Downtime

While many of the issues we see are simple to resolve, others require careful planning and execution to avoid major website outages. Our monitoring systems help by providing early notification of problems. In most cases, we are able to reach out to clients to schedule downtime as a result. This allows for your website to be taken offline at a time that is least impacting to you while resolving the issues that could cause bigger problems in the future.

However, downtime can sometimes strike without warning. That’s why we keep a sufficient stock of equipment on hand to complete replacements as needed, ensuring that no client is left offline for an extended period of time.

Minimizing downtime at your data center

We are able to immediately act on issues thanks to our monitoring systems, but we still ensure that each server is backed up to an off-site location on a daily basis. As a wise person once said:

It is better to have something and not need it, than to need something and not have it.

In the event our team needs to utilize these backups to restore a server to service after a catastrophic failure, we have the ability to bring a server back from the dead in a matter of hours.

Most of what we do goes unnoticed, but the DCO team plays a pivotal role in ensuring your websites remain online and stable for visitors. Without the hardware that we maintain, we would be unable to run the necessary software to ensure that your website provides the best experience possible to your visitors.

Blog Post Summary


About the Authors

Nathan is a Data Center Technician with the DCO team at Hostdedi. He enjoys working with clients to help give them the right hardware needed for the best website experience possible. He also enjoys traveling and is an avid fan of the Ohio State Buckeyes.


 

Alan Cutshall is a Tier 2 Data Center Operations Technician at Hostdedi. He currently attends Western Governors University in pursuit of a Bachelors of Science in Network Operations and Security. Computers have been a life-long fascination of his. Throughout his time with Hostdedi, he’s been provided with countless opportunities to deploy, configure, and troubleshoot some of the latest and greatest hardware the market has to offer. The opportunities he’s been afforded have not only furthered his fascination with computers, but also taught him things he’s been able to translate to both his studies and his hobby equipment back at home.


 

Posted in:
Hostdedi

Source link

How Will WordPress 5.0 and the Gutenberg Editor Affect My Site?

How Will WordPress 5.0 and the Gutenberg Editor Affect My SiteWordPress has changed forever, and we’d like to say those changes are for the better. For many they are, for others, they have come with a lot of uncertainty. Mainly, how will WordPress 5.0 affect your website, and is the Gutenberg editor going to cause problems?

We’re not in the business of fear-mongering, so we want to reassure you that your website is almost certainly going to be fine. However, we’re also realists, and we know that site issues can spring up out of seemingly nowhere. This is why we always recommend making changes to a dev site before making them to your production site. With WordPress 5.0 being such a radical departure from the CMS’s previous iterations, if you were ever going to test a site update, now is the time.

This article will cover what WordPress 5.0 is, what it’s going to mean for your site and you, and how to make sure that everything is working perfectly the day you go live.

This is the Gutenberg Icon

What is WordPress 5 and the Gutenberg Editor?

Editing in WordPress, while relatively easy, has always had its downsides. Unique placement and sizing of page elements were awkward and for users that didn’t have advanced development knowledge, the answer was always been to install a plugin. The problem with this is that too many plugins can slow your site to a crawl and make user experience terrible.

WordPress 5 addresses this issue by providing much more “out of the box” functionality. The new Gutenberg editor offers users an interface that’s much more “you see what you get” than the classic WYSIWYG editor.

With this added functionality, some of the core features of WordPress have had to change. This has caused many site owners to ask whether WordPress 5 will break their site. We’re here to reassure you that it won’t as long as you take some simple precautions beforehand.

What’s Going to Change?

Your site itself won’t change too much with the new editor. That being said, there are going to be some changes to the way that you WordPress. Most of those changes are going to take place during editing.

You’re Going to Develop a New Workflow

It doesn’t matter how you make changes to your site, you are going to have to adjust to a new WordPress workflow.

At WordCamp US 2018, Matt Mullenweg talked about how previous versions of WordPress were not entirely compatible with Word. Copying content would often result in strange irregularities and problems in formatting. One of the goals Gutenberg has managed to achieve is the ability to copy and paste content while maintaining formatting. For WordPress users that don’t access the coding portion of the editor, this is huge.

The Editing Experience For Contributors Will Be Easier

If you have someone, or a group of people, that contribute to your blog periodically, the editing experience is going to get a lot easier for them.

The new Gutenberg editor interface is clean and easy to navigate. Functionality is quickly picked up, and how to access a certain set of features is easily applied to finding others.

Other tools that will make a new contributor’s experience easier include:

  • Drag and drop building through “blocks”
  • Preformatted “blocks” for different types of content (image, paragraph, header, etc)
  • Individual block formatting for placement and style
  • Simplified but powerful option menus

The types of Gutenberg Blocks

You’re Going to Use Fewer Plugins

… and this is a good thing. Too many plugins spoil the broth (or website), by increasing page load times and reducing the quality of user experience.

By offering a lot of advanced functionality through the Gutenberg editor itself, a number of features that basic users previously had to rely on plugins for are now included as standard.

The Current State of WordPress 5.0

Gutenberg has already had over 1.2 million active installs, with 86k posts being written and published daily. The fact that there are that many people already actively participating should put your mind at rest.

Of course, like any updated and changed piece of software, bugs do still exist. The main worry for many site owners and WordPress developers is how the new update will interact with plugins and themes.

WordPress 5.0, Themes, and Plugins

While many theme and plugin creators have spent time updating and ensuring compatibility with WordPress 5.0, there are still some that have not been updated – and possibly will not.

If you’re using a plugin that hasn’t been updated in several years and is still only technically compatible with WordPress 4.1, then you may have a problem. Luckily, the Gutenberg editor has added a lot of functionality to the default editing experience – potentially making your dated plugin redundant.

WordPress 5.0 and Page Builders

Another area of worry for many WordPress developers is how page builders will interact with the update. So far, we haven’t seen any issues. For the most part, because page builders are avoiding the Gutenberg editor entirely, pages created with page builders should remain stable.

Does this mean you shouldn’t test your site with 5.0 before you go live? Probably not.

How to Prepare Your Site for WordPress 5

Getting ready for the WordPress 5 update is simple… if you’re prepared.

The first step is spinning up a development environment to test how the update will affect your site. In the few cases that something is different, it’s probably not going to be sitewide, so testing each page for functionality and content is important.

If you’re hosting with Hostdedi, spinning up a dev site is simple, and can be done through your client portal. Start by going to Services -> Cloud Accounts, then find your WordPress environment in your list of services. Click the dropdown and select Add Development Account.  After a short series of steps, your dev site will instantly go live, complete with its own domain.

Spin up a dev site to test wordpress 5

Once you’ve spun up a test environment, you can then update WordPress through your Admin Panel. You can either select the small callout along the top or the huge callout just underneath the dashboard title.

Update to WordPress 5 through the admin panel example

What and How to Test

Testing your development site is similar to testing a site migration. In fact, we recommend following similar steps. This includes five primary different checks:

  • Content Presence
  • Content rendering
  • Loading behavior
  • Site links
  • Load times

While you’re testing the site, you’re also going to want to keep an eye on how plugins and theme elements react to the changes. This is largely going to be covered under content presence and loading behavior. You may find that something has loaded incorrectly, or behaves in a strange way. Identifying these problems is easy. Identifying load time issues is not.

Identifying Performance Issues

It’s important during any site change, to check whether performance has taken a hit. We don’t need to reiterate how much of an effect on conversion and bounce rate a slow site can have.

Luckily, checking site speed is easy, and can be done through Lighthouse. To check site speed with Google Lighthouse, you can follow our guide to auditing WordPress site performance.

The Bottom Line: Will WordPress 5 Break My Site?

The short answer is: probably not, but it’s better to be safe than sorry.

Gutenberg and WordPress 5 have already been adopted by so many people, with a comparatively small number of problems, that it’s unlikely you’re going to experience issues that haven’t been created by another user at some point.

Yet as per Murphy’s law, if you give something a chance to go wrong, it probably will do. Start off on the right foot with WordPress 5.0 and spin up a dev site.

Posted in:
Hostdedi

Source link

What Does PHP 5.6’s End-of-Life Mean For WordPress Users?

PHP 5.6 is the most widely used minor version of a programming language on the web. The PHP language is used on 79% of websites where the server-side language is known. PHP 5 is used on 58% of the web, and PHP 5.6 is used on around a quarter of all websites. It would not be an exaggeration to say there are millions of websites running PHP 5.6 — and also millions using older versions of PHP.

The statistics for WordPress are in the same ballpark: 35% of WordPress sites run on PHP 5.6. For a four-year-old piece of software, PHP 5.6 remains remarkably successful. It is also unsupported, receiving neither bug fixes nor security updates.

By the end of December 2018, PHP 5.6 hadn’t been actively supported for two years, during which time it received no bug-fix releases. Its official end of life was reached as 2018 came to a close, and, going forward, it will no longer be updated for critical security issues either.

PHP 5.6 and WordPress

WordPress recommends that hosting providers support PHP 7.3, which is the most recent version. At the time of writing, modern versions of WordPress will run on much older PHP versions, back to PHP 5.2.4, but, as WordPress’ developers make clear, using an older version may expose your site to security vulnerabilities. When WordPress 5.1 is released later this year, PHP 5.6 will become the minimum supported version, and sites using older versions may begin to experience compatibility problems. There are tentative plans to make PHP 7 the minimum supported version as early as the end of 2019, but given the huge install base for WordPress on PHP 5.6, it’s uncertain that this will actually happen.

Your site will continue to work. Although PHP 5.6 is no longer supported, WordPress sites that use it will continue to work for the foreseeable future. WordPress’ developers prefer site owners to use up-to-date versions, but they ensure that WordPress is compatible with older versions. However, it’s not guaranteed that WordPress will remain compatible with older versions forever or that developers will continue to support old versions for as long as they have.

Using older versions is a security risk. If a critical vulnerability is discovered in PHP 5.6, it won’t be fixed. It’s impossible to say how much of a risk this poses because no one knows if there are any critical security vulnerabilities in PHP 5.6. Over the last couple of years, numerous denial of service vulnerabilities were discovered and patched in PHP 5.6, but few critical remote code execution or privilege escalation vulnerabilities. After four years, the risk of show-stopping vulnerabilities is not high, but it is not zero.

New WordPress sites should use supported versions of PHP. There is no good reason to launch a new WordPress site on an unsupported version of PHP. Hosting providers that use outdated versions for new sites are negligent, knowingly put their clients at risk. Responsible hosting providers regularly upgrade PHP across their hosting platforms. Hostdedi offers the most recent supported version for new WordPress hosting accounts, although we continue to support older versions for clients who need them.

In summary, while there is no need to panic, hosting clients with sites based on PHP 5.6 should consider upgrading to a more recent version because there is a non-negligible security risk when using older versions of PHP.

Posted in:
Hostdedi

Source link

Using WordPress Logs To Understand Activity On Your Site

Using WordPress Logs To Understand Activity On Your SiteWordPress has a fairly simple interface, but there is a lot happening beneath the surface that you don’t see. Every page load and configuration change may trigger dozens of functions which, in turn, may trigger dozens more. Most of the time, the activity is hidden and that’s a good thing: you don’t need to know everything your WordPress site does behind the scenes.

But sometimes it’s useful to move the curtain aside and see what’s really happening. WordPress can communicate with you in various ways: it can send you emails, it can display notifications, but today we’re going to look at logs.

A log is a list of events, usually displayed in the order in which they occurred. Logs often include errors, but they might also include the day-to-day activities of your site.

Logs are useful for figuring out what is happening when it isn’t obvious from the interface. For example, you might install and configure a plugin so that a widget is displayed on the home page. If the widget doesn’t appear, you can look at log files for clues about what went wrong.

  Low activity may be due to slow site speed. Here are some simple optimizations to speed up your website

The WordPress Error Log

WordPress doesn’t produce a log of errors unless you ask it to. There are a couple of ways to get WordPress to generate an error log. We’ll look at doing it manually first.

In the root of your WordPress installation is a file called wp-config.php. It includes variable definitions and other code for configuring WordPress. You can edit this file by SSHing into your WordPress hosting account or by using an FTP client like Filezilla.

To turn on the error log, look for code that says:

define( ‘WP_DEBUG’, false );

 

Change it to the following:

define( ‘WP_DEBUG’, true );

 

This turns on debugging, but you also need to add another line so that WordPress sends errors to a log:

define(‘WP_DEBUG_LOG’, true);

 

Make sure that there is only one occurrence of the WP_DEBUG and WP_DEBUG_LOG  definitions in wp-config.php.

Now, if you look in your WordPress installation’s /wp-content directory, you will find a file called debug.log that contains errors and other useful information. As you carry out actions on your site, any errors generated by the site’s code are added to the log.

When you have finished using the log, it’s a good idea to turn off log generation by returning wp-config.php to its default state.

An easier option

If editing the wp-config.php file manually and viewing logs over Filezilla doesn’t sound like fun, you can use a plugin to toggle logging and view the log. WP Log Viewer allows you to turn logging on and off, and provides useful tools for downloading and viewing the error log.

  Get started with the new Gutenberg editor here

Comprehensive Logging

The error log doesn’t tell you everything that happens on your site. If you’re interested in logging comprehensive information about what your site is doing and what users are doing on your site, you need a plugin such as WP Security Audit Log.

WP Security Audit Log logs a huge range of information, including changes to posts and pages, user accounts, settings, the database, and more.

Posted in:
Hostdedi

Source link