Alexandre Froger

Hello!

I just tested adding a user with an @ character in the username, and it works as designed. The issue must be elsewhere.

Since you mentioned 3rd party software; this is somewhat out of the scope for this forum as outlined in the main description, however I would first eliminate this possibility by testing adding/updating an account the default way, and after ascertaining this works, take a note of the data sent by adding traces in the code if needed, then look into the 3rd party process and make sure the user_register action is called when a user is created, as well as other hooks and look into what the data looks like, for comparison.

Code to put in theme’s Additional CSS field – updated for empty lines support with highlight and blur:

/**
 * Line wrap support
 *
 * Use the class force-wrap in the block under
 * "Advanced" > "Additional CSS class(es)"
 */
div[class*='code-block-pro'][class*='force-wrap'] pre span.line.cbp-line-highlight .cbp-line-highlighter,
div[class*='code-block-pro'][class*='force-wrap'] pre span.line.cbp-no-blur:hover .cbp-line-highlighter,
div[class*='code-block-pro'][class*='force-wrap'].cbp-highlight-hover:not(.cbp-blur-enabled:not(.cbp-unblur-on-hover)) pre span.line:hover .cbp-line-highlighter,
div[class*='code-block-pro'][class*='force-wrap']:not(.code-block-pro-editor) pre span {
    white-space: pre-wrap;
    min-height: 100% !important;
    min-width: 100% !important;
}

div[class*='code-block-pro'][class*='force-wrap']:not(.code-block-pro-editor) pre span.line span:empty:not(.cbp-line-highlighter)::before {
    content: ' ';
    visibility: hidden;
    opacity: 0;
    min-width: 100% !important;
    min-height: 100% !important;
}

Hi Kevin, and thank you for the reply!

 I’ve just decided that text wrapping isn’t a feature I want to support globally.

An option like there exists for ignoring parsing shortcodes would have been nice, but fair enough, and well understood – development time is not free, even in free plugins, so I can very much relate. It is a pity that the only potential solution is putting other features at risk of breaking.

Can you explain what you mean by this?

I simply meant it is a well-known anti-pattern (a quick Google away can confirm) and a code-smell; it was more of a general statement, as it often nullifies possibilities of override no matter the selector specificity. As stated though, technical challenges for wide theme support make its usage here somewhat justifiable.

I’ve been trying to bring support to highlight/blurring with line wrapping (and that’s where !important has begun to rear its ugly head). Below is some updated code, if it helps anyone. Empty lines still don’t highlight on hover because they end up with a height of 0 though, and that’s currently my main focus.

div[class*='code-block-pro'][class*='force-wrap'] pre span.line.cbp-line-highlight .cbp-line-highlighter,
div[class*='code-block-pro'][class*='force-wrap'] pre span.line.cbp-no-blur:hover .cbp-line-highlighter,
div[class*='code-block-pro'][class*='force-wrap'].cbp-highlight-hover:not(.cbp-blur-enabled:not(.cbp-unblur-on-hover)) pre span.line:hover .cbp-line-highlighter,
div[class*='code-block-pro'][class*='force-wrap']:not(.code-block-pro-editor) pre span {
    white-space: pre-wrap;
    min-height: 100% !important;
    min-width: 100% !important;
}

Using recommended snippet in the theme’s additional CSS does the trick:

div[class*='code-block-pro']:not(.x) pre span.line {
    white-space: pre-wrap;
}

However, to also keep the default functionality, using a class like force-wrap on the block, and changing above like the following allows to give the choice per block:

div[class*='code-block-pro force-wrap']:not(.x) pre span.line {
    white-space: pre-wrap;
}

I still feel this should be a block option though, so I will not mark as resolved just yet.

Hi!

Do you mean you had UP Server and Dummy Plugin on the same instance of WordPress?
If that was the case, this is definitely the issue: when WordPress attempts to go into maintenance mode to get its plugins updated, it cannot serve updates at the same time!

If that was indeed the source of the problems, then I am glad it was discovered and that you are able to start providing updates!

Hi!

How much control do you have over the server? You mentioned that the debug log is empty. Which file is the debug log? This seems odd that there is no trace of the issue – are you the sole admin of the server, or is there some support you can contact?

Some possible areas to check:

• Nginx error logs (/var/log/nginx/error.log)
• PHP-FPM logs (/var/log/php-fpm.log)
• WordPress debug logs (enable?WP_DEBUG?in?wp-config.php)
• Use?top,?htop, or?free -m?to monitor CPU, memory, and disk usage.
• Test Nginx configuration:?sudo nginx -t (and reload Nginx:?sudo systemctl reload nginx )

Hi!

Thank you for reminding other readers of this forum that htaccess is only relevant for Apache.
Indeed, this is why UP Server does not in any way rely on htaccess for its endpoints, but instead uses add_rewrite_rule core WordPress function.

If the issue came from URL rewrites, then you would experience a 404 error, not a 503.
Common causes of 503 are that a server is down for maintenance or overloaded – I cannot establish whether this apply in your case.
If the issue came from URL rewrites, you would also not be able to reach the JSON output API.
Moreover, UP Server does not in any way exit with a 503 error code.

For all these reasons, the issue cannot come from URL rewrites. This issue cannot be about how NGINX rewrite rules with this plugin specifically in contrast to how Apache does it. If there is a configuration issue that affects UP Server, it is elsewhere.

Because I cannot have access to the server configuration, I can only let you know what my test environment looks like. Yes, I do use Apache, but as determined above, the issue is not related to how it rewrites urls.

I do hope this can help, and if not, that we can continue troubleshooting with more information and diagnosis from your side.

Thanks for the details.

Here are the outputs of Step 7:

More importantly:

7. Copy this URL and open it in your browser: the download should start

What is happening when you visit the URL (with an updated token, and pretty-printed as outlined in step 6, not with all these backslashes):

"download_url": "https:\/\/www.domain.com\/updatepulse-server-update-api\/?action=download&package_id=dummy-plugin&update_type=Plugin&token=a82b2dc2cd1484cc7b6bd14197167202",

It looks like that your API-URL gets rewritten by WordPress on nginx with permalinks.

UP Server does not alter the main htaccess file in any way. It relies on WordPress’ internal mechanism using add_rewrite_rule.
Since you do get an output on the updatepulse-server-update-api/?action=get_metadata endpoint, you can be sure the plugin’s API permalinks are therefore working.

Hi!

The trace does not seem to indicate anything related to your error. the %2F is actually required: it’s encoding the parameter so that the slash not considered a URL fragment. You can see it in all update links – for instance, for WooCommerce:

https://sub.domain.tld/wp-admin/update.php?action=upgrade-plugin&plugin=woocommerce%2Fwoocommerce.php&_wpnonce=84b468e2wf

Circling back to the procedure outlined earlier:

• Question 1: what happens at step 7?
• Question 2: If nothing unusual happens at step 7, are you able to update any other plugin not using UP Server? You can edit the plugin version manually (in the example, I changed “* Version: 9.7.0” to “* Version: 9.6.0” in woocommerce%2Fwoocommerce.php to get the above URL).

Hi and thank you!

Here is what I have on my test environment (see the URL, properly encoded).
Do you have anything different? Could you provide a screenshot?

Hi there!

Could you please give more details? Which url are looking at with “the URI”? And what parameter in that URI is supposed to contain forward slashes?

Best

Hello and thank you for your interest in UpdatePulse Server!

Preliminary Troubleshoot

If you’re willing, we can attempt doing some troubleshooting.

1. Please first update to 1.0.3 – I just released a new version addressing the warnings you reported (thank you!), among a few other things
2. In your UP Server’s Packages Overview, click the “Details” link of the package for which the update failed.
3. Check out the update_url down the bottom of the JSON info (it’s new!)
4. Copy this URL and open it in your browser: you should see the same JSON your plugins see when they attempt to check for update
5. If the package you attempt to update does not require a license (which would be ideal for troubleshooting purposes), you should see a download_url property (note how this URL has a token – the next steps to test should be undertaken ASAP so that it does not expire) ; this is the URL your plugins use when they attempt to download an update
6. Make sure to enable Pretty print in your browser to get rid of the extra slashes in URLs (Chrome has a checkbox at the top, for instance)
7. Copy this URL and open it in your browser: the download should start
8. Report here anything unusual

While doing the above, the following would help:

• Keep an eye on the PHP logs
• Use the Dummy Plugin from the UpdatePulse Server Integration Examples repository – this is what I use to test

Going Further

If you’re willing, we could try and explore with more direct involvement.
Please do not give me any credentials or do not create any account on any site for me.
What we could do, though, is attempt a package update from my end, I could replicate your issue, and check the actual response from the update API.

Here are the requirements for more advanced troubleshooting:

• Provide the home URL of your UP Server in Link to the page you need help with (like https://your-updatepulse-server.tld)
• Provide updates for the Dummy Plugin package with no license requirement through your UP Server

Please let me know!

These keys can be generated with any tool of your choice, for example https://randomkeygen.com/

As long as they are long, secret, and the same on all the connected sites, you’re good to go!

Hi @kingcooper

I performed a full test on my installs with the same settings you linked above in the various screenshots, and could not reproduce the issue.

Moreover, I tried to test again on https://integritytoysales.net (I checked that https://integritytoysales.net/wprus/[action] are working, getting a blank page where action is update for instance).
I also could not reproduce the issue: I received the email, and clicking the link landed me on the expected password reset page.
Please see attached screenshots.

The password got reset successfully.

These tests were made before receiving:

I removed other syncs, and only have login, logout, and password now.

But I am not sure if the settings had changed in the meantime.

Please let me know how the troubleshoot goes, specifically if you can narrow it down to a specific actions combination.

Hi @kingcooper ,

Thanks for these.

Could you please also include one of the site’s settings showing which actions are activated (like in below screenshot – please ignore the red lines)?

Also, I see 3 sites connected: does the issue happen with only one?

Best,