My D7 site, a hobby site that I ignored for a while, wasn't updated and got hacked. Lots of junk php files all over the server. All my Drupal sites on that server got hacked, but not my test backdrop site. I always planned to migrate the main site to Backdrop, so that is now. The question is whether I can use the standard upgrade path, or whether that risks bringing corrupted code in the database. I once migrated a drupal site by saving serialized node objects to a file and reading them in to a blank new site, fiddling with the objects, and then saving them as new nodes. If I did that, the most important thing would be to save the url alias as that is how pages are linked. Would that be a safer method or is that not required? There was some php filter stuff on the site but of course won't be on backdrop, and those few nodes (I was just calling drupal_add_js() for a jquery plugin) can be dealt with later. It's got over a 1000 nodes but they are just my photos from the years, so mostly just a body of image tags and descriptions. Almost nothing in the way of blocks or views and Backdrops default layout/theme will be fine for starters. Just the most basic complement of modules. I just want to save those nodes with 40 years of photos.
Weekly office hours
Bring your questions to our weekly virtual office hours, every Wednesday. Everyone is welcome.
Recent topics
Posted 1 week 8 hours ago by (stpaultim) in How-To and Troubleshooting
Posted 1 week 2 days ago by (stpaultim) in Weekly Meetings
Posted 1 week 3 days ago by (NormPlum) in Other
Posted 1 week 3 days ago by (NumerousHats) in How-To and Troubleshooting
Posted 1 week 3 days ago by (gwolf) in Other
Recent comments
Tried and successfully applied DrAlbany's method with the form https://www.drupal.org/sandbox/grobot/2105379stickman hook. I also encountered the same situation. Thanks DrAlbany
Ubercart - Auto increment SKU
Since before migration you need to prepare the Drupal site - disabling and removing all modules, disabling themes, as part of the preparation you can clear the cache and logs, delete the search...
Trimming the size of my database for D2B_migrate not to error out (Request Entity Too Large / 504 Gateway Time-out)
QuickTabs is now available!!! But does not work as expected, already reported (https://github.com/backdrop-contrib/quicktabs/issues/14). Maybe an alternative solution using Views...
Quick Tabs (or method to simulate)
Great, I just accessed the report here: https://github.com/backdrop-contrib/quicktabs/issues/14 geometry dash
Quick Tabs (or method to simulate)
SKU = Stock Control Unit... meaning an easy way to identify stock... Depending on the type of stock item you have, would dictate the SKU. So, for example, in the IT industry,...
Comments
Hi,
I like very much Backdrop and I plan to work with this CMS henceforth, but from the experience I have till now I would say that the upgrade from Drupal 7 to Backdrop, if it is a more complex site, with additional modules and non-standard configuration, is neither easy nor seamless.
Very often the problems come from imperfect modules of Drupal 7 or in errors made in the process of development (e.g. incorrectly uninstalled modules for which useless information is available in the database)
Either way, to upgrade from Drupal 7 to Backdrop, you first need to upgrade to the latest version of Drupal 7. At this time - Drupal 7.59.
I would first attempt to transfer ONLY the contents of the infected site to a pure new installation of Drupal 7.59 and then restore the configuration by installing and configure one by one the modules that were available on the infected site.
This removes the possibility to transfer the infected database parts to the new D7.59 site.
I've done transferring only the content from an infected site into a new installation with D7 modules like
https://www.drupal.org/project/migrate
https://www.drupal.org/project/node_export
This includes a significant additional manual work on setting up the new clean copy of the site, but sometimes it's inevitable. And yet much better than doing it all over again.
After that you will have a clean installation of your site with last version of Drupal 7 and ample time to try upgrade to Backdrop CMS. And when you do this upgrade successfully you'll be sure that it doesn't contain hacked code.
Drupal 7 will have at least a few more years of secure life, and Backdrop is getting better and more powerful with each successive version and with more and more modules available.
Like I said, this is a simple site structurally nor do I mind if some details are left behind. That might be good in fact. Website that have been around for years accumulate junk in nodes and others places, unused content types, etc.
Your suggestion to first create a clean Drupal site makes sense, and then migrate it to backdrop using their script. But I'm not sure if the extra step is necessary in this case. I created an export form the compromised site. For each node, it writes two records:
1. <node title>_<nid>_<node_type>
2. <Node body>
The old nid will be used to convert links. I'll create a field for the old nid in the nodes so they can be easily cross-referenced. These are written to a text file using fwrite(), which was done using the Devel execute php block. I haven't checked to see if Backdrop's devel has a php execute block, but I can put it in a module as well if need be. The big question is what it takes to take the above and create a savable node object for node_save(). If the normal Drupal --> Backdrop migration process has glitches, then I'd rather just skip that step.
Just thought I'd post again that I did follow through in regenerating my site directly into Backdrop and all worked fine. I used a loop calling both node_save() and path_save() and basically it's all working - deanmyerson.org. The only difference from D7 was $node = new Node instead of $node = new StdClass().