Intra-site link syntax is not resolved when using the summary plugin #314
Comments
justinmayer
changed the title
|
Related: getpelican/pelican#1342 |
|
This problem hit me too. But this is different from getpelican/pelican#1342. The I think the And I don't think the patch for getpelican/pelican#1342 would fix this issue, so I reworked the plugin here: https://gist.github.com/l04m33/7e93b0bb3ca0cfc6f2d0. But it's monkey patching and looks messy. It would be wonderful if Pelican itself provides some kind of pipelining for plugins to hook-in and process the content in a predefined order. |
|
Exactly, the problem is that some plugins fire on Besides summary, I found share_post and representative_image plugins are also affected. I don't see an easy solution other than creating a new signal "all_generators_finalized" after all the contexts have been generated in Would this be accepted as a (two) pull request(s)? |
Related to issue getpelican#314.
|
It sounds like a new "all_generators_finalized" signal would be beneficial. Pull request to that effect would welcome. |
|
I'm on it and proceeding wonderfully. But I guess future plugin developers should be warned to avoid |
clean_summary, read_more_link, representative_image, summary plugins now use all_generators_finalized signal so as to avoid issue getpelican#314. They fallback to current behavior is said signal is not yet available.
Some plugins have used `content_object_init` signal and read `summary`
or `content` properties of the content object. This resulted in
internal (`{filename}`) links being unresolved. When used, this signal
should hopefully mitigate that.
See also:
* getpelican/pelican-plugins#314
* getpelican/pelican-plugins#410
clean_summary, read_more_link, representative_image, summary plugins now use all_generators_finalized signal so as to avoid issue getpelican#314. They fallback to current behavior is said signal is not yet available. See also: getpelican/pelican#1616
clean_summary, read_more_link, representative_image, summary plugins now use all_generators_finalized signal so as to avoid issue getpelican#314. They fallback to current behavior is said signal is not yet available. See also: getpelican/pelican#1616 Closes getpelican#314.
Add signal: all_generators_finalized (see getpelican/pelican-plugins#314)
Related to issue getpelican#314.
clean_summary, read_more_link, representative_image, summary plugins now use all_generators_finalized signal so as to avoid issue getpelican#314. They fallback to current behavior is said signal is not yet available. See also: getpelican/pelican#1616 Closes getpelican#314.
Related to issue getpelican#314.
When using the summary plugin, if part of the post that is within the summary boundaries contains a link to another article (via {filename} links), the link is not created correctly for the summary.
The following example document demonstrates the problem:
On the created article page, the link will point to
/posts/hello-world, as expected. However, on pages that display the summary, the link will be to{filename}hello-world.rst(this is the exact content of thehrefattribute).Placing the link target within the summary boundary does not resolve the problem, nor does the use of inline link markup: ``another page <{filename}hello-world.rst>
_This bug happens on Pelican 3.4.0 and the current version of summary that is in the master branch. This bug may be related to #23, though that is purely based on the description of that one, not any form of test.
The text was updated successfully, but these errors were encountered: