• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

WP Toolkit - General Discussion

Client did something unorthodox:
they created a wordpress page with no title. All it displays is a few drawings of something to be build with one text line above it.

How I found it:
The wordpress toolkit showed plugins with no apparent use by any subscription.
Looking closer, there are plugins that have a blank between commas of subscriptions that use the plugin.

Took me a while to figure it out that there was a wordpress installation with no title. Took me even longer to find it in all the other wordpress installations listed.

My way around it, (as I know the client personally), enter a title and use CSS to dispay:none . But isn't really the way forward as I as admin shouldn't interfere with client side in that way.

Suggestion for improvement: If a wordpress installation has no title at all, instead of just displaying a blank, substitute it with the domain name of the wordpress installation.
 
UPDATE:
I made efforts to contribute a code patch on the WordPress Meta component (the site that hosts and promotes plugins with their respective descriptions and development details).
I made limited progress, which resulted in, IMHO another kludge on top of the existing kludge*. Since that has effectively been carried as far as the senior contributor(s) are willing to, I am once again making an appeal to this group to move this forward.
The current version of the Toolkit in my Plesk instance is: 4.3.1-2483. The request I made "to modify the plugin link targets to be consistent with how the WordPress Meta needs them to be" is still pending.
There was mention of sneak peek at a new design in development for this toolkit. I have not yet received a direct invitation to that.
I personally consider having a path to access the development "changelog" details of any plugins needing an update to be useful. I hope that any redesign of the toolkit maintains access to that resource in one form or other.
Thank you!

Prod Juan said:
Feature modification request (currently running extension version 4.1.1-2009)
(If this is the wrong place to submit mod requests, please advise so I can post accordingly. Thanks!)

In the "Plugins" tab (shown between Installations and Themes tabs), any plugin with an update available presents the following indication (for example):
--
[ ] Akismet Anti-Spam
( ! ) A new version is available. [Update to version #.#.# (link)] [View Details]
--
For plugins, the View Details link points to a URL off the wordpress.org site that ends with /changelog/.
That URL resolves to the "Details" tab of the plugin page, not the Development Tab.
My request is to modify the URL of the View Details link to end in /developers/ since that's where the change log details actually live on each plugin page.
In this case, the new link would be Akismet Anti-Spam
I suggest that the more useful information pertaining to a plugin with an update is what was changed within that update.
Thank you for considering this request. :)
Click to expand...

custer said:
Hi @Prod Juan,

This makes total sense. We are planning to redesign both Plugins and Themes tabs later this year, so I'll be sure to include this change as well. Let me know if you're interested in getting a sneak peak at the new design, I'd appreciate your feedback. ;)
Click to expand...

Prod Juan said:
Yes, I'm interested in the sneak peak you offered. :D Thank you for the prospective implementation estimate.
Click to expand...

* the first kludge: relay on a innovative JavaScript statement which directs the browser to think someone clicked on one of the tabs of content mid-page WHILE THE PAGE IS STILL LOADING. The render of the content is based on WHEN the browser considers the URL in the address bar and applies the (rather elaborate) CSS rules to make the intended content visible on the page. This is all well and good AS LONG AS the processing of the URL value happens AFTER the page loads.
** most recent kludge: apply a JavaScript delay function to the browser location hash so that maybe the execution will happen later in the page-load sequence. This again leverages another script-based approach that depends on the browser acting upon it relative to how much of the page data has arrived from the server to process. I'm not satisfied with this either. In my case, the results are at best inconsistent between different computers using the same browser. I'm not satisfied with how this resulted but I gave it the "college try". (The browser has been observed to initially show the Developer tab content, then a second later, act as if the 'Details' tab was clicked (with no user action). I have one more thought of how to fix this at the destination point but I've lost motivation after that experience. I may make other contributions to their system, but this issue in their eyes is effectively "closed" (see ticket details)
 
Hi @Prod Juan,

I've re-checked your initial proposal, and both Akismet links you mention forward me to Akismet Anti-Spam, where the changelog is displayed. Can you please clarify how exactly you'd like WPT to behave in this particular regard?
 
Thank you for your request of clarification.
If you watch the browser address bar carefully, you'll notice a redirect occurring by the server. What you're observing is the result of the redirect taking the browser ultimately to the developer tab. There are known problems relying on the redirect to take the browser to this page. Part of the time, the browser continues showing the Detail tab.

I don't know how better to clarify what I expressed earlier:
For plugins, the View Details link points to a URL off the wordpress.org site that ends with /changelog/.
That URL resolves to the "Details" tab of the plugin page, not the Development Tab.
My request is to modify the URL of the View Details link to end in /developers/ since that's where the change log details actually live on each plugin page.
Click to expand...

Just make it so when the user arrives on the WordPress site, neither the page nor the server has to "translate" the link into the desired ultimate destination URL.
I feel like this is a straightforward concept and any more description of what should happen will repeat what has already been described in the initial report.

I have high confidence that when the WordPress site sees ONLY the /developer/ URI, the browser will consistently and reliably present the developer tab to the user.

custer said:
Hi @Prod Juan,

I've re-checked your initial proposal, and both Akismet links you mention forward me to Akismet Anti-Spam, where the changelog is displayed. Can you please clarify how exactly you'd like WPT to behave in this particular regard?
Click to expand...
 
Prod Juan said:
Just make it so when the user arrives on the WordPress site, neither the page nor the server has to "translate" the link into the desired ultimate destination URL. I feel like this is a straightforward concept and any more description of what should happen will repeat what has already been described in the initial report.
Click to expand...

OK, got it. This is now fixed in the upcoming WPT 4.4 release. Sorry it took so long!
 
@ellagill, this most likely means that your Nginx is working while the Apache or PHP backend isn't. There can be any number of reasons for this, you'll have to consult the log files to find out what is going on.

I'd also advise you to open a separate thread in a different section of the forum, depending on your Plesk version, as this issue isn't directly connected to the WodrPress Toolkit. You'll get more answers this way.
 
custer said:
Hey everyone, we have published WordPress Toolkit v4.4.0 update -- check out the full changelog at WordPress Toolkit - Plesk Extensions and let us know what you think!
Click to expand...

1) the links back to the wordpress.org/plugins/ for "View Details" in the Toolkit "Plugins" tab now targets the "#developers" rather than "/changelog" -- THANK YOU!!! :D :D :D :D :D

2) after applying updates for selected plugins using the [update] button at the top of the plugs list, the status box in the lower right corner no longer has a "refresh page" link to reload the page and reflect the updated plugins as updated?!? ‍:(:confused: I don't follow the logic of this change.

3) When I used to load the plugins list, there was a banner above the list showing a type of scoreboard report of how many plugins had an update available, and how many themes had an update available. Now that scoreboard display no longer appears, so I have to scroll down the whole list of plugins to see whether there are any updates to apply. I don't follow the logic of this being removed either. ‍:confused:

4) What-If #1a: (Cosmetic suggestion) there was a filter button that would toggle between 'show all plugins' and 'show plugins needing updated' (or similar verbiage). The mechanics of this button could be either 1) a CSS rule based approach to apply 'display:none' the rows of plugins not having an update available, or 2) a soft-reload of the list that actually suppresses the plugin rows there is no update available for
What-if #1b: apply a sort priority to those plugins/themes needing an update so they were at the top of the list together and list the others not needing updates below the first group. This would ease the process of selectively updating those items without the need to scroll down to find them.

5) What-If #2: (Cosmetic suggestion) when the plugs/themes list was scrolled, the area above the list was "sticky" ... I'm referring to the button row and the column headings "Name" + "Installed at". This would provide a smoother UX when the checkbox near the bottom of the list was checked, the user wouldn't need to scroll-to-the-top just to click the [Update] button to handle multiple (or even just a single) plugin/theme update with that [Update] button above the list.
I managed to help at least the button row to become sticky by adding these CSS rules to the ".pul-list" rule in List.less file:

max-height:calc(100VH - 302px); /* offset by other element heights */
margin-top:1px; /* small break below button bar */
overflow-y: scroll;
display:block;

Not sure exactly why the 'display:block' must be there, but it had to be to force respect for the height clause. maybe the 'table' display disregards the height constraint in CSS but obviously respects the 'block' display. (YMMV.)

Thanks for giving these ideas some consideration! :D
 
Last edited:
TomBoB said:
Suggestion for improvement: If a wordpress installation has no title at all, instead of just displaying a blank, substitute it with the domain name of the wordpress installation.
Click to expand...

That's one way to improve the situation.
What about offering the option of listing all the WordPress by domain vs by site title because I've encountered cases with different domains hosting WordPress sites that share similar (or the same) title. That made maintenance more work than necessary.
 
I am still getting these daily, is anyone else having this issue in Plesk Obsidian?

grumbi84 said:
Hello,

am I the only one who gets this message since the last update?

First I got it only for one domain. After deactivating this domain I start getting it for other domains, too.
wp-config.php is clean, we run updates every month, several anti-virus and online scanner show nothing suspicious, everything clean.
Google shows clean SERPs.

Interesting thing is, that the installations are not getting quarantined. Some look quarantined in Wordpress Toolkit, but are accessible through the web.

I don't even know where to follow up on this issue.

--

The following WordPress installations are quarantined:

Website "xxx" (https://xxx.tld): WP-CLI command has not finished working in 60 seconds, so it was terminated. Usually this means that there are problems with WordPress installation itself, for example it could be infected with malware. Check the wp-config.php file of the installation for potential malware code.
Click to expand...
 
Prod Juan said:
This announcement was posted on 12/5/2019.
This site, which promotes the toolkit, still refers to version 4.3.4.
What is needed for that page to be updated? (Is that something I could help with?)
Click to expand...

Hi @Prod Juan, thanks for noticing this! I've contacted the responsible parties, we'll start working on a fix very soon.
 
Mark@beeldr said:
I am still getting these daily, is anyone else having this issue in Plesk Obsidian?
Click to expand...
Hello!
Usually this means that we did not get an answer from WPCLI during quite a big timeout. Does this issue remain when you are trying to refresh this WP installation manually using the "Refresh" button on instance's card?
 
@custer - seems the new Version 4.5.0-2944 has a small glitch at security & updates as well
Plesk Onyx & Obsidian
Ubuntu 16 & 18
1580146892922.png
 
We confirm a bug with ID EXTWPTOOLK-4324 which will be fixed in the nearest release.
We fixed locales and seems like we've overfixed this a little :(
 
You must log in or register to reply here.

Similar threads

G
Question WP installs are quarantined daily.
Replies
4
Views
634
Bobbbb
B
W
Issue scheduled task ERROR | /opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/wp-toolkit/scripts/instances-auto-update.php'
Replies
3
Views
906
Wolfgang Reidlinger
W
custer
  • Sticky
WP Toolkit - Product News
2 3
Replies
52
Views
14K
Kaspar
K
V
Resolved Error when opening Wordpress Instances Overview in Plesk
Replies
7
Views
3K
vic666
V
B
Forwarded to devs Wordpress toolkit - odd behavior: Change of preferred domain triggers password change and makes admin interface inaccessible
Replies
2
Views
2K
IgorG
IgorG
Back
Top