You are here:  » Migrated, lost product mapping, feeds etc.

Migrated, lost product mapping, feeds etc.

Submitted by PS on Wed, 2019-04-17 16:17 in

Hi David,

We migrated to a new host and everything (database etc) was carried over. It seems like it all went fine on the frontend, i.e. comparison tables show fine, however, when you click a link it doesn't go anywhere. Also, all product mapping seems to have gone as well as feed registration. Where is this admin data normally stored? I thought it would be in the database somewhere, but perhaps not?

Thanks for any help as usual! :)

Submitted by support on Thu, 2019-04-18 07:31


That's strange - yes it's all in the database. From /admin/, if you go to Tools > Backup and Restore you'll see the list of tables on the backup form so for a migration, if not making a full copy of the database you can just use a backup of all tables from the tool, and then on the new server use the restore function to re-create the database (other than products table), upload feeds or run all Automation Tool jobs and finally run a full import (or alternatively schedule a cronjob to run to fetch feeds and do the full import).

Clicking on a link and then not going anywhere, I'm wondering if you are viewing cached pages perhaps and aren't actually coming from the database at all - and then when requesting jump.php as the products table is empty the link goes nowhere (jump.php exits).

What is shown as the product count at the bottom of the /admin/ home page? Are you able to look into the database with your hosting control panel or phpMyAdmin to check the tables?


Submitted by PS on Sun, 2019-06-09 11:14

Hi David,

Thanks and sorry for the huge delay responding.

I've checked the tables in the database via phpMyAdmin, and it seems like all the data is there. I.e. the product data, feeds table, product mapping etc.

When I look at the admin section of PT, none of this shows up and if I try to do an import/register a feed it doesn't work. It allows me to 'map' the fields but when I click the trial import button it just returns me to the admin home page and it hasn't imported anything.

Any ideas of how I can troubleshoot this further or resolve?

I can't restore from the previous installation as our old host has removed those files.

Thanks very much!

Submitted by support on Mon, 2019-06-10 10:21


Feeds not registering would normally indicate that not all custom fields (added to $config_fieldSet) have been set-up correctly on the database tables. The following dbmod.php script (run from top level as usual) will add all custom fields without having to run individual scripts;

header("Content-Type: text/html;charset=".$config_charset);
header('Cache-Control: no-cache, private, must-revalidate, max-stale=0, post-check=0, pre-check=0, no-store');
header('Pragma: no-cache');
header('Expires: Thu, 1 Jan 1970 00:00:00 GMT');
$config_databaseDebugMode FALSE;
$ignore = array("name","description","image_url","buy_url","price","category","brand");
$config_fieldSet as $field => $v)
    if (
in_array($field,$ignore)) continue;
$sql "ALTER TABLE `".$config_databaseTablePrefix."feeds`
              ADD `field_"
.$field."` VARCHAR(255) NOT NULL";
$sql "ALTER TABLE `".$config_databaseTablePrefix."products`
              ADD `"
.$field."` VARCHAR(255) NOT NULL";


Submitted by PS on Mon, 2019-06-10 13:56

Hmm, that didn't seem to do anything.

I ran it and it completed fine showing 'done', but it's not allowing me to register feeds still.

Submitted by support on Mon, 2019-06-10 14:16


To reveal the problem that is preventing feed registration if you first enable database debug mode in config.advanced.php by setting to TRUE at line 6:

  $config_databaseDebugMode = TRUE;

Next, edit includes/database.php and look for the following code at line 56:

      print "[".$sql."][".mysqli_error($link)."]";

...and REPLACE with:

      print "[".$sql."][".mysqli_error($link)."]";exit();

Then attempt to register a feed again and the script will exit after the first database error allowing the error message to be captured. If you're not sure from what is displayed (or if no difference of course), let me know the output and I'll check it out further for you...


Submitted by PS on Mon, 2019-06-10 19:53

Ok - I did just that and refreshed the admin home page.

Immediately, all the feeds with green register buttons disappeared and instead in their place, it just shows this under 'Admin Home, Feed Management':

[SELECT * FROM `pt_feeds`][]

Any further help would be greatly appreciated!

Submitted by support on Tue, 2019-06-11 08:34


That sounds like the feeds table is missing - if you have a full database backup from the old server it might be worth trying to restore again however the setup script doesn't DROP tables so from the top level if you browse to


...that will restore any tables that haven't been restored - as you say it sounds like the products table is present but at least feeds and productsmap may be missing.

The above should then show all tests pass and the link to /admin/ to continue. If you have added custom fields, run the dbmod.php from above once more as that won't have applied anything to the feeds table if it was missing, and then you should be able to register / manage product mapping once more...


Submitted by PS on Tue, 2019-06-11 22:02

Thanks, David.

Although, I'm looking at the database now in phpMyAdmin and can see all the tables including the products, feeds, productsmap, filters etc.

All the database looks fine and populated with the correct data, and not corrupted or anything.

I'm not sure what to do as presumably the restore will just reimport the same data again.

Submitted by support on Wed, 2019-06-12 12:24


That would indicate that the script isn't looking at the same database as you are seeing in phpMyAdmin - if you go to just /setup.php (from top level), does it say that all tests are passed with the link to /admin/ to continue?

If not, if you could check the database settings in config.php to ensure that they match the database being viewed in phpMyAdmin that might be all it is but I would be happy to take a look at the site if that would be OK - you can email me the installation URL and temporary admin password I'll check it out further with you...


Submitted by PS on Wed, 2019-06-12 12:57

Aaah, yes. Sorry about that, how stupid of me!!! :/

It was just the wrong credentials and now everything looks fine.

I ran setup.php and the only issue that it showed was:

WARNING: $config_useRewrite is TRUE but .htaccess not found.

Interestingly, the site 'out' links are not working still so I guess that's to do with the .htaccess rewriting issue above.


Anything I can run to get that working again?

Also, do I need to remove the code that I previously entered a few posts back?

Submitted by support on Thu, 2019-06-13 09:07


Out links aren't actually affected by .htaccess being missing so however that would be stopping the product and index pages being displayed (/category/ etc.) as it .htaccess that rewrites that into categories.php etc.)

Once that's in place and products pages are working with clean URLs e.g. /product/Product-Name.html run a full import and check the Visit Store links again, if they're still not working what actually happens - does it just go to a blank page with /jump.php?id=1234 for example?


Submitted by PS on Thu, 2019-06-13 18:55

Sure, let me try that re-import and see if it works.

The usual jump.php was being re-written to /out/merchant/id

You can see what it does here when you click the 'visit store' link:

{links saved}

Submitted by support on Fri, 2019-06-14 07:47


As you're using WordPress the /pt/.htaccess isn't actually necessary, so you could just set $config_useRewrite back to FALSE (config.php line 8).

What you will then need is a rule in your top level .htaccess as follows, immediately after the RewriteBase line:

RewriteRule ^out/(.*)/(.*)/$ pt/jump.php?id=$2 [B,L]


Submitted by PS on Fri, 2019-06-14 09:29

Thanks, David.

Just took a look and it seems I already had that line, albeit not straight after the RewriteBase /

It also didn't have the 'B' at the end, only the L.

I've tried it directly after the RewriteBase line but it makes no difference.

I noticed there are two RewriteBase lines in the .htaccess file, one inside the ifModule for WP and the one for PTO. Not sure if it makes a difference?

It's strange because this was working perfectly before we migrated the site, so not sure why it wouldn't now as the .htaccess file would be exactly the same.

Submitted by support on Fri, 2019-06-14 11:07


Could you post your top level .htaccess (I'll remove before publishing your reply) and I'll take a look...

(I see from the link you provided earlier that the /out/ links just go your WordPress site's standard 404 page)


Submitted by PS on Sat, 2019-06-15 08:52

Hi David,

Thanks - here is the .htaccess file:

{code saved}

Submitted by support on Sat, 2019-06-15 09:35


As the WordPress catch-all appears first in the file I don't think the out rule will be reached as it stands - if you move the rule from the current position to the line after RewriteBase / in the # BEGIN WordPress section I think that should do the trick...


Submitted by PS on Tue, 2019-06-18 16:04

Perfect, thanks again David - appreciate it.