New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 participants
@edelooff
Copy link
Contributor

edelooff commented Sep 23, 2014

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 [plugin: summary] Link to other posts in the summary do not work Intra-site link syntax is not resolved when using the summary plugin Sep 23, 2014

@justinmayer

This comment has been minimized.

Copy link
Member

justinmayer commented Sep 23, 2014

@l04m33

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
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 added a commit to kernc/pelican-plugins that referenced this issue Feb 1, 2015

@justinmayer

This comment has been minimized.

Copy link
Member

justinmayer commented Feb 2, 2015

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

@kernc

This comment has been minimized.

Copy link
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 added a commit to kernc/pelican-plugins that referenced this issue Feb 7, 2015

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 getpelican#314. They fallback to current behavior is said signal is
not yet available.

kernc added a commit to kernc/pelican that referenced this issue Feb 7, 2015

kernc added a commit to kernc/pelican that referenced this issue Feb 7, 2015

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

kernc added a commit to kernc/pelican-plugins that referenced this issue Feb 7, 2015

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 getpelican#314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

kernc added a commit to kernc/pelican-plugins that referenced this issue Feb 7, 2015

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 getpelican#314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

Closes getpelican#314.
@kernc

This comment has been minimized.

Copy link
Contributor

kernc commented Feb 7, 2015

Available for review:

Thanks.

justinmayer added a commit to getpelican/pelican that referenced this issue Feb 11, 2015

kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 4, 2015

kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 4, 2015

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 getpelican#314. They fallback to current behavior is said signal is
not yet available.

See also: getpelican/pelican#1616

Closes getpelican#314.

kernc added a commit to kernc/pelican-plugins that referenced this issue Jul 12, 2015

@hjpotter92 hjpotter92 referenced this issue Jan 29, 2016

Closed

Documentation #1

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