7
Amok:
Are you ready for a long while of delicate work? Grab a cup of coffee or something that keeps you awake, fire up your XOOPS site, launch phpMyAdmin and goooooo!:
Let's proceed one thing at a time.
1. I don't think you have a problem with tables. You need to drop the following:
+ xoops_xfs_article
+ xoops_xfs_broken
+ xoops_xfs_category
+ xoops_xfs_config (this will also delete the data)
+ xoops_xfs_files
+ xoops_xfs_votedata
2. Then you need to delete the module's id in table xoops_modules. In your example, the module was created with id = 30. You'll need to find (and note down) the IDs for your bad modules.
3. Next, you have templates added to the database and compiled. The compiled ones are written into templates_c so they're easy to delete. The ones written to the database need more work.
a. Open your table xoops_tplfile. There you have references to every template in your XOOPS system. Each template has an ID (first column) and is associated to a module (third column, tpl_module). In your case, I'd erase every line pointing to the xfsection module. But be careful: you need to take note of every tpl_id you erase, because you need to also erase the source for that template.
b. Once you've finished erasing from xoops_tplfile every reference to templates associated to the module xfsection, open your table xoops_tplsource. From there, very carefully, delete every record whose Id you noted down in the previous step.
4. Remember you saved the IDs of your bad modules? Open your table xoops_block_module_link and there you'll see associations between block numbers (block_id) and module numbers (module_id). Look for the records of your bad modules and note down the block_id numbers. Then delete the records.
5. Go now to your table xoops_newblocks. The first column (bid) holds the blocks numbers, so you'll be able to delete those blocks associated to the bad modules, using the block_id numbers you noted down in the previous step. The block templates should by now be deleted (you erased them in step number 3).
6. Now it's time to get rid of the module's configuration data. Open your table xoops_config and there locate every record whose conf_modid corresponds to the bad modules' ids. You'll need to delete all those records, but before doing that, note down their IDs (first column, conf_id). Armed with those values, open your xoops_configoption table and delete there the records whose value confop_id matches the values of the conf_id you just noted.
7. Time to take care of permissions. Look for the records whose gperm_modid matches the IDs of the bad modules. You'll see a lot of values, because you have permissions for each group, both at the module and the block level (you can identify the blocks looking at the gperm_itemid value. Once you delete all the records for gperm_modid, you'll be done.
Whew! That was complicated, right? It's hard to do it by hand, and it should give each one of us reasons enough to have more respect for the developers of this excellent piece of software, because all this is usually hidden from us so we just have to worry about using the software.
Cheers.
