abitofmind
Forum Replies Created
-
FOUND THE PLUGIN CONFLICT
See as a ▶️ screen recording or read the description below.
I use the plugin My Private Site which hides the entire website behind a login wall for anonymous users.
Ideal for WordPress pages which are in the early building process and not yet ready for the eyes of the public and the spiders of the search engines.
It redirects all anonymous requests for
example.com/*tohttps://example.com/wp-login.php?redirect_to=YourRequestedURLwith HTTP status code 302 “Found” (also known as “Moved temporarily”).And Broken Link Checker seems to conduct its link tests simply as an anonymous user.
As soon as “My Private Site” is de-activated, it detects the broken internal links correctly.
PROPOSAL FOR BETTER COMPATIBILITY
Settings > Link Checker > Advanced
Gets this new setting:
“Check links as”: [ Anonymous User ▾ ]
Offers choices: Anonymous User | Admin | Editor | Author | Contributor | Subscriber | Specific User
When choosing “Specific User” then you get a text field nearby with the hint text “username”.
I imagine that WordPress has an API/calls for “request as…” and maybe also some sort of “sudo” hence no need to specify the password too. If that’s not the case then also offer a password field.
- This reply was modified 4 years, 8 months ago by abitofmind.
- This reply was modified 4 years, 8 months ago by abitofmind.
Dear Nithin, thanks for your info, I will try to isolate the bug by first disabling NestedPages, then further plugins, and last with the default theme.
And after each configuration change I will run “Re-check all pages” (a.k.a. the “nuclear option” as you call it drastically 😉 in the Settings).
And then tell you what behavioral changes I noticed after the configuration changes.
I think that you as the plugin developer already ship the best possible default selector, namely “a.broken_link, .broken_link”.
The plugin’s CSS-selector for broken links needs to select all broken links regardless in what parent elements they may reside, hence it has to be very general and can’t be too specific. So it is very likely that themes apply the attribute text-decoration with a more specific selector and hence take precedence. So the site administrator needs to take care of this, and see that the theme (or other plugins) contain no text-decoration attributes with more specific selectors or an !important flag. That’s seems to be the only possible way as also you outline it.
The only alternative idea I had was to maybe “artificially blow-up selector specificity” but I do not know any way to achieve that. Wrapping the A element into something else would be bad because it changes HTML markup and may break plugins or themes. And maybe still be for nothing because some selectors may still be more specific. And wrapping an A into 5 SPAN elements just to win the specificity game, even more terrible. And whether there are tricks with CSS selectors being artificially more specific than they need to be, I do not know any way to achieve this, but maybe there is? Do you know any?
- This reply was modified 4 years, 8 months ago by abitofmind.
- This reply was modified 4 years, 8 months ago by abitofmind.
Solved it myself, shared the answer above. Maybe helpful to somebody one day. 😉
Glad that my feedback is of help!
Thanks had a good day indeed, and now even better! The same to you!
Thanks! Glad that it gets tracked and considered in your team! All the best for it!
The competitor plugin FileBird already does so.
Btw, ▶️Broken Link Checker was successful with finding broken external link during initial scan a video which I recorded some days ago before today running into the issues with re-checking failing to detect broken internal links.
Hi Predrag,
thanks for your reply!
You achieved your reproduction with an active Redirection plugin I assume. And I without it! To not explode the issue here I put my experienced bug with a full reproduction into a separate support-ticket, and also have some renaming recommendations in another ticket.
Here, I would like to continue the overall/high-level discussion, what you see in the scope of your plugin, and what may be better off in core or other plugins?
From the research and tests conducted in the last 1-2 weeks, I meanwhile learned:
– 👍 All my issues can be solved with plugins (examination in link below)
– ❌ Except healing broken links in the markup when intercepting a slug-change during the event of saving a page or when pages in hierarchical structures are moved or parents changed their name.
– I outsourced these event based approaches:
– to Github.com/WordPress/gutenberg/
– as When changing a slug offer options to update internal incoming links
– It is full with a visual mockup story there. Check it out 🙂My questions to you:
– Would you like to extend your plugin to be event-based?
– Or do you think this is best/better off in Gutenberg?
– If so, could you think participating as a dev there?Regards, abitofmind
Thanks for looking up up in the code to confirm that your “404 solution” plugin automatically creates a redirect when a page or post slug is changed. So #5 of my criteria list is handled by it.
Wouldn’t it make more sense for the plugin to update the links on other pages at the time when the slug change was done, instead of afterwards?
Exactly! Fixing the problem at the root place (markup) and root event (saving page with slug change) should be the main strategy! Maybe you missed it, but I outlined this in:
2) When saving a page with a slug change going to all incoming links and repairing there.
But complimentary to that one would need a batch-process:
– for #3 initial cleanup
– or recurring #4 cleanup of things which “slipped through” #2 (if saving non API conform, i.e. direct DB editing).The plugin Broken Link Checker does #3 and #4. And not only for internal links but also for external links, where a cronjob is the only possibility, as in general you have no access to creation/change events of other websites except when using Linkback technologies.
From the overview I gained meanwhile:
– The only missing part in WordPress that is neither covered by a plugin nor core is #2, cleaning incoming links when saving.
– For integration into an existing plugin it would better fit into Broken Link Checker which operates on HTML markup level rather than your 404 solution which operated on HTTP transport level.Do you concur?
@aaron13100 thanks for the consideration!
Thanks for taking the time for stating so clearly your plugin’s scope! Thanks!
The plugin only captures 404s so there’s no preprocessing of the links that caused the 404s.
Ok, so it deals not with the cause (the broken link in the markup) but with the symptom. And for the symptom provides a permanent “medication” a redirect. But nevertheless the whole experience for that page which provide the broken internal link will always be a tad slower in nature, because there’s always a redirect.
What about when intercepting the symptom (404 for unknown resource) getting back to the high level cause (to the referrer URL) and there looking for the problem (the broken link in the markup). Could this be done in a companion-plugin?
If it’s not too much to ask, I’d appreciate if you could take a look at my feature-request
There I outline the other detection-possibilities:
2) When saving a page with a slug change going to all incoming links and repairing there.
3) A manually triggered bulk operation for legacy or special occasion cleanups.
4) A regular cronjob cleanup (to catch exceptions or for performance reasons).
5) And all that accompanied with automatic redirect entries to not loose SEO juice.If possible add a comment regarding feasability or effort-estimation. For doing this is in a fresh plugin. Or in core. And whether core or plugin would be the right place according to WordPress philosophy/system-architecture.
I’m a UX Designer, and can have some tech conversation, but am not qualified for questions on software architecture and thelike. Would highly appreciate your input!
Forum: Plugins
In reply to: [Content Anchor Links] Does the Linker part work with Gutenberg?@jdembowski I do not use reviews “as a stick” anymore and don’t crosslink to support threads. I learned that from your first intervention. And really took it to heart.
What you observed here is something different:
I spotted reviews which were just plain negative without providing any reason or explanation, in other words, very superficial and not helpful:https://ww.wp.xz.cn/support/topic/complete-waste-of-time-12/
The author fails clearly explain how to use the plugin. It has absolutely no use and is likely out of date.
https://ww.wp.xz.cn/support/topic/breaks-website-3/
Installed and broke my website…
And hence tried to bring some balanced info which summarizes the current tate of the plugin. What it does in essence, and which parts have what compatibility as of now. Hence in that date included a timestamp in the title to clearly state the datedness of this info. And hence the 3 start review (neutral).
How can such dull reviews like the ones above remain? What info value do they provide?
Ofc my review here is not from practical experience due to the Gutenberg compatibility warning but only a review of the info provided in the plugin description plus infos gained from the recent support articles. If that disqualifies it then please delete it. But then please also delete this other review(s) which provide no info only unconstructive negativity and hence distort the total impression IMHO.
Created https://core.trac.ww.wp.xz.cn/ticket/54069 with the title:
Media title change in “Attachment Details” dialog opened via Media Library Grid View is not informing API/plugins properly
Hi @tigroumeow,
thanks for confirming that the Media File Renamer integration in Real Physical Media is official.
And for your strong indication that the observed bug is likely in WordPress Core. Hence I will create a bug report there. Will add/post the link here later.