While our goal is to help you make sure that you can always get back to a working version of your site if something goes wrong, we certainly understand how this feature can be frustrating at times once you’re used to using Restore points without being prompted. With that in mind, there’s an easy way to disable this popup window. Add the following line to your wp-config.php file:

define( 'WPE_POPUP_DISABLED', true );

Resetting your Git Push repository on WP Engine is actually a very simple process. Before we get started, please note that if you do this, there is NO undo. Support will not be able to come in and restore your Git repository to a previous state. You must be absolutely sure that deleting your entire repository is what you really want to do before continuing.

Here’s an outline of the steps involved:

1. Initiate a new repository on your local computer
2. Force push the new repository to WP Engine
3. Continue using Git Push as before

Initiate a new repository on your local computer

If you’re reading this article, you should already be fairly familiar with how Git works. Of course, if you’re still new to Git and aren’t as familiar with initiating a new repository, you can reference the Getting Started page for Git Push to Deploy. Here is the most important portion:

Force push the new repository to WP Engine

We have set up our Git Push system to allow you to set up a new repository as needed. When you go to push to our servers, you slightly modify the command to tell Git to force the push. If you are pushing to production, the command might look like this:

You should get output that looks similar to this:

Continue using Git Push as before

Now you should be able to keep using Git push exactly as before. You can make new commits and push them. After the first push, it is no longer necessary to use -f in the push command.

Some people want to have it display and others may simply choose that they would not like to have it display. For a while we have had the option to hide it but it was just a blanket on/off switch. You can now choose which roles has access to this drop down menu. To enable this drop down, just go into /wp-admin/ and click on the WP Engine button at the top left side. Then look under the ‘Display Options’ header. Set the drop down to enabled then check off which roles you would like to be able to see the menu. Hit the save button and once it is done saving hit the ‘purge all caches’ button. Once the page reloads you will be able to see the menu at the top. Below is a screenshot of the ‘Display Options’ where you can enable this feature:

• WordPress in Your Language
• Installing WordPress in Your Language
• Translating WordPress

Do clients need to be PCI Compliant?
According to PCI DSS Compliance, any client that accepts credit card information or does a credit card transaction on their site will need to be PCI Compliant or put themselves under “high risk” and liability from the different credit card providers.

A client can remain in compliance if they perform CC transactions via a third party service, where the transaction is submitted and processed entirely through a separate service. A good example would be Authorize.net DPM, Braintree’s API service, and PayPal Pro’s API. These type of services process CC transactions through a client-side browser request – thus allowing these payment processors to handle the payments entirely through their system. These processors maintain their own PCI compliance so a client does not need to do their own auditing.

What is the PCI Security Standards Council?
The PCI Security Standards Council ( PCI SSC ) is a global forum, founded in 2006, uniting the major credit card providers (MasterCard, American Express, Visa, etc. ) to set standards of accepting and processing credit card data. According to the PCI SSC Standards overview

There’s a set of requirements called the Payment Card Industry Data Security Standard (or “PCI DSS”) and it was developed by the PCISSC – (the Payment Card Industry Security Standards Council)

These requirements are designed to provide a standardized set of consistent security measures for merchants to follow that are handling credit card transactions.
The standard includes 12 requirements for maintaining a secure operation:

Build and Maintain a Secure Network

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data
• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
• Requirement 3: Protect stored cardholder data
• Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

• Requirement 5: Use and regularly update anti-virus software
• Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

• Requirement 7: Restrict access to cardholder data by business need-to-know
• Requirement 8: Assign a unique ID to each person with computer access
• Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
• Requirement 10: Track and monitor all access to network resources and cardholder data
• Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
• Requirement 12: Maintain a policy that addresses information security

For WordPress your E-commerce options are limited, and for a PCI Compliant shopping cart, they’re limited even further.

Is WP Engine PCI compliant?
WP Engine is not a PCI Compliant hosting platform; we encourage customers to use other methods if they believe they require compliance for their entire hosting platform. Many well-known eCommerce sites do not require this, but others do.

The Good News is all ecommerce platforms offer payment gateway services that satisfy PCI compliance standards. Whether you’re on braintree, PayPal, Authorize.net, etc.
If you have any further questions on PCI compliance please refer to the following site.
https://www.pcisecuritystandards.org/approved_companies_providers/index.php

So what should you do?
You should first review the PCI documents listed above and determine if you need to be PCI compliant. Then work with your internal teams on how to get there if the answer is yes.

In many cases this can be done using a Plugin or Theme – You can check out http://www.woothemes.com/woocommerce/ for more information on this.

Setting up the redirect in the user portal is the most sure fire way to get the redirect working. The redirects reside on the NGINX level so it will handle all requests accordingly. Using .htaccess or redirection plugins will not handle all redirects because they sit on the Apache layer and thus only redirect requests handled via Apache. To create the redirect you will want to log in to the user portal. Once logged in you will click on the small version of your install name (if you have multiple installs) or click on manage wordpress (if you have only one install). You will then click on the “redirects” button. This will provide you with a list of all redirects that you currently have added into the configuration files.

Adding Redirects

Start by clicking the “create redirect” button towards the bottom of the page.

You will be taken to a page that has several fields and will look just like this:

A description of the fields are as follows:

Name You can specify a name to remind yourself what the redirect does.

Domain You can specify that the redirect will operate only on one domain, if you do not select a domain from the list then the redirect may pertain to all domains.

Source This is the URL that is going to be requested by the end users browser or user agent. It can also be seen as the origin or page that is getting redirected “from.”

Match args This field is for advanced users and can be used to further specify rules for your rewrite.

Destination This is the URL that is going to be returned when the request for the source is made. This is the page that the end user is going to be sent “to.”

Redirect type Generally this field should be left alone. You can specify what type of redirect will be used.

Once you fill in the fields, click “create redirect rule” and your redirect will be saved.

Examples

Below you will find some examples of redirects that you may find useful.

Say you need to redirect just one page to another page, you would fill in the fields like so:

Name Redirect my contact page
Domain mydomain.com
Source ^/olddirectory/verylong/URL/goeson/contactus/
Match args
Destination /contact-us/
Redirect type 301

next example…

Please notice below that there is a backslash infront of the dot of the html document. Certain characters have a specific purpose in regex so they must be escaped (ignored) in order for the rewrite rule to work properly. Just throw a backslash infront of any dot of a document type (jpeg, css, js etc.).

Name Redirect my static html page
Domain mydomain.com
Source ^/olddirectory/verylong/URL/goeson/mypage\.html
Match args
Destination /mypage/
Redirect type 301

next example…

Use case: I have a bunch of files in a certain directory but they have all moved to another directory. All of the file names are the same but they are just in a new directory. The end of each regex is like a find and replace or a copy/paste. Whatever is at the end is going to get carried over with the redirect.

Fill in the fields like this:

Name Redirect catch all
Domain mydomain.com
Source ^/thisiswhere/myfileswhere/(.*)
Match args
Destination /thisiswhere/myfilesmovedto/$1
Redirect type 301

Note

You may have a need to redirect everything in one domain to another. Some people go way overboard and try to do a search and replace in the database. Lets say you have a bunch of links in your database that have your old domain name. You should actually not create a redirect here or go updating your database. The fastest and easiest thing to do is make sure that both of the domain names are pointed to your WP Engine site and add the old domain as a redirect to the new domain. The instructions for doing so coincide with the “note” of this article: Going Live

Having your install live in /blog is not a good set up for various reasons. All of the traffic is going to proxy through the server that the main site is on. That means if the server for your main site goes down, so does your WP Engine site, even if our servers are running perfectly.The same holds true to any latency that may be present on the main site’s server.

There are also some key features that you can not make use of when you use this type of configuration, most notably are the one-click restore and staging area.

Please be aware, if you must use this type of configuration we will not assist in setting it up and the support you receive thereafter will be limited.

You can edit the thesis_options and thesis_design_options rows inside the wp_options table to change autoload to no. Once autoload is set to no for these two rows, dump your sites cache through the WP Engine plugin and your site should display properly. If you do not want to manually edit your database, you can run the following SQL query to make the necessary changes.

UPDATE wp_options SET autoload='no' WHERE option_name IN ('thesis_options','thesis_design_options')

define('WP_DEBUG', true);

Once debug mode is active, any warning or errors will be displayed at the top of every page in your website. When hosting your website with WP Engine, you will notice that every page will have the following warning when debug mode is on.

Warning: include() [function.include]: Failed opening '/nas/wp/www/cluster/account/wp-content/advanced-cache.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /nas/wp/www/cluster/account/wp-settings.php on line 62

This is just a warning, and it has nothing to do with your site in particular. Every site hosted on WP Engine, with caching enabled and debug mode on, will see this warning.