More permissive slug generation?

[mar...@martinmalmsten.net]

Hello,

we are currently implementing AtoM (2.4) at the National Library of Sweden, so far it is going well :)

I have three question (or rather a suggestion and two questions) though:

- A more permissive slug generation would allow for (some? most?) reference codes to be part of the URL without transformation, which would be very nice at least to us. For example https://atom-host/KB:HS:123:456 would be a perfectly good URI that would lend itself to Linked Data. Do you see any problems with a setting that would allow for an wider range of characters?

- We are currently experiencing a problem where the slug generation setting seem to be ignored, it falls back to using the title. Has someone else had the same problem (on RHEL).

- Is the index.php supposed to be present in the URL? I can use rules in nginx to remove it, but it does not work 100%.

Best regards,

  Martin Malmsten

  National Library of Sweden

[mar...@martinmalmsten.net]

Forget the question about index.php. We found the answer on the list :)

/martin

[mar...@martinmalmsten.net]

And the slug problem only happens when language is Swedish, not English.

/martin

[mar...@martinmalmsten.net]

And with the risk of spamming you all, this also happens when using the 2.4.x Docker-installation. So I guess that it is an actual bug.

/martin

[Dan Gillean]

Hi Martin, 

Thanks for your question. 

In AtoM 2.4 there is an option to use the Reference code as the basis for slug generation, but you are correct in noting that it's currently pretty restrictive - at the moment, slugs in AtoM will only allow lowercase alphabetic characters, digits, and dashes. Anything else (such as spaces, special characters, etc) is converted to lowercase or dash, or stripped from the resulting slug. 

I will have to ask my team as to whether they anticipate any issues with changing these restrictions to allow a) capitalization and b) other characters. 

One consequence of allowing capitalization might be that you'd end up having more near-identical URLs - for instances, the following could all lead to different pages (but be easily mixed up by users): 

• example.com/test
• example.com/Test
• example.com/TEST
• example.com/TesT
• etc

This isn't necessarily a problem, but it might be undesirable to some users. Because of this, I think if we did change the restrictiveness of slug generation, then adding a configurable setting (so users have some control over the feature) would probably be the way to go. 

Adding such an enhancement would probably require community support for us to be able to take on. Note that I've made a long post recently in response to some questions as to how we handle feature-based pull requests here: 

• https://groups.google.com/d/msg/ica-atom-users/aHY_tT4kz9c/iMhRCYJhBAAJ
  

As to the issue with slug generation you've encountered: 

• Is the default installation culture of your site Swedish?
• Are the descriptions created in the Swedish interface as well?
• Do the descriptions in question have translations (e.g. English, etc)?
• Are your descriptions generally created via the user interface, or imported somehow (or is it a mix of both)?

I'm wondering if this is potentially a culture fallback issue - if for example, the feature is looking for the reference code/identifiers in the English i18n settings, and when it doesn't find them, is falling back to the title. One way we could test this theory is to try flipping the user interface to English, and adding data there, and seeing if the slug task behaves the same or not. 

I will try to reproduce this issue locally. Thanks for the report. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/34ddf37e-51ef-40bc-8ca4-9567e9472fed%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[mar...@martinmalmsten.net]

Hi Dan,

and thank you for your prompt reply!

You are right in that allowing a wider range of characters would have side-effects, especially in combination with slug-generation from title-fields. It should probably only be used on identifiers/reference codes. That being said, when no identifier exists, title could be used for *that* level when creating the slug, e.g https://example.org/KB-HS-L230:1:2:3:Letters (where KB-HS is the institution and the rest the reference code). Ideally one could use a format string in the settings. We will talk amongst ourselves to work out how important this is and get back to you with a pull request or a request for a quote.

Regarding the issue with slug generation from reference codes:

1) not sure
2) yes
3) no
4) a mix

I tried it with a clean install using Docker on the 2.4.x branch, and it reverts back (the behaviour, not the setting) to using title when changing language to, at least, Portugese.

Best regards,

  Martin

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

[Dan Gillean]

Hi Martin, 

Thanks for your notes on your local testing - I've managed to reproduce this in my local Vagrant test instance as well. I've filed a bug report with 2 detailed use cases where I encountered this issue here: 

• https://projects.artefactual.com/issues/11554
  

It seems like overall, the slug settings are not being respected in other cultures - whether in the default installation culture settings or just in the user interface. Since reference code is not actually a translated field, the culture shouldn't matter when using identifier or reference code as the basis for slug generation. 

To my thinking, it seems like the culture of the original language a description is created in should be used when the setting is Title - regardless of installation culture. So if you have installed using English as the default culture, but you flip the interface to Swedish to create a new description, then even if you add an English title, the slug (when set to use title) should be derived from the original description source - the one created in Swedish - and not the translation (just because it happens to match the installation culture), even if you run the slug regeneration task. Would you agree?

In any case, I've added this ticket to a list of bugs for us to track and hopefully fix in the next release. If your institution would like to sponsor this bug so it can be addressed immediately and a patch provided in advance of the next release, please feel free to contact me off-list. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/2c4396da-8e16-43d7-8763-08f7a50e788e%40googlegroups.com.