@skjnldsv The points you raise are about SEO, and (from what I linked to above) I believe those issues are already being worked on. In case I was unclear, I’m not arguing for my idea to supplant the SEO work currently in progress, but to augment it.
Obviously, if #915 gets implemented as requested, my issue becomes moot, but from reading the comments there I understand it’s not so cut and dried that it will be.
As discussed in #915 and #517, Google seems to prefer old versions’ documentation at the expense of newer ones for some reason. The issue was partly mitigated by the fix for #958, which added prominent links to the latest version on top of old pages.
But these links currently point to the manual root. Ideally, I’d like these links to point directly to the latest version of the specific manual page I’m viewing, if available.
For instance, a search for nextcloud occ (for me at least) currently yields the manual page for version 9 as the top result. The ”latest version” link at the top then takes me to the server manual introduction. This means it’s still easier for me to navigate to the latest version of the ”Using the occ command” page by manually replacing the version number in the current URL with ’stable’ (or the latest release number) than to follow the ”latest version” link and try to find the page there.
Producing specific links is probably more laborious than the generic top-level-pointing link. For instance, there may no longer be a corresponding page in the stable version. Detecting such cases should be automatable I think, but there may be other issues that aren’t.
This will be much less of an issue once the SEO issue is resolved, but I think direct links would still remain useful, as people can still come up with search terms that search engines think correspond to old documentation better than the latest.
As a workaround, copying the icons and manifest from public to domain root seems to work (with Wekan snap running behind Apache here). As the files have a wekan- prefix, collisions shouldn’t be an issue. Naturally, this solution does require write access to the domain root directory.
Nope, Chrome manifests this too:
Server Setup Information:
Problem description:
Since (at least) a few days back, my web console (in both Firefox and Chrome) is logging this error whenever I open a card. The same error is also logged for opening a board. Additionally, in the more compact view (when the browser window is small, as in the gif I’m attaching), expanding a list causes the same error, as does closing a card.
This doesn’t seem to affect any functionality AFAICT (although I did notice this while investigating why vertical scrolling within a card is suddenly very slow, but that is probably unrelated and possibly local).
The attached animation is from a fresh install with just the user account and one test card created.
Steps to reproduce:
What happens:
”Exception from Tracker afterFlush function”, ”ReferenceError: Ps is not defined”. Web console log attached.
If using Snap, output from sudo snap logs wekan.wekan
(Nothing during the error event)
Peek animation:
Alternatively, after adding the PPA, replace ’cosmic’ with ’bionic’ in the sources list, as the package for Bionic currently appears to install and work in Cosmic just fine (from my brief testing).
The release of WordPress 5.0 brought up an issue with the use of gutenberg_parse_blocks() in aesop.php: apparently for WP versions with Gutenberg integrated, parse_blocks() should be used instead of gutenberg_parse_blocks(), otherwise a fatal error occurs when Gutenberg tries to redefine WP_Block_Parser_Block.
You can reproduce this even with Twenty Nineteen, by adding <?php $blocks = gutenberg_parse_blocks( $post->post_content ); ?> to header.php.
Replacing gutenberg_parse_blocks() calls with parse_blocks() seems to work around the issue (for me at least), and the issue here, if any, is apparently just one of confusion: renaming the function broke backwards compatibility, but since gutenberg_parse_blocks() is still defined, instead of a ”Call to undefined function” you get this attempt to redefine WP_Block_Parser (via inclusion of parser.php), resulting in the ”name is already in use”.
”Using the occ command” documents using versions:cleanup either globally or for specific users, with example invocations for both cases. However, said examples are identical in the current revision:
This example deletes all versions for all users:
sudo -u www-data php occ versions:cleanup Delete all versions Delete versions for users on backend Database […]You can delete versions for specific users in a space-delimited list:
sudo -u www-data php occ versions:cleanup Delete versions of freda Delete versions of molly
Unless I’m misinterpreting this, the latter example should have the space-delimited list of users following the invocation, like so:
sudo -u www-data php occ versions:cleanup freda molly