It’s hard to diagnose the errors without the logs. Please provide the logs from your FTP program. If you’re using Filezilla, you should follow the instructions from this article:
Thanks. Here are some of the logs, though not in their entirety, as the full log is very lengthy.
Command: | STOR GDPRF CONSENT.png |
---|---|
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Error: | Transfer connection interrupted: ECONNABORTED - Connection aborted |
Response: | 226-Timeout |
Response: | 226 Transfer aborted |
Error: | File transfer failed after transferring 81,920 bytes in 61 seconds |
Status: | Starting upload of C:\Users\Documents\Hosting\Backups\thevalutrail-extracted\plugins\gdpr-framework\assets\GDPRF CONSENT.png |
Status: | Retrieving directory listing of /thevaluetrail.com/htdocs/plugins/gdpr-framework/assets… |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,221,39) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | MLSD |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 226-Options: -a -l |
Response: | 226 22 matches total |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,126,53) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | STOR GDPRF CONSENT.png |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 150 Accepted data connection |
Error: | Transfer connection interrupted: ECONNABORTED - Connection aborted |
Response: | 226-Timeout |
Response: | 226 Transfer aborted |
Error: | File transfer failed after transferring 81,920 bytes in 61 seconds |
Status: | Starting upload of C:\Users\Documents\Hosting\Backups\thevalutrail-extracted\plugins\gdpr-framework\assets\GDPRF CONSENT.png |
Status: | Retrieving directory listing of /thevaluetrail.com/htdocs/plugins/gdpr-framework/assets… |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,131,62) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | MLSD |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 226-Options: -a -l |
Response: | 226 22 matches total |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,122,15) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | STOR GDPRF CONSENT.png |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Error: | Transfer connection interrupted: ECONNABORTED - Connection aborted |
Response: | 226-Timeout |
Response: | 226 Transfer aborted |
Error: | File transfer failed after transferring 81,920 bytes in 61 seconds |
Status: | Starting upload of C:\Users\Documents\Hosting\Backups\thevalutrail-extracted\plugins\gdpr-framework\assets\GDPRF CONSENT.png |
Status: | Retrieving directory listing of /thevaluetrail.com/htdocs/plugins/gdpr-framework/assets… |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,131,147) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | MLSD |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 150 Accepted data connection |
Response: | 226-Options: -a -l |
Response: | 226 22 matches total |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,162,60) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | STOR GDPRF CONSENT.png |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Error: | Transfer connection interrupted: ECONNABORTED - Connection aborted |
Response: | 226-Timeout |
Response: | 226 Transfer aborted |
Error: | File transfer failed after transferring 81,920 bytes in 61 seconds |
Status: | Starting upload of C:\Users\Documents\Hosting\Backups\thevalutrail-extracted\plugins\gdpr-framework\assets\GDPRF CONSENT.png |
Status: | Retrieving directory listing of /thevaluetrail.com/htdocs/plugins/gdpr-framework/assets… |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,118,247) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | MLSD |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 226-Options: -a -l |
Response: | 226 22 matches total |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,171,248) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | STOR GDPRF CONSENT.png |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Error: | Transfer connection interrupted: ECONNABORTED - Connection aborted |
Response: | 226-Timeout |
Response: | 226 Transfer aborted |
Error: | File transfer failed after transferring 81,920 bytes in 61 seconds |
Status: | Starting upload of C:\Users\Documents\Hosting\Backups\thevalutrail-extracted\plugins\gdpr-framework\assets\GDPRF CONSENT.png |
Status: | Retrieving directory listing of /thevaluetrail.com/htdocs/plugins/gdpr-framework/assets… |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,202,40) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | MLSD |
Response: | 150 Accepted data connection |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 226-Options: -a -l |
Response: | 226 22 matches total |
Command: | PASV |
Response: | 227 Entering Passive Mode (185,27,134,11,140,166) |
Trace: | Binding data connection source IP to control connection source IP 10.14.0.2 |
Trace: | Trying to resume existing TLS session. |
Command: | STOR GDPRF CONSENT.png |
Trace: | TLS Handshake successful |
Trace: | TLS Session resumed |
Trace: | Protocol: TLS1.2, Key exchange: RSA, Cipher: AES-256-GCM, MAC: AEAD, ALPN: |
Response: | 150 Accepted data connection |
The transfer stops every time at “Error: File transfer failed after transferring 81,920 bytes in 60 seconds” with FileZilla. I even set the timeout to 300ms, transferred the folder in smaller chunks, enabled keep-alive on the FTP connection but nothing helped. Internet connection is good. Even the bigger files are below 200 KB.
When I tried uploading with File Manager in small chunks (all files below 200 KB) after the failure with FileZilla, I encountered the error “Upload failed 404” before the upload even started. Then I got the message “Your FTP account quota has been exceeded,” and the upload stopped. The “404” error persisted throughout the process. My total upload for the day was less than 700 KB.
I wouldn’t suggest trying the upload with the file manager, it really doesn’t work well for these types of use.
As for why the transfer doesn’t work, the connection log doesn’t really indicate a clear issue to me. All it says is that it timed out after 60 seconds, which is too long for a small file to begin with, suggesting the data transfer never initiated properly.
My best guess is that there is a firewall or router on your end that might be messing up the connection. Perhaps you could try to connect over a VPN and see if that helps?
I also pulled the logs through an AI to see if it could make more sense of it. Here are some of the recommendations it came up with. I have no idea if they work, but it might be worth a try.
-
Increase Connection Timeout in FileZilla:
- Go to
Edit > Settings > Timeout
. - Increase the timeout value to a larger value, such as 120 seconds (default may be too low).
- Go to
-
Disable Resume TLS Session for Data Connections:
- In FileZilla settings:
- Navigate to
Edit > Settings > FTP > TLS Settings
. - Uncheck “Attempt to resume TLS session.”
- Save and try the upload again.
- Navigate to
- In FileZilla settings:
-
Switch to Active Mode:
-
In FileZilla:
- Navigate to
Edit > Settings > FTP > Transfer Mode
. - Change the transfer mode to Active Mode.
- Navigate to
-
Active Mode eliminates reliance on the server’s passive data port assignment and can avoid certain NAT/firewall issues.
-
-
Enable Keep-Alive:
- In
Edit > Settings > Transfers > FTP Keep-Alive
. - Enable the option to send keep-alive commands during data transfers that may take longer.
- In
-
Test Another FTP Client:
- Test the file upload with an alternative FTP client to confirm if it’s a client-specific issue.
- If the issue still occurs with another client, it suggests the problem lies on the server or network side, not with FileZilla.
Thanks! It was the antivirus—I switched it off, and the files uploaded successfully. However, after activating the uploaded themes and plugins in WordPress, I ran into another issue. I can’t access the dashboard and keep getting this error:
“There has been a critical error on this website. Please check your site admin email inbox for instructions. If you continue to have problems.”
But I haven’t received any emails from WordPress.
The website was originally created a few years ago and hasn’t been used for several months. Just got uploaded now. I’m wondering if outdated or incompatible themes/plugins could be causing this, or if there’s another issue at play. Any thoughts?
You need to setup SMTP, WordPress uses PHPs mail() by default which is not supported on free hosting.
Thanks for the help. I think I’ve run into a few issues that feel quite frustrating and daunting right now. One is the SMTP/PHP mail issue, another is that my content isn’t showing up in WordPress (probably due to some problems with the database.sql file). Additionally, I’m having issues with the wp-config.php file, as FileZilla overwrote the original one when I tried to download it from the server. I’ve since prepared and uploaded a new one, but now I can’t even log in to the WordPress Dashboard. At this point, it might be easier to go back to Hostinger, where the site was hosted a year ago, rather than starting over here from scratch (extracting the files from WordPress, uploading them again, and facing the same problems).
I just noticed that the content is missing from the site after uploading my website. The themes and plugins were imported, but the pages and content are not. In the WordPress editor, there are only the empty sample pages that come with the installation. I created a database in MySQL Databases and then imported my backed-up database.sql
file into phpMyAdmin. Afterward, I updated the database hostname, database name, and database username in the wp-config.php
file. However, in the WordPress editor, none of the content is there—no pages, no text, no images—just the empty page that comes with a fresh WordPress installation. The database.sql
file is 14 MB in size.
thevaluetrail.com
Hello there, have you imported the image files as well? If you are migrating your website from another hosting service, you will have to upload everything you had in their hosting account in order to get what you expect.
Did you follow the instructions from this article properly?
Aren’t these things (text, images, other content) in the database.sql which I uploaded?
No, the things you have uploaded to the database is the name of the file, or if you’ve encoded your image then it will show up but in this case its likely that you’ve uploaded the name of the file to the database. So you will have to go to the previous hosting account and check for other content.
No, you need to upload those files. Take note the database only keeps the record.
I uploaded everything (themes, plugins, uploads, and cache folders) into the htdocs/wp-content folder, and placed the index.php, package.json, and wp-config.php directly into htdocs. Then, I imported the database.sql file into phpMyAdmin using the Import tab. Images in the uploads folder. So, that folder is in wp-content folder in htdocs. Don’t know where to find the text of the site though. I also updated the database host, name, username, and password in wp-config.php, but I’m not sure what I might have messed up. Any ideas?
However, even images do not show up inWP editor. Media folder is empty there.
Check the existence of the files. Take note that there is a file size limit. If a particular file hit the limit, then it is going to be deleted. If there were missing files, then that should explain why it happened.
From what you’re explaining, I have the suspicion both the missing content issue, wp-config.php and not being able to login issue might just be one issue.
My best guess based on your description is that you have multiple WordPress databases on your account, or maybe a single database with multiple WordPress installations in it. And you imported one database backup with the right contents and users, but your actual website is configured to point to a different set of database tables.
The most straight forward way to fix this in my opinion is to:
- Make sure you have the correct database backup and the correct wp-config.php file (the one from the site you’re migrating over).
- Delete your current database(s).
- Create a new database, and import your database backup.
- Replace the wp-config.php file of your website with the correct wp-config.php. Only update the database name, hostname, username and password, avoid changing anything else.
If you don’t have a good wp-config.php file, you can also try editing the existing config file. You’ll also need to check and update the database credentials, but also check the $table_prefix
. If you check your database through phpMyAdmin, you should see that all tables have an identical prefix, usually something like wpabc_
. The $table_prefix
variable must match the table prefix of your database.
And to be clear: don’t install a new website if you don’t want a new website. This sounds obvious, but too many people install a new copy of WordPress and then try to transplant the content of their old site into it. Which is possible if you know what you’re doing, but often people just end up making a big, confusing mess with new and old content getting mixed up.
Thanks! I’m still a bit unsure about a few things. My backup website includes an uploads
folder with images and a database.sql
file. I placed the uploads
folder in wp-content
under htdocs
and imported the database.sql
file into the MySQL database I created. Are these the correct locations for the files?
Also, I noticed that even though I updated the database hostname, name, and username in the wp-config.php
file, when I uploaded it to the htdocs
folder, the changes were reversed, and it reverted to the original content instead of the updated version.
This whole upload process is really frustrating. I’ve probably spent more time on uploading than actually building the site.
I merged your topics since you were discussing the same issue in both of them.
The database.sql file must be imported into your MySQL database with phpMyAdmin, yes. There is no reason to upload it along with your website files (and it’s probably safer if you didn’t).
Besides that, I’m not quite sure what the structure of your backup is like. WordPress by default has a folder at wp-content/uploads/
that contains uploaded files.
I’m sorry to hear that it has caused you so much trouble.
For next time, may I suggest you try discussing with your hosting provider how to best migrate your website? It sounds like you could have avoided a lot of trouble had you followed our migration guide instead of working with AIO WP Migration. Extracting the wpress file and importing it by hand is definitely one of the more difficult migration routes you can take.
Actually, reading the topic back again, are these the files you got from the .wpress
file? If so, then you may have to go the more difficult content transplantation route.
I can guide you through that process. But before we’re going that route, I do want to double check: do you still have access to the website at your previous host? Because you can save yourself a LOT of tedious work by just throwing the wpress backup in the trash and migrating your website the normal way.