Forum Replies Created

Viewing 15 replies - 16 through 30 (of 93 total)
  • Plugin Contributor Simon Kane

    (@simonkane)

    Thanks much!
    I went and looked on the plugins page for a “settings” link,
    and not seeing it, I quit looking.
    Totally forgot about WP settings (it’s a WooCommerce site).

    Anyway, to follow along, I got a WP error (red) message with just 5 files:
    “[Media Sync] [AJAX error] parsererror E: SyntaxError: Unexpected token < in JSON at position 0”

    The 3 debug messages I see all have to do with the “UI” eg (“table-render”), and they are A-OK.

    Not seeing any 503. Am running current WP, Woo (Storefront theme), and Media Sync.
    Last thing I see looks good, and the first file is imported.

    Response 200, and nice HTML — which is not visible on the browser-rendered page.

    /wp-admin/admin-ajax.php?mediaSyncBatch=1&_fs_blog_admin=true
    <div class='media-sync-html-response-item-success'>βœ… media-sync-item-ast-shipping-providers_7-eleven-png</div>

    Here’s the parsed POST form-data (request).

    action: media_sync_import_files
    security: ee19f888e5
    dry_run: false
    file_post_date: default
    media_items[0][file]: /home/.../wp-content/uploads/ast-shipping-providers/7-eleven.png
    media_items[0][row_id]: media-sync-item-ast-shipping-providers_7-eleven-png

    `

    However, the other files in the batch are not touched.
    Not seeing any JSON in the network log at all.

    ** Could it be that an error in delivering the response HTML is the problem?
    Expecting JSON but receiving just the OK HTML ??
    ** And then maybe my import fails to continue because of that error?
    ** But this could very well be a separate error than the 503.

    Plugin Contributor Simon Kane

    (@simonkane)

    I’m wondering why you don’t seem to have the “Dry Run” checkbox?
    It should be in between “import selected” and the date/time options.

    And, just to be sure, have you tried running it with the Storefront theme and minimal active plugins? Some themes and plugins will have an effect on REST/AJAX.

    Plugin Contributor Simon Kane

    (@simonkane)

    Great!

    What triggers debug mode (if it’s in the plugin, I don’t ee it)?
    Just WP_DEBUG setting?

    Plugin Contributor Simon Kane

    (@simonkane)

    “why do big files fail?”
    It has to do with what WordPress is doing under the covers –
    such as all the processing it takes to resize and save multiple image sizes.

    Plugin Contributor Simon Kane

    (@simonkane)

    OK – I see a couple of things here.
    First, on my system, the “0 of 15” increments as each file is processed. Now, I haven’t used this plugin for a while — maybe that behavior has been changed. But also, I have found that even on fails, the files that were completed are still there. Is that what you see?

    Also, a 503 is normally a CDN-to-server issue. Are you running a CDN?
    This is especially pertinent because you said you raised exec time to 5 minutes (which is more typically a minimum starting point for any server). If it were a server problem, it shouldn’t timeout in 90 seconds — and yet, the server is issuing the fail message, so I’m a bit lost as to what’s happening under the covers.

    To wildly speculate, I think something else is going on — why would this plugin be issuing a REST call to something (which may be the source of the 503)??

    What other plugins on your server might have involvement? Feel free to post a copy of your WP status report.

    The way this WC Admin stuff is changing, almost daily, there’s really no way to know what would happen. Maybe try to hard-code kill them (via modding the actual woo files) on a TEST server , but then extensive testing will be needed — and then Woo may change something that causes the removal to break.

    Most of the core Woo (and the vast majority of other) developers neither understand nor care about performance and resource usage. “just add another GB or 10 of RAM”.

    Such really ticks me off coming from the days when we ran 25,000 simultaneous users on a 16MB, 40MHz single-core computer with a total of 16MBs of I/O. That is a fraction of not just a smartphone, but a smartWATCH nowadays. :/

    This plugin (last I looked) is for server-side bloat only.

    I am expecting the end-user experience of Woo to deteriorate more and more as they follow the current fad of “responsive” websites where as much processing as possible is dumped onto the client device.

    I’ve been around a very long time, and this will be the third cycle of “thin client, thick client, thin client”. Thick client only makes the code more complex, less efficient, and less reliable, but nobody learns from history. πŸ˜‰

    The tipping point this time will be due to the terabytes of JS file transfers along with horridly bloated HTML that will cost the end users actual money. It already is, they just haven’t figured it out yet. πŸ˜‰

    Plugin Contributor Simon Kane

    (@simonkane)

    Aborting in “a few seconds” is very unusual.
    How long do your batches take to run?
    When I run 10 (which is pretty much my max, too), it takes on the order of 3-5 minutes. I am on the very top tier of GoDaddy shared hosting, and have very little traffic (it’s a specialty B2B eCommerce site).

    There is a new filter that replaces the “kill it all” filter.
    I have not looked to see if the dev has implemented that yet.

    Woo hasn’t quite figured out what they’re doing with WC Admin.
    I know there’s changes coming to WC_Admin by the end of the
    year (just in time to interfere with peak shopping, right?).

    I am not finding either of these strings in the Woo core (or anywhere in my site for that matter): ‘recommended shipping solutions’, ‘we recommend adding’

    Do you have any more details about what could be producing the message?
    Screenshots only go so far. Sometimes seeing the actual HTML helps track the source.

    Or maybe a WP status report showing all your plugins?

    Thread Starter Simon Kane

    (@simonkane)

    @mrclayton The filter works just fine to enable the “Pay for Order” button, but the button throws a modal error box instead of processing the payment:
    ‘You must create the order before payment can be processed.’

    It turns out there’s a hard-coded check for order status = ‘pending’ in script:
    /woo-stripe-payment/assets/js/admin/meta-boxes-order.js:120

    The “triggering” PhP is at:
    woo-stripe-payment/includes/admin/meta-boxes/class-wc-stripe-admin-order-metaboxes.php:81

    I did a quick hack of that line to:
    ‘order_status’ => ‘pending’, // $order->get_status(),
    And the “credit card” box pops up just fine, and the payment processes (in test mode).

    Note that the default “allowed status” array includes status ‘auto-draft’ (…/class-wc-stripe-admin-order-metaboxes.php:58) which will probably cause the same modal error popup. I would guess that’s some kind of testing hook left in production code.

    Also, the “Pay” button on the front-end orders list page shows without using this filter (but with use of standard Woo filters), and if I remember correctly, payments work just fine with statuses other than ‘pending’, but I have not had time to actually test that at the moment.

    In any event, payment processing should not be dependent on the actual value of the order’s “internal woo-status”, especially now that the new filter exists.

    @joyryde Maybe you should get on the Woo Slack site at woocommercecommunity dot slack dot com where the restrictions on help here do not apply.

    Get another set of eyes on the problem. Ask in #developers

    @joyryde What I am seeing is several variants of “quotation mark” that are not the “true” quotation mark. I forget their names, but please examine EACH and every quotation mark and make certain that they are the correct ones. There are 2 different incorrect quote characters in the code line I copied from above.

    [products limit=”12β€³ columns=”4β€³ best_selling=”true”]
                     "  "         " "              "    "

    Now, sometimes what is displayed after copy-paste into a message is not actually the original — but it bears big magnifying glass triple-check.

    Plugin Contributor Simon Kane

    (@simonkane)

    @christopheran Was it you I just gave my filter snippet to over in the WooCommerce Slack?

    My snippet is very powerful for connecting Woo product images because it will match image names to products by SKU.

    For ordinary WP posts, my code can do that – but only under very limited cases — the image name has to have a way to be matched to the post name (slug I think is what I used).

    Beyond that, it would take digging into the OLD DB to find the attachment links, but then it’s still not easy to match up unless there’s a way to cross-reference (I’d have to dig into it for details).

    Thread Starter Simon Kane

    (@simonkane)

    Right – but again, somebody doing something stupid is not your problem. πŸ˜‰

    No big deal – I don’t need that side of it. πŸ™‚

Viewing 15 replies - 16 through 30 (of 93 total)