(2021-02-22, 02:20 PM)vk_knight Wrote: [ -> ]The link is live and well.. If that what you are asking..
That's part of it, but I'm guessing that it's being handled by the default Link Previewer, which only performs some generic data extraction such as the <title></title> tag for the top line of the preview, and the first (if any) <img> tag, or the "meta" tag with property "og:image" for the image to the left in the preview, and the "meta" description tag or the first bit of plain text pulled out of the page for the bottom line of the preview.
It's impossible for me to know whether this has been done "correctly" by the plugin without you letting me know what the link is. And even if it has been done "correctly", you might have a case that shows that the plugin's current "correct" is in fact "incorrect".
All of which is to say, pretty please, can you share the link with me? You can do it privately if you prefer.
(2021-02-22, 02:37 PM)vk_knight Wrote: [ -> ]Here is the full image that showed after clicking 'Regenerate Preview'..
![[Image: Capture.png]](https://camo.mybb.com/254b32495768ba7b169d38fee01154402775a40b/68747470733a2f2f692e6962622e636f2f4b3037537a6e6e2f436170747572652e706e67)
And here is the link https://www(dot)seroundtable.com/google-...30726.html
Huh. That's odd. When I post a new post with that link (
(dot) replaced) on my local dev machine, I get this preview:
[
attachment=43812]
I wonder whether perhaps you're encountering an error with the curl libraries not being installed? That's pretty much all I can think of at the moment.
(2021-02-22, 02:37 PM)vk_knight Wrote: [ -> ]And get some rest man !! I am also tired today. We shall resolve it later.
Oh, now that I've drunk all of that caffeine you tell me. :-D
That's fine, buddy. I'll be up for a little while yet if you have any energy left before retiring, otherwise, yes, let's get back to this later!
(2021-02-22, 02:45 PM)Laird Wrote: [ -> ]I wonder whether perhaps you're encountering an error with the curl libraries not being installed? That's pretty much all I can think of at the moment.
Which probably makes no sense, because in that case you no doubt would have gotten an explicit error about an undefined function. Hmm. Very puzzling.
Oh, one other by the way: what do you see if/when you click "Return to post"?
(Edit: As this implies, the regeneration link isn't intended to, and doesn't, show the preview itself, only an indication of whether that preview was regenerated. You have to return to the post to see the preview that it's regenerated).
I thought that maybe because the link already existed so it was creating the problem.
So, now I posted the link. And still it is showing the problem. Anyway, get some rest & I shall do the same. Thanks again.
We shall resolve it later.
Rest well then. We'll see what we can come up with later.
Hi, you should add some development setting to force the usage of templates directly. Currently, if I rebuild from the ACP it seems the plugin will use the templates from the master template set instead of custom ones (because the ACP doesn't load the front end template set anyways).
Also, rebuilding from the posts don't seem to work at all, it says rebuilt was done but the link preview isn't updated (I suppose it updates the link data but not the cached preview template).
Also, overall caching the final output seems like a bad idea, because MyBB supports multiple themes at the same time, thus to be mybb compatible you would need to cache one entry per template set. Otherwise the caching isn't theme friendly.
Additionally, I did set Scope of Rebuild Link Previews entry to All, but this doesn't change the front-end behavior, it only updates all previews if using the ACP rebuild tool (which causes one issue mentioned above).
Hi, and thanks for that feedback, Omar. It's very helpful. You're right about link preview caching: it only supports a single theme (which seems to be the Default theme though, not Master as you suggested, but perhaps we are experiencing things differently for some reason). This is something that I didn't think about at all when developing the plugin, which is an unfortunate oversight.
Note that some Link Previewers don't cache at all, and are not affected by this problem (currently: the "YouTube video" and "Twitter status" previewers).
Perhaps, rather than adding a new development setting, you would find your needs sufficiently met (for now) by either:
- Working with these non-caching previewers where possible.
- Otherwise using the "Regenerate preview" link in the bottom-right corner of a post with a cached preview while developing (whilst editing the Default theme's templates).
To address the deficiency you've picked up, which would permanently avoid the need for the setting you've requested, perhaps the best approach is for each caching Link Previewer to cache in serialised form the information it needs to regenerate the preview rather than the preview itself (e.g., page title, summary, and image url), and then to supply that to the template engine to generate the final preview when the thread is rendered.
Huh. And there I was thinking this feature was basically good to go. Good thing it was only a development release after all.
Hi, it might be the default theme, yes, I didn't make sure if it was either that or the master templates set.
This feature ("full cache") might be useful for big boards, which usually stick to a single theme, but perhaps adding a setting to either cache the rendered preview or to build it every time with the serialized information. I think you could do both, without necessarily dropping what you already implemented (which I genuinely think might be useful for big boards).
Well, prior to seeing your post, I'd decided to simply edit the code so that previews are rendered from cached serialised information rather than being cached as a final render, so, even if the original might have been (only slightly?) better for big boards, it won't be supported going forward. To do so would, I think, complicate an already complicated codebase too much. You can try to convince me otherwise if you like but it would be an uphill slog.
If you're willing (and I very much appreciate how willing you *have* been so far), you can test these changes by pulling the latest commits from GitHub. Based on my testing, different themes are now able to render differently for all Link Previewers, including those based on cached data, notably the Default previewer.
I hope that @vk_knight also updates from GitHub, and with any luck, the problem s/he was having is now solved (although I don't know what was causing it in the first place, and that's troubling).