There are many instances where having an alphabetical pager (A, B, C) makes more sense than a numeric one (1, 2, 3).. for example, when browsing users or terms.

There are a couple places in contrib where modules have had to implement their own alpha pager. It would be nice if core offered this natively.

Issue fork drupal-68882

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

    About issue forks

    Comments

    bitman’s picture

    bitman commented
    Version: x.y.z » 6.x-dev

    The Views Alpha Pager module is worth noting here.

    pasqualle’s picture

    pasqualle
    Location 🇭🇺 Budapest
    commented
    Version: 6.x-dev » 7.x-dev
    dugh’s picture

    dugh commented

    no drupal 6 version of that module

    wulff’s picture

    wulff commented
    Version: 7.x-dev » 8.x-dev

    Having an alphabetic pager in core sounds like a great idea.

    jhedstrom’s picture

    jhedstrom
    Primary language English
    Location Portland, OR
    commented
    Version: 8.0.x-dev » 8.1.x-dev
    Issue summary: View changes

    This might be possible with Views as-is, but I'm not certain.

    Version: 8.1.x-dev » 8.2.x-dev

    Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.2.x-dev » 8.3.x-dev

    Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.3.x-dev » 8.4.x-dev

    Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.4.x-dev » 8.5.x-dev

    Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.5.x-dev » 8.6.x-dev

    Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.6.x-dev » 8.7.x-dev

    Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    matsbla’s picture

    matsbla commented

    Here is also another contrib project #2821493: [alpha_pagination] D8 Port

    Version: 8.7.x-dev » 8.8.x-dev

    Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    Version: 8.8.x-dev » 8.9.x-dev

    Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

    Version: 8.9.x-dev » 9.1.x-dev

    Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

    Version: 9.1.x-dev » 9.2.x-dev

    Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

    Version: 9.2.x-dev » 9.3.x-dev

    Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.3.x-dev » 9.4.x-dev

    Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.4.x-dev » 9.5.x-dev

    Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 9.5.x-dev » 10.1.x-dev

    Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    Version: 10.1.x-dev » 11.x-dev

    Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

    johnv’s picture

    johnv
    Primary language Dutch
    commented
    Component: base system » views.module
    johnv’s picture

    johnv
    Primary language Dutch
    commented

    IIRC the Book module has an alphabetically sorted pager.
    Or else the Glossary

    At least, IN D7, you could create a telephone book with names, and an alphabetical pager.
    Let's re-find the contrib / deprecated core pager.
    See Search on Drupal Answers… New Stack Overflow Jobs mogelijk gemaakt door Indeed: techbanen binnen handbereik (Nu beschikbaar in Nederland) Zoek vacatures Drupal Answers Home Questions Tags Users Jobs New Companies Unanswered Teams Ask questions, find answers and collaborate at work with Stack Overflow for Teams.
    Or just enable/copy/override the core 'Glossary' view (by default disabled) , enabling the '/glossary' page as an example.

    johnv’s picture

    johnv
    Primary language Dutch
    commented
    Title: Add an alphabetical pager to core » Add an alphabetical (glossary) pager to core

    Version: 11.x-dev » main

    Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

    Read more in the announcement.

    byski’s picture

    byski commented

    Looking at this from a fresh angle on Drupal 12 (main branch)

    The query-layer groundwork for this already exists in core. StringArgument has a glossary option that runs SUBSTRING(field, 1, N)
    to group results by first character, and the DefaultSummary style renders those as letter links. The demo Glossary view
    (/glossary) uses exactly this today.

    The actual gap is in the rendering layer, not the query layer:

    - The summary only lists letters that have matching content. A full A-Z bar never renders.
    - Empty letters have no disabled/inactive state. They simply vanish.
    - It is a drill-down pattern (all letters first, then click to see items), not a persistent navigation bar that stays visible
    above/below the result list with the active letter highlighted.
    - There is no reusable element you can attach to a users view or taxonomy terms view without adopting the summary pattern
    wholesale.

    Proposed approach: a new summary style plugin

    Rather than a new @ViewsPager plugin (pagers are offset-based; "page = letter" is really a filter, so that layer is wrong), I
    would add:

    1. A new summary style plugin, e.g. AlphabeticalSummary, that takes the letters-with-content from the existing glossary query and
    merges them against a configurable full character set (A-Z, 0-9, a catch-all "other"), marking each letter as present, empty, or
    active.
    2. A Twig template for the rendered bar.
    3. A small CSS library for the active/disabled states.
    4. Config schema for the style options (which character sets to include, whether to show or hide empty letters).
    5. Update the shipped Glossary view to use the new style as the in-core demonstration.
    6. Functional tests asserting the full alphabet renders, empties are marked correctly, the active letter is highlighted, and the
    links filter content as expected.

    This approach leaves StringArgument and the query path untouched. It lives entirely in the rendering layer, which means it is safe
    to add without touching anything that already works.

    Prior art worth noting: Views Alpha Pager (D6 era, comment #1 above) and the alpha_pagination D8 port (#2821493) both took a
    similar rendering-layer approach in contrib.

    Question for maintainers before I start building: Is the summary style layer the right place for this, or is there a preferred
    architectural direction on main? Happy to attach a working proof-of-concept to this comment if that would help the review.