Wp all import ошибка сервера

This means that your server is stopping the import or export process before it can complete. WP All Import processes records piece by piece to help prevent this from happening. WP All Export also has a setting that exports a certain amount of records during each iteration to prevent terminated exports.

Sometimes you can prevent your server from terminating the import or export simply by lowering the records per iteration. Other times the reason for the termination has nothing to do with the records per iteration.

No matter the cause, the troubleshooting process always starts the same:

Lower the records per iteration. You can control how many records are processed in each iteration in the import/export Settings. Locate the Advanced Options and then change the number of records processed in each iteration. If your import/export is still being terminated with 1 record per iteration, then you’ll need to modify your server settings, so it will allow WP All Import or WP All Export to run.

Replicate on /debug. You can replicate your import or export on our testing environment (https://www.wpallimport.com/debug/) to validate that everything works as expected in a fresh environment. If the issue doesn’t happen there, it means that the problem is specific to your site’s environment. If the issue still happens on /debug, you can contact us and send us that debug site’s URL so that we investigate further.

Contact your host and have them check your server’s error log. They will be able to see exactly why your server is terminating the import/export, and they will know exactly how to fix it. There isn’t anything we can do to help until your host has checked the error log and we know exactly what the issue is.

Server Timeouts

Servers have a number of settings that place hard limits on how long processes are allowed to run before they are terminated.

There are two very common hard limits that our users run into:

Maximum Execution Time (PHP): This is set in php.ini with max_execution_time. It determines how long a process is allowed to run before it’s terminated. You can ask your host to increase the limit, but this should be considered a last resort.

FCGID Timeouts (Apache): This is set in httpd.conf with FcgidIOTimeout.It determines how long mod_fcgid will wait while trying to perform a read or write. It should be set as high as your host will allow. In our experience, 90 seconds is sufficient.

Server Errors

When servers are misconfigured or trying to do things that require more resources than are available, they will throw an error. The error message is usually just a 3-digit number. The number can give you some information about the nature of the error. For example:

500 Internal Server Error: This often occurs when something in your WordPress theme or one of the plugins has some sort of issue.

503 Service Unavailable: This often occurs when the server is overloaded. It can also indicate that the security system on your server is blocking WP All Import or WP All Export.

504 Gateway Timeout: This is often related to the server being overloaded.

524 A Timeout Occurred: This error happens due to Cloudflare. It indicates that the origin web server was reached, but it did not provide an HTTP response before the default 100-second connection timeout. You can learn more here.

Our support team will not be able to help you troubleshoot these errors. You will need to contact your host to check your server’s error log.

Check Your Server’s Error Log

You say I need to ask my host to check the server’s error logs… but what exactly am I supposed to do here?

You’ll need to contact your host’s support team, and ask them to look for entries around the time the error occurred. To help your host’s support team, be sure to include the following information in your support request:

• The approximate time of the error (including timezone). If you’re not sure when it occurred, please take the steps necessary to reproduce the error.
• Your IP address. Visit http://www.whatismyip.com/ for help.
• A screenshot of the error, including the URL in your browser.

That will put them in a much better position to give you those entries.

My host just pointed me to my error log file, can’t I just send that file to you?

No. Just sending us the entire error log file isn’t useful, as there’s no way to tell which log entries are relevant to the error you encountered.

But my host says that there’s nothing in the error logs!

If your server is throwing errors, it is your host’s responsibility to make sure it is logged. If your host is unable to find any relevant entries in the error, have them make sure that error logging is enabled and that they are checking the relevant error log. There are usually at least three places errors are logged on your server:

• The error logs for PHP
• The error logs for your web server (e.g. Apache, NGINX)
• The error logs for the database (e.g. MySQL, MariaDB)

We will not be able to help you find, read, or interpret your server’s error log. Even if we were able to do so, you’d still need to contact your host to make the necessary changes to resolve the error. This is why you pay for hosting, and problems like these are where good hosts stand out from bad ones.

If the support tech you’re talking with doesn’t see anything, you may need to:

• Try contacting their support via a different means (e.g., phone).
• Politely ask to be escalated to a higher level of support.

My host can’t/won’t help! What do I do?

If you’ve run into an unfortunate situation where your host can’t help with getting you the error logs, you can try enabling WordPress’s error-logging measures. It’s only going to give PHP errors, but in your case, perhaps that’s enough.

Please see this section for more on how to enable WordPress’s debugging measures: https://wordpress.org/support/article/debugging-in-wordpress/#example-wp-config-php-for-debugging

Once you’ve enabled them, please take the necessary steps to reproduce the error, and note down when it occurred (as advised previously). Then, please send us the entries that you found from around that time.

Note: Error log entries are usually in UTC time. You can use a tool like this: http://everytimezone.com/ – to compare your timezone with UTC time.

If you have followed all the steps so far and are still unable to find any errors, you can use a special tool that we have to log any hidden errors. It’s called error-revealer, and you can obtain it using that link. Make sure to revert the changes done to your wp-config.php file and remove the mu-plugin after you’ve logged the corresponding error.

Is there anything else I should know here?

Yes. If at any point you have a problem with this… tell us this in your reply, don’t be shy. 🙂

It’s hard to offer support when it’s not clear whether you’ve taken the steps laid out here, and communication is crucial, as we want to get this resolved for you as quickly as possible.

For a list of hosts that work great with WP All Import and WP All Export, see our recommended hosts page.

Skip to content

Есть сервер с wordpress и плагинами WooCommerce и WP ALL Import (пока что не купленные). Нужно загрузить каталог товаров в woocommerce через WP ALL Import. Каталог в формате CSV и валидирован на целостность и правильность, не помню каким тулом. Не суть, каталог корректный, так как на демо сервере WP All Import импорт проходит без проблем.

Я же получаю

Your server terminated the import process

даже не успев начать импорт. Игры с конфигом плагина не дали подвижек. Пожалуйста подскажите где копать. Вот тех инфа:

Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-514.21.1.el7.x86_64
Architecture: x86-64
vCPU: 4
RAM: 4GB
HDD: 80GB

Установленно из соурсов:
nginx version: nginx/1.12.0

--pid-path=/var/run/nginx.pid 
    --with-pcre 
    --with-http_ssl_module 
    --without-mail_pop3_module 
    --without-mail_imap_module 
    --with-http_realip_module 
    --with-http_gzip_static_module && 

PHP 7.1.4 (fpm-fcgi) (built: Jun 5 2017 10:32:06)
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

--with-mcrypt=/usr/include 
    --with-mysqli 
    --with-pdo-mysql 
    --with-openssl 
    --with-gd 
    --with-iconv 
    --with-zlib 
    --with-gettext 
    --with-curl 
    --with-png-dir 
    --with-jpeg-dir 
    --with-freetype-dir 
    --with-xmlrpc 
    --with-mhash 
    --enable-fpm 
    --enable-xml 
    --enable-shmop 
    --enable-sysvsem 
    --enable-inline-optimization 
    --enable-mbregex 
    --enable-mbstring 
    --enable-ftp 
    --enable-gd-native-ttf 
    --enable-mysqlnd 
    --enable-pcntl 
    --enable-sockets 
    --enable-zip 
    --enable-soap 
    --enable-session 
    --enable-opcache 
    --enable-bcmath 
    --enable-exif 
    --enable-fileinfo 
    --disable-rpath 
    --enable-ipv6 
    --disable-debug 
    --without-pear && 

NGINX_VERSION=1.12.0
PHP_VERSION=7.1.4

Пример конфига nginx, скажу сразу что тут уже накручено, но даже на дефолтном конфиге с правкой FastCGI результат тот же.

user  www;
worker_processes  2;

error_log  /var/log/error.log debug;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;


    fastcgi_buffers 256 16k;
    fastcgi_buffer_size 128k;
    fastcgi_connect_timeout 3s;
    fastcgi_send_timeout 120s;
    fastcgi_read_timeout 120s;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    reset_timedout_connection on;
    server_names_hash_bucket_size 100;


    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   /data/www;
            index  index.html index.php;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ .php$ {
            root           /data/www;
            fastcgi_pass   unix:/var/run/php7/php-fpm.sock;
            fastcgi_index  index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            #fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /.ht {
        #    deny  all;
        #}
    }


 }
}

PHP ini фалик:

file_uploads = On
memory_limit = 512M
upload_max_filesize = 256M
post_max_size = 300M
max_execution_time = 600
max_input_vars = 6000
max_input_nesting_level = 64

PHP-FPM Pool:

[global]
;error_log = /var/log/fpm-error.log
;
;log_level = info


[www]
listen.owner = www
listen.group = www
user = www
group = www

listen = /var/run/php7/php-fpm.sock
;listen = 127.0.0.1:9000
listen.backlog = 65536
pm = dynamic
pm.max_children = 15
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 1500
request_terminate_timeout = 300
pm.process_idle_timeout = 300
catch_workers_output = yes

SElinux=disabled

права на папки wordpress 775, файлы 664

логи PHP-FPM и NGINX пусты даже в дебаге нету ничего такого стремного при возникновении ошибки.

Суть ошибки видно на картинке.

When ever i upload the products from wp import all getting error i have aws provider they told me nothing issues in my side and i’m not able to predict what is the issues can help me issues below

Your server terminated the import process
Ask your host to check your server’s error log. They will be able to determine why your server is terminating the import process.

error screen shot —https://ibb.co/gRnXx0p

i not able to bulk upload on products showing error on server terminate the process kindly contact the hosting provider error message..
{«code»:»internal_server_error»,»message»:»The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.»,»data»:{«status»:500},»additional_errors»:[]}

Last updated: September 9, 2022

Use of WP All Import, the WordPress Importer, and similar plugins to import XML files, CSV files, WXR files, and images is a common task for developers and sites with content that changes frequently. However, it is also common for timeouts and website performance issues to occur while these imports are being processed.

In this article, we’ll discuss steps you can take to work your way through a challenging import process.

Please note that we cannot guarantee that every import process will run successfully on our platform. If the import cannot be run successfully at Kinsta we recommend performing the import in a local development environment and then importing the updated database or table to your website database.

• Why Do Imports Cause Timeouts and Performance Issues?
• Dealing with PHP Timeouts
• Dealing with HTTP Timeouts
• Dealing with Website Performance Issues
• Getting Help
• Next Steps – Local Development Workflow

Why Do Imports Cause Timeouts and Performance Issues?

There are two types of timeouts that large import processes typically run into:

• PHP timeouts occur if a single PHP process runs for longer than the max_execution_time or max_input_time set in the PHP configuration. When this happens a 502 server error is usually displayed.
• HTTP timeouts occur when the connection between your browser and the web server is held open for too long. When this happens a 504 gateway timeout error is usually displayed.

It is common for website performance to also be slower when a large import is running. This is because PHP and MySQL are busy handling the import process. This causes regular traffic to the site to have to wait until PHP and MySQL are available to generate the page requested.

Dealing with PHP Timeouts

For sites hosted on Kinsta, the PHP max_execution_time and max_input_time are set to 300 seconds by default. The maximum PHP timeout values available on our platform are based on your current hosting plan.

If you’re running into PHP timeouts, we recommend working with a developer to resolve the issue. For example, instead of running an import process via a long PHP request, it would be better to run the import directly on the container using WP-CLI or a local PHP or Bash script.

Dealing with HTTP Timeouts

HTTP timeouts typically occur after 60 seconds for sites hosted at Kinsta. Due to the design of our infrastructure, we are unable to increase the HTTP timeout duration.

If you experience an HTTP timeout there are two steps you should attempt to resolve the issue:

• If the process is timing out while the import file is being uploaded switch to a faster internet connection and retry the process.
• If you are using a tool with support for WP-CLI, such as the WordPress Importer plugin, you can run the import directly on the server and bypass the HTTP connection entirely.

Please note that running an import over SSH is a change to the content of your website is not within the scope of what our support team is here to assist you with. In addition, if you are not familiar with SSH you will either need to learn how to use this powerful tool or work with a developer to process the import over SSH.

Dealing with Website Performance Issues

If the import process is running successfully but your site is performing poorly during the process you have two options:

• Schedule the import activity for a time of low traffic to minimize the impact on your site’s visitors.
• Upgrade to a plan with more PHP workers on your live site. If the performance issues are due to PHP being unavailable to handle more requests upgrading temporarily to a plan with more PHP workers will mean PHP has more capacity to handle both traffic to the site and the import.
• Upgrading a plan will not help if you’re trying to run an import on a staging site. Our staging environment has a constant set of PHP workers and will not be affected by plan upgrades.

Upgrading plans to gain access to more PHP workers will not help in all cases. If your site is running slowly because the database (MySQL) is busy inserting content into the database then adding additional PHP workers is unlikely to speed up the performance of your site.

Getting Help

If you’ve worked through the prior suggestions in this article, are still running into issues, and would like assistance, the next step would be to reach out to our support team. However, before opening a conversation with our support team please gather as much information as possible.

• • Start the import and time how long it takes for the process to fail. If the process fails after 1 minute you are likely running into an HTTP timeout. If it fails after 5 minutes you are likely running into a PHP timeout. If it fails at some other point you are likely running into some other limit or error and not actually seeing a timeout.
  • Check the error logs at the time that the import failed and see if an error was recorded at the time of the failure.
  • Take a screenshot of the error message or error page you are observing.
  • Write a concise description of the type of file you are trying to import, how the file was created, what it contains, the tools used to create the file and run the import, and the error you are experiencing.

Once you have gathered this information open a ticket with Kinsta’s support team. However, please note that we cannot guarantee that we will be able to assist you in getting every import to run successfully.

Next Steps – Local Development Workflow

If running the import in Kinsta’s environment is not possible the next step would be to develop a new workflow for the import process where the import is run in a local development environment. Please note that a developer will need to be involved in this process to ensure no data is lost and that your site database is not damaged.

In general, the process would be to set up a copy of your site in a local development environment –  you can use DevKinsta – where you can control all of the timeout limits. Then complete the import in that local environment. Once the import is complete, export a copy of the WordPress database or the updated database tables from your local environment. Then create a backup of your live website, drop the database (or affected tables) from your live website, and import the database or tables exported from your local environment.

You may have this kind of error with WP All Import :

Fatal error: Cannot redeclare get_cli_args() (previously declared in /wp-admin/includes/class-wp-importer.php:282) in /wp-admin/includes/class-wp-importer.php on line 333
The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.

Or :

Fatal error: Uncaught Error: Call to undefined method RapidAddon::set_post_saved_function() in wp-contentpluginswpml-all-importwpml-all-import.php:77 Stack trace: #0 wp-contentpluginswpml-all-importwpml-all-import.php(60): WPAI_WPML->__construct() #1 wp-contentpluginswpml-all-importwpml-all-import.php(423): WPAI_WPML::getInstance() #2 wp-adminincludesplugin.php(1897): include('C:\domains\code...') #3 wp-adminplugins.php(172): plugin_sandbox_scrape('wpml-all-import...') #4 {main} thrown in wp-contentpluginswpml-all-importwpml-all-import.php on line 77

Or :

Backtrace from Exception "No trid for product variation in secondary language, imposssible to set _wcml_duplicate_of_variation" In /wp-content/plugins/wpml-all-import/wpml-all-import.php [line 304]/wp-includes/class-wp-hook.php 288 calling saved_post() | /wp-includes/class-wp-hook.php 310 calling apply_filters() | /wp-includes/plugin.php 453 calling do_action() | /wp-content/plugins/wp-all-import-pro/models/import/record.php 3611 calling do_action() | /wp-content/plugins/wp-all-import-pro/controllers/admin/import.php 2834 calling process() | /wp-content/plugins/wp-all-import-pro/wp-all-import-pro.php 652 calling process() | /wp-includes/class-wp-hook.php 286 calling adminInit() | /wp-includes/class-wp-hook.php 310 calling apply_filters() | /wp-includes/plugin.php 453 calling do_action() | /wp-admin/admin.php 156 calling do_action()

Or :

NOTICE: PHP message: PHP Warning: fopen(uploads/wpallimport/uploads/[…]/file.csv): failed to open stream: No such file or directory in plugins/wp-all-import/libraries/XmlImportCsvParse.php on line 962

Or :

Update Failed: Could not copy file. wp-all-export-pro/static/js/jquery/css/smoothness/images/ui-bg_highlight-soft_75_cccccc_1x100.png

Or :

Notice: Undefined variable: export in wp-contentpluginswp-all-export-proviewsadminexportsuccess_page.php on line 6

Notice: Trying to get property of non-object in wp-contentpluginswp-all-export-proviewsadminexportsuccess_page.php on line 6

There are multiple solutions to try to make it work.

Updates

The first thing to do if you are stuck with WP All Import is to ensure that all your WordPress is up to date. You should check your :

• WordPress
• Plugins
• Theme

Once all these updates are done, check back if these errors appear.

Check WP All Import

Sometimes, you just need to disable the plugin, and enable it just after to make it work again.

If it doesn’t work, your WP All Import plugin may be corrupted. To ensure that it’s not your case, you have to re-download the plugin (or the theme delivered with the plugin) and try to install it again.

Check others plugins

Are you sure that the error is related to WP All Import? Maybe not.

It could be related to another plugin that is not compatible. It could happen when you use a cache plugin, a security plugin, or simply a poorly developed plugin.

Disable all plugins. Then, check for your error, if the error is still there, the problem is not related to plugins compatibility. If there are no more errors, then enable every plugin one by one and check for the error. The goal is to target the plugin involved.

Try another theme

The error can be a problem with your theme.

If it’s not already done, then you should install & activate the default WordPress theme like Twenty Twenty-Two. Check for the error, and see what is happening to be sure that your WordPress theme is not the cause.

Permalinks & htaccess

If it doesn’t work, you may have a problem with your WordPress permalinks and/or your htaccess file. You should go on your WordPress dashboard, and re-saving permalinks from the permalinks page.

Contact the developer

If all these solutions don’t work, we advise you to contact the plugin developer.

You may have found a new bug, or a specific issue. You should get in touch with the developer either on the WordPress plugin forum, either by mail, either on their specific website with their own support.

Alternative solutions

If the developer doesn’t reply, or your problem is very urgent, then you should try an alternative to the plugin.

There are thousands of plugins on the official directory, and many others outside. You should try to find and test them!

If the issue is very specific, and the plugin could not be replaced, we advise you to contact an expert.
This is the best way to ensure you’re not going to break your site anymore.