Intra-site link syntax is not resolved when using the summary plugin

[edelooff]

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:

Example blogpost
################

:date: 2014-09-23

This article contains a link to `another page`_

.. PELICAN_END_SUMMARY

.. _another page: {filename}hello-world.rst

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 the href attribute).

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.

[justinmayer]

Related: getpelican/pelican#1342

[l04m33]

This problem hit me too. But this is different from getpelican/pelican#1342. The summary plugin tried to mutate the _summary attribute of Content objects during content_object_init, but the filenames in pelican's context is not fully populated yet.

I think the summary plugin (or any other plugins) should only make a call to Content._update_content(...) after all generate_context methods are called.

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.

[kernc]

Exactly, the problem is that some plugins fire on content_object_init signal and request the objects's summary or content sometimes before the dependent, linked-to content objects have been processed, so they don't exist in self._context['filenames'] when looked up.

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 Pelican.run(), and then amending the plugins to use that signal instead, as @l04m33 recommended.

Would this be accepted as a (two) pull request(s)?

[justinmayer]

It sounds like a new "all_generators_finalized" signal would be beneficial. Pull request to that effect would welcome.

[kernc]

I'm on it and proceeding wonderfully. But I guess future plugin developers should be warned to avoid content_object_init altogether if they do any mangling which includes reading of _content.

[kernc]

Available for review:

• Add signal: all_generators_finalized (see getpelican/pelican-plugins#314) pelican#1616
• Have relevant plugins use all_generators_finalized signal #410

Thanks.