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

Closed
edelooff opened this Issue Sep 23, 2014 · 6 comments

Projects

None yet

4 participants

@edelooff
Contributor

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 justinmayer changed the title from [plugin: summary] Link to other posts in the summary do not work to Intra-site link syntax is not resolved when using the summary plugin Sep 23, 2014
@l04m33
l04m33 commented Oct 27, 2014

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
Contributor
kernc commented Feb 1, 2015

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)?

@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Feb 1, 2015
@kernc kernc share_post: Don't read summary as it's not used anywhere
Related to issue #314.
5e7971c
@justinmayer
Member

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

@kernc
Contributor
kernc commented Feb 3, 2015

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 kernc added a commit to kernc/pelican-plugins that referenced this issue Feb 7, 2015
@kernc kernc Have relevant plugins use all_generators_finalized signal
clean_summary, read_more_link, representative_image, summary
plugins now use all_generators_finalized signal so as to avoid
issue #314. They fallback to current behavior is said signal is
not yet available.
be56eeb
@kernc kernc added a commit to kernc/pelican that referenced this issue Feb 7, 2015
@kernc kernc Add signal: all_generators_finalized (see getpelican/pelican-plugins#314
)
725945d
@kernc kernc added a commit to kernc/pelican that referenced this issue Feb 7, 2015
@kernc kernc Add signal: all_generators_finalized (getpelican/pelican-plugins#314)
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
265f68a
@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Feb 7, 2015
@kernc kernc Have relevant plugins use all_generators_finalized signal
clean_summary, read_more_link, representative_image, summary
plugins now use all_generators_finalized signal so as to avoid
issue #314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616
da0e500
@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Feb 7, 2015
@kernc kernc Have relevant plugins use all_generators_finalized signal
clean_summary, read_more_link, representative_image, summary
plugins now use all_generators_finalized signal so as to avoid
issue #314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

Closes #314.
5688b8d
@kernc
Contributor
kernc commented Feb 7, 2015

Available for review:

Thanks.

@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 4, 2015
@kernc kernc share_post: Don't read summary as it's not used anywhere
Related to issue #314.
9839f4e
@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 4, 2015
@kernc kernc Have relevant plugins use all_generators_finalized signal
clean_summary, read_more_link, representative_image, summary
plugins now use all_generators_finalized signal so as to avoid
issue #314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

Closes #314.
8b0f9e5
@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 12, 2015
@kernc kernc share_post: Don't read summary as it's not used anywhere
Related to issue #314.
fcdab23
@kernc kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 12, 2015
@kernc kernc Have relevant plugins use all_generators_finalized signal
clean_summary, read_more_link, representative_image, summary
plugins now use all_generators_finalized signal so as to avoid
issue #314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

Closes #314.
246fd05
@justinmayer justinmayer pushed a commit that closed this issue Jul 13, 2015
@kernc kernc Have relevant plugins use all_generators_finalized signal
clean_summary, read_more_link, representative_image, summary
plugins now use all_generators_finalized signal so as to avoid
issue #314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

Closes #314.
246fd05
@hjpotter92 hjpotter92 referenced this issue in JenkinsDev/pelican-readtime Jan 29, 2016
Closed

Documentation #1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment