Uninstall or Disable

This page covers switching the Magento 2 rental extension off for a while, switching it back on, and removing it for good. It applies to the core extension and to every Sales Igniter add-on installed with it. Run the commands over SSH from your Magento root directory, as the user that owns the Magento files.

Two rules matter more than anything else on this page. Do not run bin/magento setup:upgrade while the rental modules are disabled but still installed. Magento then deletes their database tables, which for this extension means every reservation, serial number and rental price. And take a database backup before you start, because an uninstall cannot be undone.

Disable or uninstall? #

	Disable	Uninstall
What happens	The modules are switched off. Their code stays installed.	Magento’s module:uninstall deletes the rental data, then removes the code with Composer.
Rental data	Kept, as long as setup:upgrade is not run while the modules are disabled.	Deleted by module:uninstall --remove-data. Only a backup brings it back.
Rental products	Switch them off first.	Turned into simple or virtual products and switched off. Nothing is deleted.
Coming back	module:enable, then setup:upgrade.	Install again with Composer. It starts from scratch.
Good for	Ruling the extension out while you chase a problem, or pausing rentals.	Stopping rentals for good.

If you are chasing a problem, the Troubleshooting Guide is quicker than disabling everything, and the Programming Notes list the plugins and preferences another module is most likely to collide with. To switch off a single add-on, disable just that module and anything that depends on it; the core extension can stay on. The setup:upgrade rule applies to that add-on’s tables too.

Before you start #

Back up the database and the code #

Take both before any step on this page. The database backup is the only way back from an uninstall, or from a setup:upgrade run at the wrong moment. Your host’s backup tool is fine. From the command line, with the database name and user from app/etc/env.php:

mysqldump --single-transaction --routines --triggers -u <db-user> -p <db-name> | gzip > magento-db-$(date +%F).sql.gz
tar -czf magento-code-$(date +%F).tar.gz composer.json composer.lock app/etc/config.php app/etc/env.php

With composer.json and composer.lock, composer install puts back exactly the versions you have now. app/etc/config.php records which modules are enabled.

Find the modules you have #

bin/magento module:status | grep -E "SalesIgniter_|Hyva_SalesIgniterRental"
composer show --direct "salesigniter/*"

The first command lists the Magento module names you will disable. The second lists the packages your composer.json requires, which are the ones you will remove. Most stores have only a few of the modules below. They are listed in the order they have to come off: add-ons that depend on others first, SalesIgniter_Rental and SalesIgniter_Common last.

Magento module	Composer package	Comes with
SalesIgniter_Customvendorpdf SalesIgniter_Marketcustom SalesIgniter_Marketintegration	salesigniter/customvendorpdf salesigniter/marketcustom salesigniter/marketintegration	Rental Multi-Vendor Marketplace
SalesIgniter_MagePlazaIntegration	salesigniter/mageplazaintegration	Mageplaza integration
SalesIgniter_Rentalinventory	salesigniter/releaserentalinventory2	Multi Source Inventory Pro
SalesIgniter_Rfqintegration	salesigniter/releaserfqintegration2	Amasty RFQ integration
Hyva_SalesIgniterRental	salesigniter/hyvarental	Hyvä storefronts
SalesIgniter_RentalContract SalesIgniter_Maintenance SalesIgniter_Rentalextend SalesIgniter_Purchaserentals SalesIgniter_Orderedit SalesIgniter_WaiverDamage	salesigniter/releaserentalcontract2 salesigniter/releasemaintenance2 salesigniter/releaserentalextend2 salesigniter/releasepurchaserentals2 salesigniter/ordereditintegration salesigniter/waiverdamage	Rental Booking Pro
SalesIgniter_Cartdates SalesIgniter_Partialpayshow SalesIgniter_Partialpay SalesIgniter_Preorderfix SalesIgniter_Preventstock SalesIgniter_Rentalpdfserial SalesIgniter_FixedAddress SalesIgniter_PickupDropoffDates	salesigniter/cartdates salesigniter/partialpayshow salesigniter/partialpay salesigniter/preorderfix salesigniter/preventstockdeduction salesigniter/releasepdfserial salesigniter/fixedaddress salesigniter/pickupdropoffdates	Optional add-ons
SalesIgniter_Bookingsgrid SalesIgniter_Rental SalesIgniter_Common	salesigniter/bookingsgrid salesigniter/releaserental2 salesigniter/releasecommon2	The core extension

What happens to existing orders #

Orders belong to Magento, so nothing on this page deletes one. What changes is what you can do with the rental lines on them.

• The rental dates stay visible. The extension saves them on each order line as the Start Date and End Date custom options, and Magento shows those as plain text in the admin order view, the customer’s account, invoices and emails.
• The rental tools stop. Sending and returning items, serial numbers, the rental calendar and dashboard, availability checks and reminders all work from the extension’s own tables. While the extension is disabled those tables are still there; an uninstall deletes them.
• Magento no longer recognises the line type. Rental lines keep the product type sirent. Admin Reorder leaves them out, and Edit warns that they will be removed and the order cancelled and replaced. Don’t go ahead with the edit if you want to keep those lines.
• Damage waivers and deposits. With Deposits & Damage Waiver switched off, new invoices and credit memos are calculated without the waiver and deposit lines, so invoice and refund those orders first. An uninstall also deletes the waiver and deposit amounts stored on past orders; the order totals keep them.

Disable the extension #

Disabling switches the modules off and leaves their code and their data in place, so you can switch them back on later and carry on where you left off. Steps 1 and 2 need the extension still switched on.

1. Take rental products and widgets offline #

In Catalog > Products, filter Type to Reservation, select all, and choose Actions > Change status > Disable. Do it now: once the extension is off, the product grid can no longer filter by that type. Magento would treat these products as simple products, and because the extension keeps their regular price at 0 and prices rentals from its own tables, one left enabled could be ordered for nothing, with no availability check.

Remove any Rental Calendar widget from Content > Elements > Widgets, and from any CMS page or block you inserted one into (see Calendar Widget).

2. Clear the rental attribute classes #

bin/magento salesigniter:Remove:Attributes

The rental product attributes point at classes inside the extension. This command sets their backend and source models back to Magento’s defaults, so the product grid and the product edit page keep working while the extension is off; without it, every product page stops with an error. It changes nothing else and deletes no data. salesigniter:Restore:Attributes puts the classes back when you re-enable. Both commands belong to SalesIgniter_Common, which is why this step comes before you disable it.

Versions of releasecommon2 before 1.2.56 miss one attribute. With an older version, also run this in your database (add your table prefix if you have one):

UPDATE eav_attribute SET backend_model = NULL WHERE attribute_code = 'sirent_minmaxhidecalendar';

3. Turn on maintenance mode and disable the modules #

bin/magento maintenance:enable
bin/magento module:disable SalesIgniter_Customvendorpdf SalesIgniter_Marketcustom SalesIgniter_Marketintegration SalesIgniter_MagePlazaIntegration SalesIgniter_Rentalinventory SalesIgniter_Rfqintegration Hyva_SalesIgniterRental SalesIgniter_RentalContract SalesIgniter_Maintenance SalesIgniter_Rentalextend SalesIgniter_Purchaserentals SalesIgniter_Orderedit SalesIgniter_WaiverDamage SalesIgniter_Cartdates SalesIgniter_Partialpayshow SalesIgniter_Partialpay SalesIgniter_Preorderfix SalesIgniter_Preventstock SalesIgniter_Rentalpdfserial SalesIgniter_FixedAddress SalesIgniter_PickupDropoffDates SalesIgniter_Bookingsgrid SalesIgniter_Rental SalesIgniter_Common

Delete every name module:status did not list; Magento stops with Unknown module(s) otherwise. Keep the rest in one command. Magento checks dependencies before it switches anything off, and the core extension and the bookings grid require each other, so neither can be disabled on its own.

module:disable also deletes Magento’s generated classes, so keep maintenance mode on until step 5 is done.

4. Do not run setup:upgrade #

While a module is disabled but its code is still installed, setup:upgrade deletes the database tables and columns that module declares. That is how Magento’s declarative schema treats disabled modules, and the extension cannot change it. For the rental extension it means every sirental_ table (reservations, serial numbers, rental prices, send and return history) and the rental columns on the quote and order tables. Magento does not need setup:upgrade after module:disable, so skip it.

If your deployment script runs it on every deploy, pause the script while the extension is disabled. To see what a run would do without changing the database:

bin/magento setup:upgrade --dry-run=1

It writes the SQL it would run to var/log/dry-run-installation.log. Any statement in there that drops a sirental_ table means stop.

5. Rebuild, flush and reopen the store #

bin/magento setup:di:compile
rm -rf pub/static/frontend pub/static/adminhtml pub/static/deployed_version.txt
rm -rf var/view_preprocessed/* var/cache/* var/page_cache/*
bin/magento setup:static-content:deploy -f en_US
bin/magento cache:flush
bin/magento maintenance:disable

Add every locale your storefront and admin use to the deploy command, for example en_US en_GB. Wipe pub/static first rather than trusting -f: that flag only allows a deploy in developer mode and does not overwrite files that already exist, so without the wipe the store goes on serving the previous build’s JavaScript and CSS. On Luma the top menu can collapse to nothing. The upgrade note under version 1.2.197 in the release notes describes what that looks like.

In developer mode you can leave out setup:di:compile and the static deploy, because Magento generates both on demand. Do the wipe and the cache flush anyway.

Re-enable the extension #

If Magento was upgraded to 2.4.9 while the extension was off, update the extension before you enable it. releasecommon2 older than 1.2.54 and releaserentalinventory2 older than 1.2.47 stop every bin/magento command on 2.4.9 as soon as they are enabled.

composer update "salesigniter/*"

Then enable the modules you disabled, in one command, and rebuild:

bin/magento maintenance:enable
bin/magento module:enable SalesIgniter_Common SalesIgniter_Rental SalesIgniter_Bookingsgrid SalesIgniter_PickupDropoffDates SalesIgniter_FixedAddress SalesIgniter_Rentalpdfserial SalesIgniter_Preventstock SalesIgniter_Preorderfix SalesIgniter_Partialpay SalesIgniter_Partialpayshow SalesIgniter_Cartdates SalesIgniter_WaiverDamage SalesIgniter_Orderedit SalesIgniter_Purchaserentals SalesIgniter_Rentalextend SalesIgniter_Maintenance SalesIgniter_RentalContract Hyva_SalesIgniterRental SalesIgniter_Rfqintegration SalesIgniter_Rentalinventory SalesIgniter_MagePlazaIntegration SalesIgniter_Marketintegration SalesIgniter_Marketcustom SalesIgniter_Customvendorpdf
bin/magento setup:upgrade
bin/magento salesigniter:Restore:Attributes
bin/magento setup:di:compile
rm -rf pub/static/frontend pub/static/adminhtml pub/static/deployed_version.txt
rm -rf var/view_preprocessed/* var/cache/* var/page_cache/*
bin/magento setup:static-content:deploy -f en_US
bin/magento indexer:reindex
bin/magento cache:flush
bin/magento maintenance:disable

setup:upgrade marks the indexers invalid without rebuilding them, which is what indexer:reindex is for. Finally, switch your rental products back to Enabled and put back any widgets you removed. If setup:upgrade was run while the extension was disabled, the rental tables come back empty; see The rental tables are gone under Troubleshooting.

Uninstall the extension #

Uninstalling removes the extension for good with Magento’s own command, bin/magento module:uninstall --remove-data. Every Sales Igniter module that stores data carries an uninstall routine, and Magento runs it: the routine deletes that module’s data, then Magento takes the modules out of app/etc/config.php and removes their code with Composer. It needs releaserental2 1.2.206 and releasecommon2 1.2.56 or later.

There is no way to uninstall and keep the rental data: if you might come back, or want the rental history, disable the extension instead.

What the uninstall removes and keeps #

Removed	Details
Rental tables	Every sirental_ table: reservations, serial numbers and their readings and photos records, rental prices, fixed rental dates, send and return history, utilization and stock-out reports, calendar feeds and imports, reminders, and tables older versions left behind. Your table prefix is taken into account.
Pro add-on tables	The maintenance tickets (simaintenance_ tables) and the rental contracts (sirental_contract, sirental_contract_audit).
Columns on Magento’s tables	The rental dates and reservation flags on the quote, order, shipment item and credit memo item tables; the deposit and damage waiver amounts on the quote, order, invoice, credit memo and order grid tables; the signature columns on the quote and order tables.
Product attributes	Every rental product attribute (sirent_…), including those of Deposits & Damage Waiver and Purchase Rentals, with their values on every product, and the Rental group in every attribute set once it is empty. Attributes you created yourself are kept, even if their code starts with sirent_.
Settings	Stores > Configuration > Sales Igniter Rental, in every scope.
Everything else the modules kept about themselves	Admin role permissions for the rental menus, Rental Calendar widget instances, queued rental cron jobs, and Magento’s record of which setup patches have run, so that a later install starts from scratch.

Kept	Details
Every order	Rental lines keep their Start Date and End Date as text on the order, invoices and emails, and the order totals keep any deposit and waiver amounts. See What happens to existing orders.
Every product	Rental products become simple products if they have a weight and virtual products if they do not, and are switched off: most carry a regular price of 0, and an enabled one could be ordered for nothing. Before you switch one back on, give it a price and a quantity and delete its Start Date:, End Date:, Rental Buyout: and Damage Waiver: custom options.
Files	Serial photos in pub/media/salesigniter/serial-photos/ (or the folder you chose), and signed contracts in pub/media/salesigniter/contract/ and pub/media/pdfs/. Delete them, or keep a copy for your records.
Rental Calendar widgets in CMS content	A calendar you placed through Content > Elements > Widgets is removed. One you typed into a page or block as a {{widget}} directive is not; remove it before you start (see below).

Before you uninstall #

• Finish or cancel open rentals. Invoice and refund orders that carry a damage waiver or deposit.
• Take the database and code backups described under Before you start. The uninstall cannot be undone; only the backup brings the data back.
• Update the extension to releaserental2 1.2.206 and releasecommon2 1.2.56 or later, with composer update "salesigniter/*" and bin/magento setup:upgrade. On older versions module:uninstall stops with an error as soon as it loads the rental extension’s uninstall routine.
• Pro add-ons remove their own data from these versions: Deposits & Damage Waiver 1.0.2, Purchase Rentals 1.2.52, Maintenance 1.2.52, Rental Contracts 1.2.64, Multi Source Inventory 1.2.50. An older add-on is still removed, but its tables, columns and product attributes stay behind, and a leftover attribute of Deposits & Damage Waiver or Purchase Rentals stops the product edit page from opening. Update them with the rest.
• Find any calendar typed into a CMS page or block, and remove it:

SELECT page_id, title FROM cms_page WHERE content LIKE '%CalendarWidget%';
SELECT block_id, title FROM cms_block WHERE content LIKE '%CalendarWidget%';

If your database has a table prefix (table_prefix under db in app/etc/env.php), add it to those table names, for example mg_cms_page.

Run the uninstall #

First let the extension tell you the exact command for your store. It deletes nothing; it lists the Sales Igniter modules you have, in the order Magento needs them:

bin/magento salesigniter:Uninstall

It prints a module:uninstall line like the one below, with only your modules in it. Run that line, then rebuild:

bin/magento maintenance:enable
bin/magento module:uninstall --remove-data SalesIgniter_Customvendorpdf SalesIgniter_Marketcustom SalesIgniter_Marketintegration SalesIgniter_MagePlazaIntegration SalesIgniter_Rentalinventory SalesIgniter_Rfqintegration Hyva_SalesIgniterRental SalesIgniter_RentalContract SalesIgniter_Maintenance SalesIgniter_Rentalextend SalesIgniter_Purchaserentals SalesIgniter_Orderedit SalesIgniter_WaiverDamage SalesIgniter_Cartdates SalesIgniter_Partialpayshow SalesIgniter_Partialpay SalesIgniter_Preorderfix SalesIgniter_Preventstock SalesIgniter_Rentalpdfserial SalesIgniter_FixedAddress SalesIgniter_PickupDropoffDates SalesIgniter_Bookingsgrid SalesIgniter_Rental SalesIgniter_Common
bin/magento setup:upgrade
bin/magento setup:di:compile
rm -rf pub/static/frontend pub/static/adminhtml pub/static/deployed_version.txt
rm -rf var/view_preprocessed/* var/cache/* var/page_cache/*
bin/magento setup:static-content:deploy -f en_US
bin/magento indexer:reindex
bin/magento cache:flush
bin/magento maintenance:disable

• Name every module in one command, add-ons first and SalesIgniter_Bookingsgrid SalesIgniter_Rental SalesIgniter_Common last. Magento will not uninstall a module while another installed module needs it, and the core extension and the bookings grid need each other. Leave out any module salesigniter:Uninstall did not list.
• Magento asks You are about to remove code and/or database tables. Are you sure? Answer y. It then removes the data, takes the modules out of app/etc/config.php, and runs composer remove, which also removes libraries that only these modules used.
• Keep --remove-data. Without it Magento asks again whether to remove the data, and when the command runs from a script with no one to answer, it removes the data anyway.
• A Sales Igniter module installed as a folder under app/code rather than with Composer cannot be removed this way; salesigniter:Uninstall lists it separately. Delete its folder, then run the commands above.
• Add every locale your storefront and admin use to the deploy command. In developer mode you can leave out setup:di:compile and the static deploy.

Then set a price and a quantity on the former rental products you want to keep selling, delete their rental custom options, and switch them back on.

Installing again later #

Install the packages as on the install page for the regular, Pro or Multi Source Inventory version, then run bin/magento setup:upgrade. The extension installs from scratch: empty rental tables, default settings, fresh product attributes. The products the uninstall converted stay simple or virtual. Only your database backup brings the old rental data back.

Remove the package feeds (optional) #

Once nothing from Sales Igniter is installed, you can drop the repository and the credentials added at install time:

composer config --unset repositories.rental
composer config --unset http-basic.rental.rentalbookingsoftware.com

Repeat with rentalpro and rentalmsi in place of rental if you added the Pro or Multi Source Inventory feeds.

Troubleshooting #

“Please upgrade your database” or “Please update your modules” #

Magento compares each enabled module’s version with the setup_module table and refuses to serve pages when they differ.

• After re-enabling or updating: run bin/magento setup:upgrade, then rebuild as in Re-enable the extension.
• “Please update your modules”: the code is older than the database, usually after restoring an older code backup or pinning an older version. Magento cannot downgrade a module. Install the version recorded in setup_module again, or restore the database backup that matches the code.

A class that no longer exists #

• Naming an attribute class, for example Class "SalesIgniter\Rental\Model\Attribute\Backend\SirentBackendConfig" does not exist when you open or save a product, import or reindex: an attribute still points at a removed class. While the extension is installed, run bin/magento salesigniter:Remove:Attributes (step 2 of Disable the extension). If its code is already gone, clear the classes in your database instead: UPDATE eav_attribute SET backend_model = NULL WHERE backend_model LIKE 'SalesIgniter%'; and UPDATE eav_attribute SET source_model = NULL WHERE source_model LIKE 'SalesIgniter%';
• Naming SalesIgniter\Rental\Block\Widget\CalendarWidget: a Rental Calendar widget is still placed. Delete it in Content > Elements > Widgets, or find the page or block that holds it with the queries below.
• Naming an Interceptor, Factory or Proxy class: stale generated code. Run rm -rf generated/code/* generated/metadata/*, then bin/magento setup:di:compile.
• From your own theme or modules: grep -rl "SalesIgniter" app/design app/code lists the files that still call rental classes.

SELECT page_id, title FROM cms_page WHERE content LIKE '%CalendarWidget%';
SELECT block_id, title FROM cms_block WHERE content LIKE '%CalendarWidget%';

bin/magento stops with a fatal error on Magento 2.4.9 #

The error says a SalesIgniter command’s execute() must be compatible with Symfony\Component\Console\Command\Command::execute(). Magento 2.4.9 ships Symfony Console 7, which needs every console command to declare a return type. releasecommon2 older than 1.2.54 and releaserentalinventory2 older than 1.2.47 don’t, and while either is enabled every bin/magento command dies, module:disable included. It happens when an older version comes back: a composer.lock restored from before 2.4.9, a pinned version, or an old copy enabled again after a Magento upgrade. Update them:

composer update salesigniter/releasecommon2 salesigniter/releaserentalinventory2

If you only need bin/magento back so you can finish removing the extension, set the module to 0 in app/etc/config.php by hand, for example 'SalesIgniter_Common' => 0,, and run your command again. With SalesIgniter_Common off the salesigniter: commands are unavailable, so update instead if you still need them.

module:disable refuses #

• Unknown module(s): you listed a module that is not installed. Take it out of the command.
• Unable to change status of modules because of the following constraints: a module you left out depends on one you are disabling. Add it to the same command. Don’t reach for --force; it switches modules off while the modules that need them stay on.

The rental tables are gone #

setup:upgrade ran while the modules were disabled but still installed (see step 4 of Disable the extension). Re-enabling creates the tables again, empty. Only the database backup brings the data back: restore it, then follow Re-enable the extension.

salesigniter:Uninstall says it has been retired #

From releasecommon2 1.2.56 the command deletes nothing and exits with an error, so a script that still calls it stops instead of carrying on. It prints the module:uninstall command to run instead; follow Uninstall the extension. Older versions of the command did not remove every table, and on a database with a table prefix removed none at all while still deleting the attributes and settings. If you ran one of those, it also deleted Magento’s record that the rental modules are installed, and module:uninstall only cleans up modules it has a record of. With the modules still enabled, run bin/magento setup:upgrade first to put the records back, then follow the uninstall steps.