In app/Providers/RouteServiceProvider.php change the line
public const HOME = 'dashboard';
to
public const HOME = '/';
This constant is used in app/Http/Controllers/Auth/RegisteredUserController in the store function
return redirect(RouteServiceProvider::HOME);
Implementation – Facebook Pixel
If you plan to serve European Union you will need to implement GDPR.
General Data Protection Regulation (GDPR) | Facebook for Business
Which means you will need to ask for user consent before tracking their activity on your website that involves personal data. Fortunately Facebook offers an API to pause Pixel from firing and fires once consent is granted:
fbq('consent', 'revoke');
fbq('consent', 'grant');
General Data Protection Regulation – Facebook Pixel
You can also use a tag manager for that purpose.
Facebook Pixel API offers a wide range of standard events to track.
Examples:
fbq('track', 'Purchase', {currency: "USD", value: 30.00});
fbq('track', 'AddToCart', {currency: "USD", value: 30.00});
fbq('track', 'PageView');
You will find the complete list of standard event here Reference – Facebook Pixel.
fbq('trackCustom', 'ShareDiscount', {promotion: 'share_discount_10%'});
Conversion Tracking – Facebook Pixel
In the examples above you may have notice that some code got additional information beside the event name.
{currency: "USD", value: 30.00}
{promotion: 'share_discount_10%'}
Those are optional parameters written as JSON-formatted objects and allow to include additional information to your events.
We have seen value parameters and promotion but you might want to add the category where the event took place
{content_category: "name_of_category"}
You can just as easily create custom parameters.
{custom_parameters: "some_value"}
or even more complex objects:
{contents: [
{
id: '301',
quantity: 1
},
{
id: '401',
quantity: 2
}]}
You will find more information on the link above where parameters are treated, plus you have some example above.
In this article we will consider that you have already finalize your site on WordPress on a development server, backed up your production site and that you are ready to do the transfer. We will simply mention that once you have finalized you site on the development site don’t forget to redirect your page through .htaccess.
Your .htaccess will look like that:
<IfModule mod_rewrite.c>
RewriteEngine On
</IfModule>
# BEGIN WordPress
# Rivit, jotka ovat "BEGIN WordPress" ja "END WordPress" välissä on luotu dynaamisesti ja niitä tulee muokata vain WordPressin filttereillä. Kaikki manuaaliset muutokset riveihin tullaan yliajamaan.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
#My redirect
RewriteRule ^some_url.html$ https://www.example.com/some/new_url/ [L,R=301,NC]
#End redirect
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
#BEGIN CUSTOMNote that the simple 301 redirect:
Redirect 301 /oldpage.html http://www.yoursite.com/newpage.html Redirect 301 /oldpage2.html http://www.yoursite.com/folder/
as described here, won’t work as is in the WordPress .htaccess, hence the use of the previous method. Not that the URL being redirected does not use the domain name.
If you have to redirect files and folders that are hosted in a subdomain, make sure to modify the .htaccess accordingly in the affected directory.
We also recommend that you redirect your image to not lose any image traffic.
WordPress.org has a good documentation about moving wordpress:
In our case study, the paragraph about changing domain name and URLs is particularly of interest to us.
One thing that is not explicitly mentioned is that the column guid in the wp_posts column in the database won’t change and still refer to your development server. To solve this you might think of running an SQL command to update the gui to your new domain name:
UPDATE wp_posts SET guid = REPLACE(guid, "old[DOT]com", "new[DOT]com");
but this operation is not recommended due to data serialization issue. I tested one of the recommended plugin in the article (better search replace) and it worked well.
Note that some plugins might cause issue during the migration because they have hardcoded your previous domain (the development one). In that case you might want to uninstall them before migration. Some plugins doesn’t do proper garbage management and you might need to do some manual cleaning.
In my case, I had to uninstall Wordfence and manually clean the database and some files and folders. You will find all required information on Wordfence site. There is an advance uninstall option that is suppose to do that for you, but I was not aware of it at the time. It seems to be a separate plugin:
YITH WooCommerce Wishlist caused also issue by requiring a file that was not there (and also missing in the dev site but without causing issue). So you can also just uninstall it before backing up for migration and reinstall it once migration is complete. In my case I commented out the incriminated line which allow me to access the dashboard and updated the plugin, which solved the issue.
If your site have a large amount of pictures and you want to minimize downtime, we recommend that you upload your picture before hand on the production site ahead of the migration.
If you have followed the moving WordPress tutorial, you have done a backup of your development site and its database, changed the URLs in wp settings – general, which leads to a 404, backup your dev site and its database after the change you can upload the following folder to your production site, without interrupting production: wp-admin, wp-content, wp-includes.
Make sure you have php version compatible with wordpress on your production site.
Create a database to upload the database of your dev site (the one you did after changing the domain in the settings). Note the user name, use password, database name and host as you will need it later.
Once you have finished transferring your pictures and the WordPress folders and imported your database table in the production database, you are ready to finalize the migration. Delete the folders related to the previous version of your site and upload all the WordPress files that lies at the root of your dev site.
Check that your site is discoverable in WP Reading Settings and double check the robots.txt and do your redirect as indicated at the beginning of the article.
Make sure to update your site map URL in case it differs from the version prior to migration.
And finally add your analytics tracking code to your new site.
Profit.