Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter Drumsk8

    (@drumsk8)

    Thank you ever so much for taking the time to explain the plugin so throughly! I very much appreciate it.

    I understand fully now and due to FDS, everything is ‘processing’ and will stay like that. But that’s a woocommerce thing like you’ve shared.

    Incase others wonder how you could complete an order with FDS on: I have looked at creating a custom webhook on authorize.net to send a completed signal to the woocommerce server. A custom function listens on an endpoint and can update the order if something is received. That’s out the scope of this plugin and would be individual for you to develop/solve.

    Thread Starter Drumsk8

    (@drumsk8)

    @niklasinpsyde

    Thank you so much, that was indeed the issue. I didn’t even think of checking that. So sorry.

    Thread Starter Drumsk8

    (@drumsk8)

    Hello Mark,

    Perfect, thank you ever so much for getting back to me so soon. I am sure the corrections in the new update will be very welcomed.

    Kind regards,

    Richard

    Thread Starter Drumsk8

    (@drumsk8)

    Purged all object caches in w3tc still files are being found that correspond to a username that’s only used in the cloner plugin.

    I am at a loss to understand how on earth credentials digested only by your plugin are constantly being reformed after all the purging and service restarts the plugin is deleted from the system!

    If I re-install the plugin and network activate I am instantly brought back to the plugin page for the main site within multipress with all the the fields populated.

    This is getting beyond a joke!

    Thread Starter Drumsk8

    (@drumsk8)

    So I got bored and wanted to find where this information was being stored.

    First checked the database for pattern match of the target host db username I had set in the plugin, nothing was found.

    So then I decided to check all the files in wp-content and found a bunch. I used a command like this:

    grep -r -l “target_db_user” /home/domain/public_html/wp-content/cache/object/

    Outputs a list like this:

    /home/domain/public_html/wp-content/cache/object/1/c57/c1b/c57c1b30e7e434011bddae3c48ec0ffd.php
    /home/domain/public_html/wp-content/cache/object/1/62e/3e1/62e3e12cb2116ecb64d5fa09b2ece4a5.php
    /home/domain/public_html/wp-content/cache/object/1/99c/3d7/99c3d7f11981a3b45f3e1700fdda2a94.php
    /home/domain/public_html/wp-content/cache/object/1/046/6cf/0466cfc6407cfe7995699cdc8212b22f.php
    /home/domain/public_html/wp-content/cache/object/1/b5c/d47/b5cd477768d07ac7d15e3619bb02207b.php

    I found a number of php files spread around /wp-content/cache/objects/ so I tried to delete them like this:

    grep -r -l “target_db_user” /home/domain/public_html/wp-content/cache/object/ | xargs rm -f

    Even after deleting these files, it appears they are still being created randomly. So i’ve restarted apache and fpm-php services hoping to flush out any old php task that’s running rouge in the background. Still after running the delete command I get more files appear, this even with the plugin deactivated!

    I am reluctant to reboot the server as it’s a live system, so what could be automatically generating these files, is it a stuck process? as I don’t see anything sticking out with ps -aux

    Any thoughts?

    I would also like to report that I cannot change the currency from USD to GBP or any other currency under the lite version (7.6.1).

    Since there is no warning message to upgrade when attempting to make a change, I believe this functionality to be active in the lite version? Is this a bug or an intended limitation?

Viewing 6 replies - 1 through 6 (of 6 total)