In general, the Feeds module might be a solution. I've not used the BackdropCMS port for feeds yet, but that is probably what I would have used for Drupal 7. https://backdropcms.org/project/feeds
The site is an existing backdrop site running on Digital Ocean which I wanted to move to an alternative host (Hostgator).
I created a new site on Hostgator and attempted to import the digital ocean site using backup-migrate ..but it failed. Importing database using PhpMyadmin also failed.
So I thought I would simply rebuild the site, which is OK as long as I can import users.
I started using Drupal when there were less than 500 users worldwide (am a very senior citizen). I love it, but I am not a programmer so I rely totally on contrib modules.
I also love Backdrop CMS...makes so much sense.
I am a regular user of the feeds module so I will try.
Don't import whole database, just users table. And 'profile', if u are using profile2 module on Your D7 install.
I had to move 90k users from drupal 7 to backdrop. I have a lot of fields in a profile form. I 've imported users and profile table, adjusted table format a bit (AFAIR) and imported all the fields like 'field_data_field_somename'. Later edited config files for the fields and uploaded by ftp.
If You have users only and no custom profiles, then import should go quite smoothly. Dump all of the users table except user id = 1 and import to users table on backdrop site.
What was the error in phpmyadmin? If it's timing out you can try export into multiple sql files and import them. Ultimately that's easier than trying to recreate the site.
How do I apply those engines. The only one on your list that I see is UTF16, and does not create the error , but PhpMyadmin just locks up...even when only trying to import a few tables
I am wondering if the problem is that I am using Backup-Migrate to export the database, and PhpMyadmin to import?
But first look into the dump files and edit them accordingly. If there is something like
SET NAMES 'utf16'
SET CHARACTER SET utf16
Change it to utf8. And in general remove any unneccessary command which can result in import failure. I don't remember which one are these exactly, but something along the lines of:
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
These were nothing but a headache for me.
Also try INSERT IGNORE, when repeating partially successful import.
I decided to port the User Import module to make user imports simpler for Backdrop admins. It's still in very early stages but I'd love some help testing the various options if anyone is up to do some testing and file issues as they discover them (and PRs to fix would be amazing of course, but otherwise I'll try to tackle them as I can).
This (User Import module) could be a big help. I tried it on a small list, but haven't been able to get it to work. Maybe I'm doing something wrong, because the Test runs fine and says 123 Processed, 123 Importable, and 0 errors. But then on import, it shows 0 processed, 0 imported, 0 errors. Any ideas on what the hangup might be? (I didn't see anything about this in the issues queue.)
Update: After trying it on several sites, and using the test data file provided in the issues queue, I get the same result every time: Tests run fine, but imports fail. Instead, I installed the Feeds module and configured it to read in the users. It worked fine, no issues.
Thanks! The site was on PHP 7.0. With assistance from my hosting provider, I updated to PHP 7.4 and now I have access to the site again. No database re-import required.
The best you can do is test and report. If you find a contrib that doesn't work in php 8.3, create an issue in its queue so it gets fixed.
In my experience, I've found that 7.4 is safest...
Posted6 days 23 hours ago by Alejandro Cremaschi (argiepiano) on:
Hi argiepiano,
Some contrib will not work in php 7.2 or lower, and some will not on PHP 8.1 or higher.
Is there a way to find out which is the optimal PHP version for a...
Posted6 days 23 hours ago by Antony Milenkov (amilenkov) on:
This sounds like a combination of a buggy module and the "wrong" version of PHP. The fact that you are being redirected to the maintenance page may be an indication that your site was put on...
Posted1 week 44 min ago by Alejandro Cremaschi (argiepiano) on:
Comments
In general, the Feeds module might be a solution. I've not used the BackdropCMS port for feeds yet, but that is probably what I would have used for Drupal 7. https://backdropcms.org/project/feeds
If you are moving from a Drupal 7 site, you can run the Drupal 7 to BackdropCMS upgrade: https://backdropcms.org/upgrade-from-drupal
Please, provide a little more information. What kind of site are you importing users from? What is your experience level?
Wow thanks for that!
The site is an existing backdrop site running on Digital Ocean which I wanted to move to an alternative host (Hostgator).
I created a new site on Hostgator and attempted to import the digital ocean site using backup-migrate ..but it failed. Importing database using PhpMyadmin also failed.
So I thought I would simply rebuild the site, which is OK as long as I can import users.
I started using Drupal when there were less than 500 users worldwide (am a very senior citizen). I love it, but I am not a programmer so I rely totally on contrib modules.
I also love Backdrop CMS...makes so much sense.
I am a regular user of the feeds module so I will try.
Thanks so much for your help.
Barney
Don't import whole database, just users table. And 'profile', if u are using profile2 module on Your D7 install.
I had to move 90k users from drupal 7 to backdrop. I have a lot of fields in a profile form. I 've imported users and profile table, adjusted table format a bit (AFAIR) and imported all the fields like 'field_data_field_somename'. Later edited config files for the fields and uploaded by ftp.
If You have users only and no custom profiles, then import should go quite smoothly. Dump all of the users table except user id = 1 and import to users table on backdrop site.
What was the error in phpmyadmin? If it's timing out you can try export into multiple sql files and import them. Ultimately that's easier than trying to recreate the site.
No..it is not timing, but it seems to reject all cache tables with error:-
#1071 - Specified key was too long; max key length is 767 bytes
So I emptied all cache on the source database but the error remained.
I then excluded all cache tables but the error appeared on other tables.
Try using different engine or different charset. innoDB vs MyISAM, UTF8 vs UTF16.
Thanks for the feedback.
How do I apply those engines. The only one on your list that I see is UTF16, and does not create the error , but PhpMyadmin just locks up...even when only trying to import a few tables
I am wondering if the problem is that I am using Backup-Migrate to export the database, and PhpMyadmin to import?
ALTER TABLE my_table ENGINE = InnoDB;
But first look into the dump files and edit them accordingly. If there is something like
Change it to utf8. And in general remove any unneccessary command which can result in import failure. I don't remember which one are these exactly, but something along the lines of:
These were nothing but a headache for me.
Also try INSERT IGNORE, when repeating partially successful import.
I decided to port the User Import module to make user imports simpler for Backdrop admins. It's still in very early stages but I'd love some help testing the various options if anyone is up to do some testing and file issues as they discover them (and PRs to fix would be amazing of course, but otherwise I'll try to tackle them as I can).
https://github.com/backdrop-contrib/user_import
This (User Import module) could be a big help. I tried it on a small list, but haven't been able to get it to work. Maybe I'm doing something wrong, because the Test runs fine and says 123 Processed, 123 Importable, and 0 errors. But then on import, it shows 0 processed, 0 imported, 0 errors. Any ideas on what the hangup might be? (I didn't see anything about this in the issues queue.)
Update: After trying it on several sites, and using the test data file provided in the issues queue, I get the same result every time: Tests run fine, but imports fail. Instead, I installed the Feeds module and configured it to read in the users. It worked fine, no issues.