Wordpress expert.
1904 stories
·
0 followers

How to Make Your WordPress Website Secure (SSL) in 6 Steps

1 Share

If you've looked into search engine optimization as a promotional technique for your website, you have likely come across the advice to make your website secure (having an https:// appear in front of your URLs instead of http://). Google has been very vocal in pushing for all websites to make the move to being secure,... Read More

The post How to Make Your WordPress Website Secure (SSL) in 6 Steps appeared first on Sugarrae.

Read the whole story
Share this story
Delete

why your conference should have a code of conduct

1 Share

I’ve been asked many times why a conference needs a code of conduct.  Depending on who’s asking, and whether I feel like taking on such basic education for a conference organizer, I give many answers: to increase attendance of women, to have a documented procedure of how to handle a situation, to do the right thing.

There have been many articles written about the problem of harassment at conferences.  The most recent to cross my radar quotes Leigh Honeywell:

“I’ve had enough crappy experiences at security conferences that I no longer attend them alone,” said Leigh Honeywell, a security engineer.

And that, conference organizers, is why you should have a code of conduct.  When people have bad experiences at your conference, they stop attending it.  When women have bad experiences at your conference, they stop attending it if they can’t come up with a way to guarantee their safety.  And when we have bad experiences at your conference, we talk about it.  I’ve avoided attending conferences because I’ve heard about bad behavior that goes unchecked.

If you don’t have a code of conduct that you enforce, you’re losing attendees.  It’s in the best interest of your conference, including best financial interest, to have a code of conduct.

Read the whole story
Share this story
Delete

What’s new in Gutenberg? (14th July)

1 Share

0.5.0 🦀

#core-editor, #editor, #gutenberg

Read the whole story
Share this story
Delete

Deploy WordPress Sites From GitHub With DeployHQ

1 Share

One of the most popular ways of managing WordPress code is storing it in a repository, such as GitHub or BitBucket. In today’s post, we’re exploring how DeployHQ can deploy code from a GitHub repository to a WordPress site. We’ll walk you through the steps required to implement and configure DeployHQ, including:

  1. Connecting a DeployHQ project to a GitHub account and repository.
  2. Setting up DeployHQ to connect to a staging site and production site via SFTP and configuring each to update when a push is made to staging and master branches.
  3. Configuring GitHub to know where to send event payloads that will trigger automatic deploys/updates to staging and master branches.

While the instructions outlined here will work with any SFTP setup, the workflow we’re demonstrating is based on the Pressable platform.

What You’ll Need

Before getting started, it’s important to have the following items already in place:

  • A GitHub account and repository that you privileges to modify settings on.
  • A DeployHQ account with space to create a project. DeployHQ offers a free account that allows for 1 project with limited daily deployments.
  • Your Pressable SFTP credentials (or credentials to an SFTP server that your staging/production sites and filesets reside on).

A Word of Advice

We highly advise that you do not version control any code that’s not directly managed by you. Our instructions should be followed for repositories that you are regularly committing to, but not for the following:

  • WordPress Core: Pressable already manages/updates WordPress Core on your behalf, there is no need to version control and deploy it via GitHub.
  • The wp-content, plugins and/or themesfolders. Only version control themes and plugins you are intending to maintain yourself. All others should be updated through the WordPress repository when possible.
  • The uploads folder should not be version controlled in a repository. There are more effective ways of accomplishing file parity between sites that we will not discuss here.

The suggestions above are tailored for Pressable customers but they are good practices for customers of most any WordPress host.

Configuring DeployHQ

The first step is logging into DeployHQ and starting a new project. You can do so by clicking on the green + button on the right hand side of the “Projects” page.

The next page will give you the opportunity to name your project and select the service where your repository is hosted. For the purposes of this tutorial, we’ve named the DeployHQ project “Pressable Blog Project.” We’ll use this project to deploy updates for a mock theme we are creating and managing through GitHub. You can choose the repository host you use. We’ll share links to Bitbucket’s documentation a bit later.

Once you’ve created your project, the next screen will prompt you to select a repository to configure from your GitHub account. In our case, we’ve selected a repository named “Pressable Blog Project.” You’ll want to select the repository for the project you are attempting to deploy.

Once you’ve selected your repository, you will be prompted to add a server to your DeployHQ project. We will be adding two “servers” in this tutorial, one for the staging site and one for the production site. For Pressable users, you will end up providing the same set of SFTP credentials twice (if you are an account owner) or two separate SFTP credentials (if you are a collaborator). Keep a careful eye out for how we configure things.

We are creating this tutorial as an account owner of two different sites on Pressable servers:

  • blog-staging
    Deployment Path: /blog-staging/wp-content/themes/pressable-blog-theme/
  • blog-production
    Deployment Path: /blog-production/wp-content/themes/pressable-blog-theme/

We’ll start by configuring the staging server deploy options first, followed by production afterward. We’ve named the first server “Staging Site SFTP” since this is an SFTP connection to the fileset for our staging site named blog-staging. You will want to give this server a name that describes what its function is relative to your project and then go ahead and enter your SFTP credentials and deployment path.

The deployment path is the directory where you want this repository deployed to. In this example, our repository holds theme files, so we created a pressable-blog-theme directory inside both blog-staging and blog-production sites. It is important that you create this folder (and name it appropriately) so that DeployHQ has a valid directory to deploy your files.

Finally, because this is our staging site, we want files to be deployed here only when there is a push to the staging branch of our repository, so we’ve selected staging as the branch to deploy from. This branch will only be available for selection if it is an already existing branch. You may have a branch named dev or some other name that you might prefer to use. We are using staging here for the sake of example. The other options can be left blank in this example.

Once you’ve configured the settings for your staging environment, you will end up on the settings page for the server. In this page, you will want to take note of the deployment URL on the right hand site of the server configuration page. You will need this URL later on when configuring deploy hooks at GitHub.

From here, you can now add and configure your production server settings and take note of the deployment URL for that server as well. Take note that our deployment path has changed for our production site to match the directory path. You will also want to note that we selected master as the branch to deploy from. This is because we want all pushes to the master branch to trigger a deploy to our production file set.

Configuring GitHub

Configuring GitHub’s settings is simple. You’ll want to navigate to the repository’s settings page and click “Webhooks” on the left hand side navigation menu. From here, you will want to click on “Add webhook.”

The next page is the webhook configuration page, where you will insert the payload URL that is available to you in the DeployHQ server configuration settings page. This means you will need to create two webhooks in GitHub, one for the staging server/fileset and one for the production server/fileset.

For instructions on configuring a webhook using BitBucket, see this link.

Final Steps

From here, all that is left to do is to make your first push to either your staging or master branches. Based on which you push to, DeployHQ will know which server to deploy the files and/or changes to.

If you have no code to push, you can also choose to manually deploy files from the DeployHQ interface by clicking on the “Deploy Now” button and selecting which server (staging or production) you want to manually deploy to.

Final Thoughts

Integrating DeployHQ with your Pressable sites allows you to deploy changes/updates with ease, enabling developers and agencies to stage updates to plugin and theme code before pushing the updates to production site(s). Give DeployHQ a try and let us know what you think!

The post Deploy WordPress Sites From GitHub With DeployHQ appeared first on Pressable WordPress Hosting.

Read the whole story
Share this story
Delete

New Guide on How to Clean a Hacked Drupal Sites

1 Share
New Guide on How to Clean a Hacked Drupal Sites

Drupal is an open-source content management system and website builder with a unique structure that allows it to be highly flexible and extendible. For these reasons and more, it’s favored by technical developers and many large websites, including .gov and .edu domains.

With its popularity among enterprise and mid-market users, there is a strong focus on security within the community. Even with this, there is no software in the world that can claim to be immune from hacks and vulnerable code.

Continue reading New Guide on How to Clean a Hacked Drupal Sites at Sucuri Blog.

Read the whole story
Share this story
Delete

WangGuard Plugin Author Shuts Down Splog Hunting Service Due to Trauma and Death Threats

1 Share

After seven years of developing and supporting the WangGuard/SplogHunter service, José Conti has shut down the server permanently due to the stress and trauma associated with maintaining it. Conti is a WordPress plugin developer and consultant, and a member of the WordPress España translation team. His WangGuard plugin identifies and blocks sploggers, unwanted users, and untrusted users on WordPress, Multisite, BuddyPress, bbPress, and WooCommerce sites. It is currently active on more than 10,000 sites.

Speculation about why the service shut down was running rampant after Conti had collected donations via an Indiegogo campaign in October 2016 to fund support and server costs. Since that time SiteGround stepped in to sponsor WangGuard, eliminating the server costs. The only costs that remained were Conti’s time and effort that he put into supporting the plugin.

“My purpose with WangGuard was never money,” Conti said in his post explaining the reason for the shut-down. “I could have made WangGuard a paid plugin at anytime, and actually had a plan for that for years. But I didn’t do it because there is something inside me that would never let that happen. It was never, I repeat, never my plan to get rich with WangGuard, and I assure you that I could have done it easily: simply charging each of my users 24€/year, would have meant an income of more than 2 million euros per year. I just had to distribute a version of WangGuard I had collecting dust, with a checkbox on WangGuard’s server administration options but I never got it done. No matter the other reasons, which only people very close to me know: I simply didn’t want to, nor did I want to be a millionaire.”

Mafia Death Threats and Trauma from Exposure to the Dark Web: The High Cost of WangGuard’s 99.9% Accurate Detection of Splogs

WangGuard has long been known for its nearly perfect detection of registration spam. Not only did it completely block unwanted users, it also removed them from the database. The plugin was unrivaled in both accuracy and price – all users got everything the service offered for free. In order for WangGuard to provide its 99.90% accuracy, Conti bolstered the algorithm with manual curation and reviews.

“WangGuard worked in two different ways: as an algorithm that I had been refining for seven years, and which was getting better as the sploggers evolved, so that it was always one step ahead of them, and also as human curation, in which I reviewed many factors, among them sites of sploggers to see if their content could improve the algorithm and make sure that it worked correctly both when it was blocking or not blocking a site,” Conti said. “The great secret of WangGuard was this second part. Without it WangGuard would not ever have become what it was.”

Because of how effective WangGuard was at stopping unwanted users, Conti said for four years he received “almost daily death threats from mafias for making them lose millions of dollars.”

Through the process of manually curating splogger sites, Conti caught a glimpse of the some of the darkest places on the web, which he said had a damaging psychological impact on him.

“For seven years, I have visited places where I saw pederasty, pictures, and videos of murders (by razor blades, by gutting live people, by beheadings, dismemberments, to name a few), real videos of rape of all kinds (children, women, boys), photos of accidents in which people were totally disfigured, bizarre actions that I did not even know existed, and a very long ‘and so on,’ which I do not want to expand on,” Conti said.

The effects of viewing these types of websites every day took their toll and Conti decided to close the splog hunter service.

“Finally, a few months ago, I broke down,” Conti said. “I disappeared from everywhere and fell into a depression. The seven years of working at WangGuard finally took a toll on me. I had nightmares because of all the macabre deaths I had seen, an obsession with protecting my children from pederasty, OCD, depression, and many other symptoms. It took me about 6 months to recover (and honestly, I may be deceiving myself, since I do not think I completely recovered my life).”

I asked Conti if clicking through to the websites was necessary for maintaining the service. He explained that while WangGuard blocked emails, domains, IPs, and ISPs, without his manual curation of visiting the domains and clicking the links, users could get a lot of “sleepers” – registered and active accounts that remain silent until one day with a 0day vulnerability or a bug fix, they attack thousands of websites. The sleepers also wait to perform actions like create millions of sites on thousands of WordPress multisite installations in order to create a lot of bad content/links.

“Visiting many domains, I was able to minimize this problem,” Conti said. “The way I worked not only fixed the current spam / splog problem, but the wizard and database also fixed any future problems with sleepers.”

Another reason he visited the domains was to figure out what he needed to block, whether it was an email or a domain. The domain could be a spam domain or possibly a free email service.

“By visiting a website, I could detect whether it was a phishing website or a site camouflaged as an email service in order to try to cheat WangGuard,” he said. “I saw a lot of ‘techniques’ for trying to cheat WangGuard at Black Hat specialized forums. I had been subscribed to many spam/sploggers forums for investigation. Every time that a user described a real technique for cheating WangGuard, it was fixed immediately.”

If you’re still using the WangGuard plugin, it may continue to work but not nearly as well as in the past. Conti said that some parts of the code work without the API, but the most important parts require the WangGuard/SplogHunter server. The plugin is open source, so anyone can fork it. An English translation of his original post is available on the WordPress.org plugin forums.

Read the whole story
Share this story
Delete
Next Page of Stories