nikkoboy

@tigroumeow I have updated the plugin to version 2.5.1 and can confirm that the previously reported issue has been fixed.

Thanks a lot!

@tigroumeow So “Remote Upload: Share URLs” was the way to go! I downloaded version 2.4.5 of the plugin, and this time I was able to select “Remote Upload: Share URLs” without any problem. From there, I uploaded an image, and it worked!

I then upgraded to version 2.4.9, and that worked too! So the problem seems to be linked to plugin version 2.5 as it does not let me select “Remote Upload: Share URLs” (I get an error message when I try and select it)

I hope you find this feedback useful.

• This reply was modified 4 months ago by nikkoboy.

@tigroumeow I just noticed in your message that you mentioned “I am using Vision by URL too”. I am using Images > User Upload > “Remote Upload: Upload data”.

When I try to activate Images > User Upload > “Remote Upload: Share URLs” I’m getting “Error: An error occurred while updating the options. For more information, check your console. You might also want to check your PHP Error Logs.”

Hi @tigroumeow,

Thanks a lot for your reply! I appreciate!

Since both my websites (staging and production) are live and accessible, I reached out to my host to investigate whether there might be a security feature on their server that prevents loading external resources on the server (via the filesystem or media library).

They thoroughly investigated the issue and confirmed the following:

“I have checked the logs and with the team as well and it appears to be related to the plugin itself. The upload is going through the plugin so you might need to contact them. You can share this error:
[24-Jul-2024 07:48:33 UTC] PHP Warning: file_get_contents(https://www.mysite.com/wp-content/uploads/2024/07/c2b89256ee06667f6438e3da0370ff7e.jpg): Failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
in /home/l52dprj/public_html/wp-content/plugins/ai-engine/classes/queries/droppedfile.php on line 54

They also asked me to upload a file while monitoring the logs, and they could see the file I uploaded. So this means the upload works fine. They added “The plugin/chatbot has some issues. you may share the error with their support team.”

[24-Jul-2024 08:01:05 UTC] PHP Warning: file_get_contents(https://www.mysite.com/wp-content/uploads/2024/07/25fb625bd0f374c72f55fc33c81b502f.jpg): Failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
in /home/l52dprj/public_html/wp-content/plugins/ai-engine/classes/queries/droppedfile.php on line 54

I also deactivated plugins one by one to make sure there weren’t any conflicts, but I’m still running into the same issue ??

• This reply was modified 4 months ago by James Huff.
• This reply was modified 4 months ago by nikkoboy.

Hi @valwa

I completely rewrote from scratch the JS snippet (based on version 2.4.4), and I can now achieve exactly the same goal as the other JS snippet used in v2.3.8. This time I targeted the class .mwai-chatbot-container instead of class=”mwai-trigger mwai-open-button”.

Cheers!

Hey @valwa ! Thanks for your reply!

I checked, and actually until version 2.3.8 the class of the Mwai open button was class=”mwai-open-button P8gokhAqzYbmwRSdIX15″. All versions above version 2.3.8 use a different class: class=”mwai-trigger mwai-open-button” . I also made sure the issue isn’t related to the wp_vars not being defined (on the site using version 2.3.8

if (wp_vars.is_user_logged_in === 'no') {

works just fine. I removed wp_vars from the snippet on the staging site with version 2.4.4, but the script preventing visitors from opening the chat window if he/she is notsigned inn still does not work.

I tried both .mwai-trigger .mwai-open-button in my code snippet on my staging site (exact copy of my live site – I also tested on the live site, and it does not work), and it’s not working as .mwai-open-button in 2.3.8 works on my live site. Again, both websites are strictly identical and use the same code snippet.

As of now, the version 2.3.8 is the last version of the plugin that works with this snippet :/

@simov I was running the plugin on my staging website, and I couldn’t see the conversions, although WP Rocket was deactivated.

After running the plugin on my live website, the conversion started showing! It’s because the conversion URL/page was excluded from the server cache (I specifically asked my hosting service to not cache this page). So far, everything seems to be working just fine.

• This reply was modified 8 months, 2 weeks ago by nikkoboy.

@valwa: I managed to solve the issue of the dark text on a dark background. This was caused by my theme, from which the chat widget inherited a style rule that sets the color of text for both (anchor or link) and (paragraph) elements within a webpage to a specific color. I solved it with a tiny css snippet:

/* Global style affecting all <a> and <p> */
a, p {
    color: #242429; /* Dark color */
}

/* Specific override for the mwai-chatbot-container */
.mwai-chatbot-container a,
.mwai-chatbot-container p {
    color: #ffffff; /* Lighter color for readability on dark background */
}

cheers

• This reply was modified 9 months ago by nikkoboy.

Wow, thanks @valwa ! It works great!

Do you know if/when the API will be able to check live data (ex: upcoming events dates, actual prices, etc) like ChatGPT 4 ? With https://chat.openai.com/ I’m able to get this information, but not with the API (I tried ChatGPT 3.5, 4, 4 Turbo, and it only querries historical data, not current data).

Also, I noticed a peculiar behavior of the plugin: when the bot replies to my question, the text is dark instead of white: https://imgur.com/a/zsHqq62 Have you heard of a similar bug/behavior?

Thanks again for your help! You created a FANTASTIC tool!!

• This reply was modified 9 months ago by nikkoboy.

@itism64 your code seems to have some syntax errors and incorrect function names. Try this corrected version:

// Flush permalinks every hour
add_action('my_hourly_event', 'do_this_hourly');

function my_activation() {
    if (!wp_next_scheduled('my_hourly_event')) {
        wp_schedule_event(time(), 'hourly', 'my_hourly_event');
    }
}

add_action('wp', 'my_activation');

function do_this_hourly() {
    global $wp_rewrite;
    $wp_rewrite->flush_rules();
}

In the code snippet above, the main changes made were:

• Replaced the single quotation marks around function and action names with normal single quotation marks (' instead of ‘ and ’).
• Adjusted the indentation for better code readability.

Please note that this code should be placed in the appropriate location within your WordPress theme or in a custom plugin file.

@domainsupport the WP Cron event job jetpack_v2_heartbeat can be removed with Advanced DB Cleaner PRO. I was actually checking if it was ok to delete the cronjob jetpack_v2_heartbeat if Jetpack was uninstalled, and found your thread. Removing it now.

Thanks!

Hi @leonwimmenhoeve @rogierlankhorst

Thanks for your message! I’m not sure what was causing the problem: I think a mix of Really Simple SSL and my site and server cache. But in any case everything is back in order.

So in summary, reverting to an earlier version of Really Simple SSL solved the problem, and then updating the plugin, and cleaning the caches (site, server and cloudflare) after updating to the latest version of Really Simple SSL also worked.

All is well now. Thanks again for your assistance and I’ll keep you posted if I encounter similar problems in the future.

All the best,

Nick

• This reply was modified 1 year, 6 months ago by nikkoboy.

Ok, I think I found the answer to my question: ADD to Home screen button by using Shortcode – Super PWA Docs

Is that correct?

Thanks!

@dgoldak thanks a lot for your reply! I originally imported customers separately because I wasn’t sure this was done automatically with the EDD order import (I wanted to avoid orders not being linked to existing users, and seeing them linked to a random “guest” user).

I found a way around to not mess up with the dynamically created content of EDD (and not risk losing customers along the way, or not using the same IDs): I’ll continue working on finalizing my new website on my staging site, and when ready I’ll import then everything except all EDD’s DB tables and wp_user_meta and wp_user to the prod site. I ran a test on another staging site, and it worked. The most important parameter for me was to safeguard dynamically generated content by EDD’s (until the last second).

Thanks again for your help!

@misulicus thanks a lot for checking this! I’m not sure what might be causing this issue. For instance, for the same customer, on my live/PROD website it appears as “refunded”, while on the staging website (on which I imported the file exported from PROD), the same order from that customer appears as “pending” (instead of “refunded”). And I can’t manually set it to “refunded”: whenever the page reloads after saving it, it shows “pending” again. I can however set it to “completed”, “pending”, “partially refunded”, etc. But not to “refunded”. So that’s the same situation as the one you reproduced.

Whenever an order is refunded, the customer gets an additional order number, like for instance 23153-R-1 (in addition to his original order number. Ex: 23153).

In the end, as long as this discrepancy in the order increment does not affect the accounting on my website, that’s good for me (both my website have 3000 orders, but there is a difference in the increment of orders between the two websites: the order numbers of the last 50 clients is shifted by three numbers. Ex: same client on PROD is #3000 and on DEV is #2997)