For some reason, “some” websites do not show BetterUptime data in our MainWP installation.
One website was in our MainWP before you released the integration of BU. When you released it, all our existing monitoring seem to have sync’ed automatically with BU.
But there are a couple of websites that can’t “sync”.
How do I manually link websites that have a monitor in BetterUptime, that is using the same URL, but that is not seen or linked correctly by MainWP?
Hi @maximejobin
I couldn’t reproduce the issue.
All of the Better Uptime monitors are present in the extension.
In fact, you should be able to see your monitors even if that URL is not added as a Child Site to your Dashboard.
Can you try Saving the extension settings and see if that helps?
And can you please post the community system report from your MainWP Dashboard for review? The report is located in your Dashboard under Info → Server, on the top right of the page.
Be sure to use the button like the one below; this button hides all your private information:
Pressing the button auto-copies the report to your clipboard then just paste it in a reply here.
Hello @bojan ,
From your answer and what I understood from the code, it seems like simply “Saving” the settings tries to sync everything properly. I was able to link all websites… except 2.
Both websites have URLs like:
From what I understand, the data is synced using the aum_get_data() function as you can see here from the class-mainwp-aum-settings-page.php:
The red arrows show where you “try” to find a match between the monitored address and the website URL in MainWP.
The problem occurs when we take a look at the get_monitor_by() function :
On lines 252 and 256, you try to remove “useless” parts of the string to get a match. These 2 lines cause problems. Both lines are the same and read as:
$url_address = str_replace( array( 'https://www.', 'http://www.', 'https://', 'http://', 'www.', '/' ), array( '', '', '', '', '', '' ), $value );
The last 2 strings to search are causing bugs:
As for the 4 first strings to search, it is not optimized as I think you should check if $value starts with these strings… not only contains these string.
As for the remaining 2 strings to search, they simply make some monitors to simply not link to the data from a monitoring service.
Stripping all “www.” or “/” from a website URL will make some monitors not be able to sync.
Here is a small demo to break the logic:
abc.comdef
abccom
Of course, there is no match for these 2 sites as the URLs make no sense.
Please let us know if you can reproduce and fix this problem.
Thank you!
Thanks for the detailed write-up.
We are looking into it, and we’ll update you via this topic as soon as we have more information.
Hi @maximejobin
Can you please try this version of Advanced Uptime Monitor and see if it resolves the issue:
Hello Bojan,
To make our communication more productive, could you please provide the following information:
As a developer, I would like to know if my bug report was valid. If possible, could you share the Git pull request (PR) with me? This would help me assess whether it can be deployed in our production environment.
I apologize if I am being a bother. My intention is to assist in resolving this issue without causing any additional problems for either of us.
Thank you.
Sorry to jump in, but I’ve been someone who has tested lots of those “can you try this” versions. Practically always did it resolve the issue. Also with beta versions (big changes), I’m one of the first who installs it on a live environment with already 300+ client sites. In the rare situation it doesn’t work as it should, I know I can rollback to the previous version.
Out of curiosity I often do a compare between both version to get an idea what has changed. I’m not a developer, but I can read code, so it’s not just a black box for me.
Hi @maximejobin
I’ll have information about which changes were made soon, and I’ll update you via this thread as soon as I can.
I tested the version that I provided to you and didn’t observe any issues.
@josklever Thank you for your input. As a non-developer, I totally understand what you are saying. That being said, rolling back is not always possible. If the script sends emails, for instance, when it’s sent, it is sent. Also whatever action was completed between the installation and the rollback will be lost. That could be a huge issue.
@bojan Thank you for validating.
As I was unsure about the code status, I took a tool to compare the code between the current production version and the new version you posted here. In general, when I see “can you please try this?”… what I really read is “I haven’t fully tested, can you do it for me?”. This is not targeted to you as it seems you are not the programmer here.
Usually, when there is a bug, it needs to reproduced at will to be fixed. I provided everything you (MainWP) needed to do that. So the answer could’ve been : “we have officially released a new version that fixes the issue, please update your plugin”.
Unfortunately, that is not what I got…
Just by looking at the code, I can certify that this code was never successuflly tested. See this new code from the provided ZIP file:
The red arrow points to a column that does not exist anywhere in the database. I don’t even have to install the plugin to know for sure this won’t work.
And as the get_results() function is not handled properly in your code, the site does not crash but this function is useless.
But as you asked to try it, I took an hour to evaluate the code, create a DEV, create fake websites and upgrade the plugin. Then, I went to the Settings and clicked on “Save” as asked.
My debug.log is filled with SQL errors as expected:
Conclusion : whoever did this code never tested it successfully. It does not matter how many websites you have or if you use websites containing “www.” or “/”. It just doesn’t run.
I’m pretty sad and frustrated about the situation as I took probably 3 hours in total to report, investigate, test and write all this.
Note : English is not my first language. Nothing in this comment is intended to hurt or insult.
Hi @maximejobin, Thanks for the additional report, and let me apologize for the inconvenience.
I am bringing this to the dev team again, and I will make sure this gets reviewed and retested properly.
Please let me say that we always test code before we release or send code to users for verification, but in some cases, problems are hard to catch on our dev setups where we did not experience this problem before.
As I mentioned earlier, this will be reviewed and fully retested as soon as possible. I will keep you updated.
Thanks again, and let me apologize one more time for the oversight on the dev team side.
Hi @maximejobin,
I just wanted to follow up here and let you know that the dev team is working on this.
About an hour ago, I got an update from them to test, and as per my testing, the problems that you reported are resolved. I tested the update and everything works properly on my side.
I have tested syncing Monitors that were created in BU before connecting it to MainWP AUM Ext. and it works fine, as the rest of the functionality.
Before we push out the public release, we still need to fix a couple of PHP warnings and deprecation notices. But in the attached screenshot, you can see relevant changes.
@bogdan Thank you for your answers.
Let’s agree to disagree about the “we always test code”.
That being said, can you clarify what the whole sentence means exactly? From what I understand, you might try to fix code where you can’t reproduce the problem. Is that it?
I will gladly wait. Tested code, when you have a maintenance business, is even more important than in many other cases. We rely on it to serve our clients!
Thank you
Hi @maximejobin,
By saying we always test the code, I wanted to say that before we send code to clients for fix confirmation, we always check the version on our test setups to be sure it won’t cause additional problems. Of course, if we worked on fixing a bug that we could reproduce, we will confirm the fix on our side and release the update. However, when there is a case where we cannot reproduce the bug, but the dev team thinks some code change could help in the reported case, we pre-test the version to make sure it’s stable and send it to the user to confirm the fix or let us know that the fix is not good, so we continue working on it.
Yes, sometimes we have to try to fix the code even though we can’t reproduce the issue on our test setups. This happens if the dev team feels that they can do it. In case of bigger problems, we would usually ask for a temp access to the user dashboard where the dev team can run additional tests and necessary changes.
We completed the update, retested the extension functionality, and released version 5.2.3.
For transparency - here are the screen shots of the current patched version
I started fresh, created 2 monitors in BU:
Connected API and Monitors were pulled correctly:
Additionally, I created more monitors from the extension:
If, by any chance, the problem persists on your setup after the changes we made, I would kindly ask you to open a support ticket where we can collect more info and recheck.
Thank you one more time for reporting the problem and for all your help!
Thank you for your detailed answer @bogdan.
As for your tests in BetterUptime, I would have expected a website with “www.” at the beginning of the site name but also in the middle. If I had to test the problem that was reported, I would have added to my existing list something like this:
The first tests that a slash in the middle or the URL should be kept.
The second tests that the starting “www.” should be removed.
The third tests that the subdomain including “www.” should be kept.
The fourth tests that the slash at the end should be removed.
This would have confirmed that the “normal” use cases are still working and that the problems reported are now fixed.
From the posted screenshots, I do not see any tests related to the bug reported.
I hope this will help for future code testing and releases.
Have a great weekend!
Thanks for the detailed feedback @maximejobin . The team will make some changes based on your suggestions higher up in the thread such as notifying what has changed and if production ready for tests or not.
One of the things I did not see in your reply is if the fix worked or not.
If it did not please open a private Help Desk ticket so we can collect some additional information & investigate further.
Have a great weekend.
Hello @dennis ,
Glad to read about the future improvements!
I honestly can’t know. No ZIP file was provided!!
I tried to compile in my head the big screenshot provided by Bogdan… but I failed miserably!! Sorry… 
Have a great weekend!
The zip is in your account and should be available for update in your Dashboard. As @bogdan pointed out above.
Feel free to update whichever way you prefer.
Hello Dennis,
I’m sorry… I did not have the reflex to go in our account to download the new version manually. I went to our WP dashboard and it seemed like the update was not available.
I was able to get the update this morning and every website have synced successfully. That is great news.
I will monitor our monitors (!!) for the next days/weeks and get back here if there is an issue.
Thanks! 
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
