kongondo

Hi @Spinbox, Thanks again for catching and reporting this as well as providing a test environment. The issue has now been fixed in today's release (007). As stated in our communication, it was caused by Padloper uninstaller not checking for Padloper items in the trash. This would cause a fatal error when attempting to delete the Padloper templates still in use by the Padloper items in the trash. Version 007 is ready for download. Thanks!

I have tested with Padloper 0.0.5 and it still works OK. I think it's time I had a look at your site, if that's OK. I'll PM you with more details, thanks.

Hmm. This is very strange. That error message is not one that is related to Padloper uninstall/removal actions. It is related to edit actions (bulk, single page, etc). I have tested with Padloper 004 and it works. Could you please confirm which Padloper, ProcessWire and PHP versions you are testing on? Thanks.

Hi @alexm, This is now possible in version 006 released today. You can hook into PadloperProcessOrder::getOrderCustomer. Demo code is here including comments in the code and a README. Give us a shout if you need further help with it.

Had you attempted to remove some stuff manually before this? I am happy to have a quick look if this is a remote site.

Hi @Spinbox, Please follow the instructions detailed here.

I see. In that case, you need to be aware of Shopify API rate limits (if you are not already ?).

Hi @Nomak. Welcome to the forums. Is this a one-off? If yes, another option is to export the products (in the Products Dashboard in Shopify admin) as CSV and then use that to import the products into ProcessWire. At that point you can use the ProcessWire API + PHP to do the imports or modify the CSV and use a module such as ImportPagesCSV to import to ProcessWire.

Hi @alexm, Excellent! Glad to hear that! Will have a look, thanks for letting me know.

Yes, that is the plan. The docs and the demo will be here. However, the purchase might remain at processwireshop.pw.

Late to the party but I agree with the approach by @rick. This is a database layer issue and I would approach it with a database solution, in the first instance, instead of a code one (hooks, forcing IDs, etc). Given, the forceID flag was added for a reason but for an operation of the scale and intricacy you are dealing with, I'd let the database handle IDs. The 1M idea is clever but given that you are enforcing it through code, it takes one or two mistakes/glitches and you could end up with some 'lost' users (e.g. with IDs < 1m).

No worries! :-).

Hi @kono, Echoing the field ?. Media Manager field has as toString() method. <?php namespace ProcessWire; // toString() echo $page->name_of_your_media_manager_field; The above will render each item in the media manager field according to its type, i.e. audio (audio player), video (video player), image (thumb 400px wide, height auto) or document (file name with URL - viewable in browser or downloadable depending on document extension) Please see the docs here. Hope this helps.

Hi @alexm, Sorry, zero idea. If you find out though (e.g. some documentation) please let me know so I can consider supporting it if it doesn't work right out of the box.

Yeah, but maybe not quite. From the thread I linked to, I see that there was an issue about saving things. My guess is that this is still happening, somehow. My theory is that something in ProcessWire 3.0.204 is preventing Padloper from saving the process module settings and maybe other stuff during the install process. Because nothing is saved, Padloper redirects back to the configuration page, and round and round we go...

Excellent! Glad you got it sorted!

Yes. It is a good idea, especially if you want to take advantage of newer features. I am not saying it is the reason for the errors you are experiencing. ProcessWire tends to be very stable across versions. It could be a case of Media Manager using one of the newer ProcessWire features. Upgrading ProcessWire is mainly a matter of swapping out /wire/ with the current latest one. However, some files such as index.php, .htaccess might also need overwriting with their latest counterparts. However, just in case something went wrong, it is a good idea to create a database backup of your site in case you needed to roll back. In the case of Media Manager itself, if you have implemented lots of changes and uploads, you might want to back those up. However, if you don't mind losing these (since you are still experimenting), I'd start from scratch. As for the Media Manager files themselves, the ProcessWire upgrade will not affect them. However, to ensure a fresh start, it is better to fully uninstall Media Manager, then upgrade ProcessWire. In summary: Create a whole site backup (e.g. using ProcessDatabaseBackups or some other database tool). Completely uninstall Media Manager. Upgrade ProcessWire. Please see the docs here. If the upgrade goes OK, do a module refresh on the site. Install & enable Tracy Debugger (if you don't have it already). Re-install Media Manager. Test Media Manager features. Please let me know how it goes.

This is a relatively old version of ProcessWire. Any reason why you are not on the latest main/master version (3.0.200) at least? Thanks. I'll have a peek.

I have narrowed this down to ProcessWirev3.0.204 at least. I have tested in 3.0.203 and install runs OK.

The last of the PHP 7.x series, PHP 7.4, will become fully unsupported (no active support + no security support) on 28 November 2022. At this point (around 2.5 months from today), the minimum PHP version requirement for Padloper will be PHP 8.x.

Hi @kono, Welcome to ProcessWire and to the forums! Thanks for the purchase. Apologies for that bad start. I have tried to reproduce this on a fresh ProcessWire install (version 3.0.204 [dev]) and I am not getting the error. Could you please let me know your environment: PHP version MySQL version ProcessWire version Are you testing on a remote or local server? In addition, could you please install the module TracyDebugger to see if it catches any errors? If your site is remote, I can have a look if I could get temporary admin access to the backend (in such a case, credentials via PM). Thanks.

He @alexm, It seems ProcessWire v3.0.204 is the issue. I don't know what exactly. I had some issues with this dev version (unrelated to Padloper) but Ryan fixed them. I'll look into this issue but it might take a while since no error is thrown. I'll try and test in older dev versions (e.g. 3.0.203). Otherwise, Padloper 005 works fine in ProcessWire 3.0.200. Thanks.

Hi @cehlo, Thanks. It is very easy (from Padloper side, at least). Please have a look at the addons documentation and specifically the payment addons docs. Hope this helps.

Hi @creativejay, I doubt it. There will be some Class name collisions at the very least. Why not just set up Padloper 2 on a local dev environment for testing? Even on a remote server for testing would work. Have a look at the import API. There's a post here somewhere where a user has successfully migrated from Padloper 1 to 2. Two main differences are: Backend: Padloper 2 houses everything in one place; Padloper 1 has stuff in different places under setup. In addition, Padloper 2 has additional dashboards, including the landing/homepage. I can give you access to a demo site if that would help. API: Padloper 2 ships with a $padloper variable that gives you access to many features in an easy, predictable and powerful way. Other than that, its all just ProcessWire pages as usual and some other optional additional features such as categories, brands, etc. I have probably oversimplified ?. Deprecation is always something to think about, e.g. PHP7. I don't know what type of customizations you have but Padloper 2 ships with an addons interface that allows you to easily extend Padloper. Hope this helps.

Done! @kalimati Please see Demo-5. Thanks.