We’ve all been there. You’re managing your website, everything’s running smoothly, and then—bam! You decide to change your domain from https://www.mydomain.com to https://mydomain.com and everything falls apart. What seemed like a simple change turned into a nightmare of CORS errors, broken links, and endless troubleshooting. In this article, I want to share my experience with this ordeal and how I ultimately overcame it with a custom bash script.
The Initial Frustration
Changing your domain might sound trivial, but the reality is often far more complex. When I decided to remove the “www” from my domain, I anticipated a few hiccups. However, I was not prepared for the cascade of issues that followed. The most persistent and annoying of these was the dreaded CORS (Cross-Origin Resource Sharing) error.
What is CORS?
CORS is a security feature implemented by web browsers to prevent web pages from making requests to a different domain than the one that served the web page. While it’s a necessary measure to protect against malicious activities, it can become a significant pain point when you’re simply trying to update your domain.
My Encounter with CORS Errors
The moment I changed my domain, I was greeted with a barrage of CORS errors in my browser’s console. My website was making legitimate requests to https://mydomain.com, but because some resources were still being requested from https://www.mydomain.com, the browser blocked them. This resulted in broken functionality and a very frustrating user experience.
The Quick Fix Temptation
In my desperation, I found a quick fix: adding CORS headers to my server configuration. This involved tweaking my NGINX configuration to allow requests from both domains. While this worked temporarily, it felt like a band-aid solution rather than a proper fix. Here’s a snippet of what that configuration looked like:
location / {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Origin, Content-Type, Accept, Authorization';
}
While this might have resolved the immediate issue, it wasn’t the secure, permanent solution I was looking for. I knew I needed to address the root cause: the mixed domains in my website’s codebase.
Crafting the Perfect Solution
Realizing that a thorough and systematic approach was needed, I decided to write a bash script to replace all instances of https://www.mydomain.com with https://mydomain.com throughout my website’s files. This was no small task, but I was determined to get it right.
The Script
Here is the script I wrote to tackle this problem. I’ve removed my actual domain and paths for privacy, but you can see the structure and logic clearly:
#!/bin/bash
# Define the search and replace patterns
SEARCH1="//www.example.com"
REPLACE1="//example.com"
SEARCH2="https://www.example.com"
REPLACE2="https://example.com"
# Define the directory to search
TARGET_DIR="/home/example/htdocs/example.com"
# Define the backup directory
BACKUP_DIR="/root/backup"
# Find and replace patterns in files
grep -rl "$SEARCH1" "$TARGET_DIR" | while read -r file; do
# Make a backup of the file
cp "$file" "$BACKUP_DIR/$(basename $file)"
# Replace the pattern
sed -i "s|$SEARCH1|$REPLACE1|g" "$file"
done
grep -rl "$SEARCH2" "$TARGET_DIR" | while read -r file; do
# Make a backup of the file (only if not already backed up)
if [ ! -f "$BACKUP_DIR/$(basename $file)" ]; then
cp "$file" "$BACKUP_DIR/$(basename $file)"
fi
# Replace the pattern
sed -i "s|$SEARCH2|$REPLACE2|g" "$file"
done
echo "Search and replace completed. Backups are stored in $BACKUP_DIR"
Breaking Down the Script
Defining Search and Replace Patterns
The script starts by defining the patterns to search for and their replacements:
SEARCH1="//www.example.com" REPLACE1="//example.com" SEARCH2="https://www.example.com" REPLACE2="https://example.com"
These patterns cover both the protocol-relative URLs and the full HTTPS URLs.
Specifying the Target Directory
Next, we define the directory where our website files are located:
TARGET_DIR="/home/example/htdocs/example.com"
This is where the script will look for files to update.
Creating Backups
To ensure we don’t accidentally lose any data, we also define a backup directory:
BACKUP_DIR="/root/backup"
The script creates backups of the original files before making any changes.
Finding and Replacing Patterns
The core of the script uses grep to find files containing the search patterns and sed to perform the replacements:
grep -rl "$SEARCH1" "$TARGET_DIR" | while read -r file; do
cp "$file" "$BACKUP_DIR/$(basename $file)"
sed -i "s|$SEARCH1|$REPLACE1|g" "$file"
done
grep -rl "$SEARCH2" "$TARGET_DIR" | while read -r file; do
if [ ! -f "$BACKUP_DIR/$(basename $file)" ]; then
cp "$file" "$BACKUP_DIR/$(basename $file)"
fi
sed -i "s|$SEARCH2|$REPLACE2|g" "$file"
done
This ensures that all occurrences of the old domain are replaced with the new domain across all files in the target directory.
Running the Script
After writing the script, I ran it on my server. The process was nerve-wracking—would it work, or would I end up with more problems? Fortunately, the script executed perfectly. All the URLs were updated, backups were created, and best of all, the CORS errors were gone!
The Sweet Taste of Victory
The relief and satisfaction I felt were immense. The CORS errors that had been plaguing my website were finally resolved, and my site was running smoothly once again. No more quick fixes, no more temporary patches—just a clean, permanent solution.
Sharing the Experience
If you’re facing similar issues, I highly recommend taking the time to address the root cause rather than relying on quick fixes. Writing this script not only solved my problem but also gave me a deeper understanding of my website’s infrastructure.
Have you encountered similar CORS issues? How did you resolve them? Share your experiences in the comments below—let’s help each other out!
Conclusion
Changing your domain shouldn’t be a nightmare, but sometimes it is. The key takeaway from my experience is that thoroughness and patience pay off. By taking the time to properly update all instances of my old domain, I was able to eliminate CORS errors and restore full functionality to my website. If you’re struggling with similar issues, I hope this article and script provide some guidance and relief. Remember, you’re not alone in this—happy coding!
Feel free to adapt the script and approach to your specific needs, and don’t hesitate to reach out if you need further assistance. Good luck, and may your websites be free of CORS errors!