As of the 1st of December 2020, the new Privacy 2020 Act came into effect in New Zealand. So what does that mean for your website, and how should you respond to the changes?

The Act has been amended to make it more relevant to today’s landscape, where so much business and communication is conducted online.

Key changes that relate to websites include:

• Organisations should ensure they have robust systems in place for digital forms
• Organisations must give people the right to access their personal information
• Organisations should minimise the amount of information they collect from a person wherever possible (i.e. if the name and email is sufficient then don’t ask for more unnecessary information)
• If information is being sent overseas (i.e. a cloud-based service) then the organisation must ensure that the overseas company handles the data in accordance with the New Zealand Privacy Act 2020
• If an organisation has a breach, then they need to notify affected people directly and the Privacy Commissioner as soon as possible.

If you have an existing Privacy Statement on your website, now is a good time to review it.

If you’re collecting any information from a visitor on your website (for example, someone filling out a contact form on your enquiry page asking for a quote, or if someone is subscribing to a newsletter, or buying a product on your website), then the systems (sometimes referred to as plugins or modules) within the website will be collecting information about that person as they enter it into the form.

Your website may or may not store this information about the person (more specifically store the information on the server where the website is hosted – this can be in New Zealand or possibly in another country).

We think it’s good practice to let the person know about your privacy practices if you’re collecting information from them. The ‘Principles’ of the new Privacy Act 2020 also highlight this:

Principle 3:

When you collect personal information, you must take reasonable steps to make sure that the person knows why it’s being collected, who will receive it, whether giving it is compulsory or voluntary, what will happen if they don’t give you the information. Sometimes there may be good reasons for not letting a person know you are collecting their information – for example, if it would undermine the purpose of the collection, or if it’s just not possible to tell them.

A good starting point for what to include on your own Privacy Statement is the example provided on the NZ Digital Government site, found here: https://www.digital.govt.nz/home/about-digital-govt-nz/privacy/

Topics the example Privacy Statement covers are:

• Purpose of the privacy policy
• Collection, storage and use of personal information
  • No need to disclose personal information
  • Your disclosure of personal information
  • Holding of information
  • Use of personal information
  • Feedback
  • Submission forms
• Statistical information and cookies
  • Statistical information collected
  • Use of statistical information
  • Cookies
• Records and disclosure statement
• Correcting your personal information
  • Your rights
• What to do if you have a Privacy Complaint.

There are a number of templates available online via a quick google search. You can also use the government Privacy Statement generator tool: https://www.privacy.org.nz/tools/privacy-statement-generator/.

If you’re unsure, however, we’d recommend you seek the advice of a legal professional to help write your privacy statement. They will be able to assess your specific business requirements and work with your website developer to ascertain if there are any additional considerations that need to be taken into account. For example – your website enquiry form may talk to your CRM system (such as Hubspot), which may be hosted on a server that is outside of New Zealand. If this is the case, you’ll need to inform the user that their data may be sent offshore (it’s also important that the system you’re using is compliant with the NZ Privacy Act 2020).

WordPress is a very secure CMS. However WordPress site owners that don’t have a plan to keep their site secure will become vulnerable to hacking.

Keeping your WordPress site secure. It’s a case of balancing risk versus cost.

Building a site using a free theme, and lots of free plugins may save you money initially, but it opens you up to the risk of hacking that can have a serious impact on the financial health of your business. That problem is compounded even more if you don’t regularly update your site. So you need to ask yourself – is that initially cheap website really going to save me money? Or is going to end up costing me?

If, on the other hand, you carefully choose the theme, only use vetted and absolutely necessary plugins, ALWAYS keep everything up-to-date, enable two factor authentication, and add a firewall, then you can breathe easier knowing your site is secure.

But there is a cost to all that security.

Not all themes and plugins are created equal. There are thousands of WordPress themes out there. Some are cheap or free, while others come at a premium. Why such a variance in price? Well, some may have been built by a student in his bedroom, while another had a whole team of engineers from a reputable company working on it.

How do you spot the difference? A good place to start is to research who created the theme, look at reviews and supporting documentation, see how often the theme is updated, and how many installs it has. Check with your web developer too – have they used this theme before?

The same is true with plugins. They’re a cost-effective way to add functionality to a WordPress site. But each plugin increases the risk of hacking. So choose them wisely, with the aim of using as few as possible. Use only plugins that come from respected developers, who regularly support and update them. The moment they’re no longer needed for your site, remove them.

Anyone who has a WordPress site and has merrily applied updates with no thought or care, will have experienced a broken site at some point. This usually happens because a feature their site uses has been deprecated, changes to the theme break their page layout, or even because of a conflict between two plugins.

In the ideal scenario a well-managed WordPress site will consist of a staging site, and a live site. A developer will then apply updates first to the staging site. Only after fixing any breaks on the staging site are those updates applied to the live site.

Even when there are no breaks, someone has to check the site very carefully to determine there’s nothing wrong. This process takes time. In web development, time is money – so the best solution isn’t the cheapest solution.

Somewhere between applying all updates immediately, and never applying any updates is a middle ground.

Depending on your budget and your appetite for risk, you can have a developer apply updates on a quarterly, bi-annual or annual basis.

Even if you don’t keep a staging site on the server, a competent developer will copy your site to a development server. That’s where they will update and test first and only apply the changes to your live site when they have found and fixed any bugs.

The time it takes to do this depends on several factors: the level of customisation in your site; the functionality and size of your site; and on the changes in WordPress, or your theme and plugins (if WordPress, or your theme have a major version change expect things to take a little longer than for minor updates).

For many small businesses an annual update will be the right balance between cost and security. For high profile sites, government sites, or websites with sensitive information, a more frequent update is prudent.

Adding a firewall to your WordPress site adds an additional layer of security. Ideally the firewall loads first before WordPress and blocks any known bad actors from even visiting your site, let alone hacking it.

The easiest way to do this is to use a reputable security plugin such as Wordfence. A good firewall will protect your site against malware, Denial of Service attacks and SQL Injections.

It seems basic, but so many site owners choose a simple easy to remember password over a secure one.

At the most basic level:
Limit the number of people who have access to your website admin area, and give them each a separate username and password;
Create secure passwords. (12 characters or more with a mix of upper and lower case plus a number and a special character);
Change passwords when staff leave.

Level Two:
Use Loginizer or Wordfence to limit login attempts and prevent brute force attacks.

Level Three:
Enable two factor Authentication. Yes, it is a pain, but it works.

Article explains how to use Magento and Apache error logs to debug or find issues in your installation.

It’s a good practice to check your error logs once a while. If you are still developing the site, turn on Magento developer mode
bin/magento deploy:mode:set developer

Magento error logs & reports

Depending on error type, Magento write it’s errors in several places. It’s important to know what these locations are, so you can easily debug the errors.

In Magento you need to turn on log write, so system start recording logs.

You need to go to Admin -> Configuration -> Advanced -> Developer -> Log setting

And Enable log settings. Keep the default files as it is.

Error Logs.

var/log folder contains the common log files along with error logs for your Magento 3rd party modules .

Magento system log file (system.log) and exception log files(exception.log) are saved to this folder unless you rename it from administrator configuration with different names.

Reading Error Files

To read your error logs, open it in your favorite editor.
Your error log file contains the following format

[error time] main.error_type error_description

Let’s look at few rows of system.log file

[2016-08-11 23:05:22] main.INFO: Add of item with id Magento_User::system_acl was processed [] []

[2016-08-11 23:50:27] main.INFO: Cache file with merged layout: LAYOUT_frontend_STORE1_40a98983867a1770682b48d9a0ad63441 and handles 1column: Please correct the XML data and try again. [] []

First line is a information log, set in Magento Backend module. This will indicate that Menu item is added to backend menu.

$this->_logger->info(
sprintf('Add of item with id %s was processed', $item->getId())
);

You need to focus on error type and error description. Error type indicates whether you need attention to a given error. Error description provides short description about a particular error.

Magento log system has several log levels;

• EMERGENCY
• CRITICAL
• ALERT
• ERROR
• WARNING
• NOTICE
• INFO
• DEBUG

It’s easy to follow the error time when debugging an issue. Check the time, a particular error happened and compare your logs for that particular time. Most of the errors can debug from your Magento log files.

Error Reports.

There has been an error processing your request
Exception printing is disabled by default for security reasons. By turning on developer mode you can view full details of the error.
Error log record number: 343443443351


We’ve all seen this error. All the critical exceptions will be written to var/report folder. You can find the error file by looking at the number. Error file for above example is 343443443351 and it doesn’t have any extension after it. You can open the file in you favorite editor.

Below is the first line of an error log file. Most often from the first line of the file you can find the error.

a:4:{i:0;s:86:"Class Forgeonline\Timeslotbooking\Model\Product\Attribute\BlockWeekdays does not exist";i:1;s:10460:"#0 /container/application/public/vendor/magento/framework/Code/Reader/ClassReader.php(19): ReflectionClass->__construct('Forgeonline\\Tim...')

Error describe of missing class file. This could be either missing class or Incorrect naming. To debug the error you need to double check the class file.

Apache Error Reports.