Stable links to fragments identifiers into paginated posts enhancement

  • Trebly

    (@trebly)


    10 years ago

    Hi,

    It seems well that : when paginated posts are used the common fragment identifiers cannot be used easily (see detailed note), because the pages are identified by their number (page=<num_page>) which is not a stable data.
    This makes quite impossible to develop and test internal links and maintain long paginated documents with many fragments identifiers because pagination can easily change.

    After researches of existing solutions, I decide to develop “something” which is quite fully designed, the feasibility checked, too some main parts of code.

    For now, because I am new in WordPress developments I need some help.
    I don’t think at all that the problem is only a pluging problem.
    There are some things that I don’t know how to do for hacks.
    I do not know anymore where are good existing examples.

    The development features are :
    (to avoid errors we replace the “page” of paginated post by the “section” word : then a post can have sections)

    – A section can be named by the use of a shortcode associated with <!–nextpage–> into the document.
    – optional replacement of the url of section identified currently by his number : <permalink>/<num_page>/
    by
    A new syntax which is the unique way (in my opinion) to reach a fragment into a paginated post
    <permalink>/section/<section_name>/

    – determine and store the post datas which describes the post sections (needs a wp enhancement – add a column to post table, or badly a special table like for a plugin for storing the pagination data, updated when the post is saved) containing :
    post, version : table (json) with for each section (section_name, title, page_num)

    Then the steps of url treatment are :
    – with a add_rewrite_endpoint it becomes
    <permalink>/?section=section_name

    – with add_rewrite_tag we can get the new query arg [‘section’]
    – read first the sections data (pagination) from data base using the permalink

    Then I need to set into the current query the hook (set by add_action) to set the query var “page=<num_page>”, the only known identifier of the “section” known by other WP soft elements.
    (I don’t know how to do this : must be placed just at the query.php beginning ?)

    I am not sure of the sequence of actions (must be the first process : it builds the request for full compatibility giving section_name and old page number) and priorities.

    The other parts of the soft with which I have no problem at all are :
    – treatment of the content to set the pagination (or sectionning) data (shortcodes)
    – writing pagination data at saving posts.

    To test, I developed a “at display” treatment which sets
    the internal good urls (as shortcodes) into href to fragments. This makes the fragment url identifiers displayed usable (replacement into urls of the section_name by the page number at display).

    But the external links cannot be obviously kept anywhere with reliability because links to fragments are broken by any pagination change while section_names are stable data.

    I think that it is not a so important work.

    I hope this is interesting development.

    Best regards

    Trebly

    ________________________________________________________________________
    (note :For clarity the concept of an article page is replaced by article “section” (concept which covers easily : parts, main chapters, which uses are naturally extended to summary, bibliography, indexes etc.)

    The styling pages link brakes the concept of spaces for html/xml.
    A post is no more, with the pagebreak feature a space, it is the section which is, but it is managed as an entity by WP.

    The enhancement restores a HTML/XML true space as a section for post paginated : divided into sections.

    Then when you creates a document a fragment identifier “#<fragment_name>” cannot be used if a <!–nextpage–> (or equivalent) is used into the document. The URI is unknown. This is proper to the multipage concept not at all to any multipage plugin.

    I have not found anywhere information (and I worked a lot on this subject) about the way to define a fragment reference inside a multi page document a tag href or to externally reference a fragment which is contained into a multipage document.
    _______________________________________________________________________
    remark : It is very difficult to write such projects without any preview of the content of message… sorry I can edit after for a while.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    You’ve clearly put a lot of thought into this, and you are certainly addressing a legitimate issue. There are a couple WordPress related issues I’d like to point out. You questioned where to hook in order to alter how the query is processed. The ‘pre_get_posts’ action is used to set or remove individual query variables that are used in constructing the mySQL query.

    You mentioned adding a column to the posts table. This would naturally make the most sense, yet you must resist doing so. If you did, you could hamper the ability for WP to modify the table at some point in the future. While it complicates queries some, you should consider using post_meta to store post related data. WP is set up to make use of post_meta for all such data, so it’s not a big deal.

    You could also create a custom table for this, but this is usually unnecessary unless the data relationships cannot be properly represented in post_meta.

    For other questions, it’d be best if you asked a single specific question as the need arises. Most of us are better at answering short targeted questions than writing essays about a range of issues.

    I don’t wish to discourage you, but couldn’t a similar effect be had by creating a new WP page post_type for each “section”? A post post_type could work in the same manner, but I generally think of pages as more appropriate for the type of content you are concerned about. Ultimately, it doesn’t matter much, except that pages are hierarchical by default, which can be useful for this kind of content.

    I personally use multiple pages to contain different “sections” of my more complex content, in part for the exact reasons you’ve pointed out. I never use the `<!–nextpage–> feature. I’ll go to “New Page” instead. The result is a page/section sequence that is not clearly defined. I don’t see that as a problem. A defined page/section sequence is contrary to hyperlinked content. Still, there is a place for it, adding clear navigation links to content is not that big a deal.

    That’s just me. Everyone has different workflows, so I can see your application being appealing to many, just not me. I wish you all the best on your project.

    Thread Starter Trebly

    (@trebly)

    Hi,

    First of all, It is sure that I sent some targeted questions into my second post.
    There are some misunderstandings then the targeted topic remains partially and I am going to answer and so update the targeted questions.

    1- First question : rewriting url and http query
    About the first question : it doesn’t concern mySQL the query of which In am speaking about, is the http query.
    The problem is a rewrite of full http request
    As it is done currently by rewriting API an url like

    https://site_url/post_slug/num_page/#some_fragment_targeted

it is a way, because of http rewrite rule and,  to build

https://site?p=post_id&page=num_page/#some_fragment_targeted

for me the http query is ?p=post_id&page=num_page#some_fragment_targeted

    I want to write code to rewrite something like

    https://site_url/post_slug/section/section_name/#some_fragment_targeted
is a way, because of http rewrite rule and  to build
https://site/?=post_id&page=num_page&section=section_name#some_fragment_targeted

    There is just one rewrite rule modification by one add_rewrite_endpoint for the “section” concept.
    Then the add_rewrite_tag will get …/section_name/ to transform as a the query var “&section=section_name”
    The fragment will be automatically added to rewritten url at the end of the query.

    Then there is not at all several rewriting rule which would depend of any section name.

    2- Second question : post table
    You are right post_meta solves the question.

    3- Third question : the paginated post concept

    The codex explains well (but don’t insist clearly on) the reason and the mechanism of pagination of a post.
    Some content need to be red sequentially and are too long for being handles by any other way than the pagination with <!–nextpage–> or equivalent shortcodes (handled by plugings).
    When I tell about long post, I mean often more than fifty printed pages quite little books.
    The reason are multiple
    – it is the whole text which must be classified by category, own tag etc…
    – The navigation is necessarily sequential and some plugins manages this perfectly (as wp-table-of-paginated-contents that I have enhanced)

    You not well that

    A defined page/section sequence is contrary to hyperlinked content.

    it is the reason why with my enhancement the html/xml granularity becomes what I name the “section” to discontinue with the use of pages naming “pages of posts”, while the “pages” (permanent content of a site) are opposed to “post”.

    You note that

    The result is a page/section sequence that is not clearly defined.

    This is too what the enhancement changes because we find at each section beginning a shortcode which is a meta (not detailed into my mail)
    [NEW_SECTION name=”section_name” title=”the title to display]
    in this I just add the name field to the existing
    [newpage title=Section 2 : Première partie : Vue d’ensemble]
    which had become (example)

    <!--nextpage-->[NEWSECTION name="overview" title="Section 2 : First part : Overview"]'
the <!--nextpage--> remains for backward compatibility,
but the the plugin when activated with check function refuses
some lonely <!--nextpage--> displaying a warning error.
If they are only the
[NEWSECTION name="<name>" title="<title>"] it place (at saving document)
just before, for backward compatibility, <!--nextpage--> into the document.

    The reason why I can describe with so much detail is that is quite ended and is already functioning.

    What is not done is the url rewriting and post_meta which are linked.
    The [NEWSECTION… data as all “sectioning” information will be accessible into post_meta.

    You told about :

    Still, there is a place for it, adding clear navigation links to content is not that big a deal.

    When <!–nextpage–> is used lonely all fragment links cannot be maintained because the only possibility for internal link of a post (link to fragment) need to use the syntax :

    ?p=<post_id>&page=<num_page>#<fragment_identifier>
or if defined by SEO for example
/<num_page>/#<fragment_identifier>
or for external
[permalink]/<num_page>/#<fragment_identifier>

but <num_page> is unknown or changing ... most of time

    You know everything now.

    Best regards

    Trebly
    ____________________________________________________
    note : sorry if the text is not well checked and styled for readability but there is no preview and edit don’t functions always

    Moderator bcworkz

    (@bcworkz)

    Thank you for the explanation! My reasoning for being critical of your plugin was to cause you to think about alternatives and to ensure your approach was truly superior. You have now demonstrated that. You did not need to prove it to me though, you will need to convince your prospective users ?? I appreciate you taking the time to respond though, thank you.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Stable links to fragments identifiers into paginated posts enhancement’ is closed to new replies.