Again downloaded the latest pre-release version.
Now it isn't even showing the default image. It is just blank space.
Bah. Foiled again.
I'll contact you privately so the whole forum doesn't need to follow along with our debugging steps.
After a lengthy debugging process, vk_knight and I have determined that the issue was with a missing configuration option for
PHP's Client URL Library (curl) on his (local) machine. We successfully resolved the issue by following the steps in
this Stack Overflow answer.
Now that this issue has been resolved, I will add some finishing touches to the code, and then release the plugin's next version on the Extend site.
Many thanks to vk_knight for persevering through what must at times have felt like a never-ending process. We
did get there in the end, in no small part due to your patience.
Released version 1.2.0 with the following new features and bug fixes:
- Support different themes by caching preview data, not the preview itself.
- Bug fix: disabling previewers had no effect.
- Bug fix: set preview to empty on unresolved previewer.
- Bug fix: previewers weren't being auto-enabled on install/upgrade.
- Bug fix: add the missing "Disable link previews" checkbox to new thread / reply pages.
- Bug fix: only show the "Regenerate preview" links at the bottom of posts for links for which a preview is valid.
- Bug fix: add a missing hook for post merges.
- Bug fix: remove extraneous `';' from "new thread" output (thanks to srjrol for the bug report).
- Improve handling on
curl error.
- Document the possibility of debugging via the supplied
lkt-curl-functionality-checker.php script.
N.B. Your
inc/plugins/linktools/link-helpers-dist and
inc/plugins/linktools/link-helpers-3rd-party directories, if any, can safely be removed. They have been superseded, respectively, by the
inc/plugins/linktools/link-previewers-dist and
inc/plugins/linktools/link-previewers-3rd-party directories.
N.B.2. You should rebuild link previews by running the Recount & Rebuild task "Rebuild Link Previews for Link Tools" given that preview data rather than previews are now cached (see the first entry in the list above).
Released version 1.3.0 with the following new features:
- Show each preview immediately after the paragraph in which it occurs, rather than showing all previews at the end of the post.
- New setting: exclude previews for [url] tags enclosing [img] tags (for when the image is preview enough).
- New styling: prevent title and summary text from wrapping.
Thank you to @vk_knight for your testing and feedback.
Upgrade procedure: deactivate-copyfiles-reactive.
In the
parse_message_start hook you need to check if it is running for a post, something around the sort of the following code:
function lkt_hookin__parse_message_start($message) {
global $g_lkt_previews, $g_lkt_links, $mybb, $post;
if (!isset($post['pid']) || !(THIS_SCRIPT == 'showthread.php'
||
THIS_SCRIPT == 'xmlhttp.php' && $mybb->input['action'] === 'edit_post' && $mybb->input['do'] == 'update_post'
||
THIS_SCRIPT == 'newreply.php' && $mybb->input['action'] == 'do_newreply' && $mybb->request_method == 'post'
)
) {
return $message;
}
(2021-03-19, 09:37 PM)Omar G. Wrote: [ -> ]In the parse_message_start hook you need to check if it is running for a post, something around the sort of the following code:
OK, I've checked the addition of that code (although I used
empty rather than
!isset) and it doesn't seem to
cause any problems... but now I need you to explain the problem(s) that it
solves!
Oh, just think about the possibility of another plugin running the parser before the post is parsed itself, like a side box or anything that decides to embed new content in the page that uses the parser.
In my specific case that is a latest post side box embedded in all pages.
I think you try to work around that issue by taking into account the parsing of the signature, but there might be additional plugins that parse new content within the postbit hook (like my Signature Image plugin IIRC). I think my solution might fall short for these cases but I haven't checked.
Understood. Thanks for the fix! I've added it in dev code for the next release. And if you do find that this solution falls short for other cases, please let me know (as if that needed to be said!).
Hi, some suggestions: it seems like post embeds don't get refreshed on quick edits, 2) if the same link is used multiple times in the same post only the first link gets embeded.
I will come up with more
(2021-04-08, 07:51 AM)Omar G. Wrote: [ -> ]Hi, some suggestions: it seems like post embeds don't get refreshed on quick edits
Hi! If by this you mean that when you, e.g., add a new link to a post in a quick edit, the preview for the new link doesn't appear in the updated post when you click "Save Changes", then:
It very much should, and does on my local dev machine. If it doesn't for you, then that might indicate a bug, or an incompatibility with some other plugin that you've got installed.
Is the behaviour different to that on a full edit? If so, that's quite odd.
(2021-04-08, 07:51 AM)Omar G. Wrote: [ -> ]2) if the same link is used multiple times in the same post only the first link gets embeded.
Yes, that's by design. I thought folks would not want the same preview showing up more than once in a post, but maybe that's a mistaken thought?
(2021-04-08, 07:51 AM)Omar G. Wrote: [ -> ]I will come up with more
I imagine so.