Ajax Back In Stock (re-written version of Conor/Ceon's Back In Stock Module)

Interesting,
What are your settings in configuration->Stock for Check Stock and Allow Checkout?

I have:-

Allow customer to checkout even if there is insufficient stock - False
Check to see if sufficent stock is available - True

I have discovered the issue and fixed in 4.0.3

yep it definitely works! What an ace module and module maker!! :-DD Thanks so much!!!

Hi,

I have a blank page when I connect to the page administrator.
The problem seems to be in init_back_in_stock.php:

PHP Code:

---

PHP Fatal error: Call to undefined function plugin_version_check_for_updates() in /Applications/MAMP/htdocs/store/floriostore/includes/init_includes/init_back_in_stock.php on line 51 


---

PHP Code:

---

line 51: $new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version); 


---

Have you any suggestions?

I use Zen Cart v1.5.1

Quote:

---

Originally Posted by Nightfly66

Hi,

I have a blank page when I connect to the page administrator.
The problem seems to be in init_back_in_stock.php:

PHP Code:

---

PHP Fatal error: Call to undefined function plugin_version_check_for_updates() in /Applications/MAMP/htdocs/store/floriostore/includes/init_includes/init_back_in_stock.php on line 51 


---

PHP Code:

---

line 51: $new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version); 


---

Have you any suggestions?

I use Zen Cart v1.5.1

---

Looks like the function is called before the function is declared (1.5.1 doesn't have that function standard)

Move

PHP Code:

---

// Version Checking 
if ($zencart_com_plugin_id != 0) {
    $new_version_details = plugin_version_check_for_updates($zencart_com_plugin_id, $current_version);
    if ($_GET['gID'] == $configuration_group_id) {
        $messageStack->add("Version ".$new_version_details['latest_plugin_version']." of " . $new_version_details['title'] . ' is available at <a href="' . $new_version_details['link'] . '" target="_blank">[Details]</a>', 'caution');
    }
} 


---

to the bottom of the page, after the function.

Issue is resolved in 4.0.4

Thanks for answer !
Now it works :-)

Quote:

---

Originally Posted by DivaVocals

You're welcome!!:laugh: I was hoping that you could use this thread as such..


Thanks sooooooo much for the detailed explanation.. Working on a v1.5.4 migration for a client, and she had the old Ceon "Back in Stock Notifications" module installed.. I had concerns about continuing to use ANY of Conor's modules for any of my clients given that JS Web has made it quite apparent that they have little to no intention to continue development of Conor/Ceon's "free" modules. I have no problem paying for premium modules, but I cannot support a "Freemium" module, where ONLY the premium bits are maintained while the free bits are done whenever or never.. Makes it HARD for me to get a client to BUY the premium version when they SEE that they can't reliably TRY the free version because it's not maintained..

Anyway.. thanks for the explanation.. Will give this a whirl and get my client's site converted..

---

One last thing/suggestion.. I haven't fully looked at the part of the coe that manages the conversion from Ceon Back in Stock Notifications.. But I'd like to suggest that perhaps your conversion code include the option of removing any tables and maybe even files from the old module as a part of the conversion process.. The process could also include making and storing backups of the files and database changes removed. Just thinking outloud about novice shopowners (and even seasoned pros..:laugh:) and how to make the conversion process seemless..

Heck.. maybe you already do this.. if so.. disregard.. Still haven't had coffee yet.. :laugh:

Quote:

---

Originally Posted by DivaVocals

One last thing/suggestion.. I haven't fully looked at the part of the coe that manages the conversion from Ceon Back in Stock Notifications.. But I'd like to suggest that perhaps your conversion code include the option of removing any tables and maybe even files from the old module as a part of the conversion process.. The process could also include making and storing backups of the files and database changes removed. Just thinking outloud about novice shopowners (and even seasoned pros..:laugh:) and how to make the conversion process seemless..

Heck.. maybe you already do this.. if so.. disregard.. Still haven't had coffee yet.. :laugh:

---

This is for a couple reasons.

Tables-
1.) The table, really does do much harm however if something goes wrong it will!
2.) Maybe someday you may want to reference it.

Files-
1.) There is a core modification in CEON's module, so that would either have to be unmodified or overwritten. And since it is used on so many different versions it would make that script to un-modify very difficult and very problematic.
2.) Also there are several template modifications, and so those would need to be removed, and since every store is unique that would only further complicate a "automatic" and would certainly fail a very high percentage of the time. Leaving store owners with a broken site, and little records of what was done.

Quote:

---

Originally Posted by bislewl

This is for a couple reasons.

Tables-
1.) The table, really does do much harm however if something goes wrong it will!
2.) Maybe someday you may want to reference it.

Files-
1.) There is a core modification in CEON's module, so that would either have to be unmodified or overwritten. And since it is used on so many different versions it would make that script to un-modify very difficult and very problematic.
2.) Also there are several template modifications, and so those would need to be removed, and since every store is unique that would only further complicate a "automatic" and would certainly fail a very high percentage of the time. Leaving store owners with a broken site, and little records of what was done.

---

I can see no reason why anyone would need to reference a table for a module that has not only been replaced by another, but the data migrated as well.. the data migration provides that "view back" as it were.. Not seeing the benefit of seeing it as it USED to be.. Even in corporate migration projects I've been a part of, we don't keep the old data hanging around once a successful migration has been completed..

Anyway.. I only suggested this as a possible future enhancement because there are module contributions for Zen Cart (by at least ONE or two contributors) which actually do just what I speak of in whole or in part.. (Image Handler for example does make and save file backups of modified files) So I know that functionally and technically it is doable.. but I understand if it's not something that will be included in the codebase.. Not a showstopper.. but truly a nice to have..:smile: