Ah, yes, that makes sense. To take in @espenmn's comment, let's rewrite the proposal to include automation and reuse or extend the TOC setting to allow hiding the TOC and to create anchors that take the heading text and normalize it (lowercase, replace non-alphanumerics with "-", for example). That would make it clearer.
Great idea, @stevepiercy. Can you write that up in a way that makes sense? Is the scope of this large enough to warrant a three-month timeline? Are there other improvements to editing/managing content that we could imagine bundling with this? Are there other ways we could leverage this change to power other functionality to help extend the scope of the project if it is indeed too simple for a three-month project?
Here's my rewrite:
Every heading in a document content type should be an anchor that is automatically generated through Plone. We do not mean manually using TinyMCE or its plugins to place anchors.
We can reuse or extend the table of contents (TOC) setting to:
- allow hiding the TOC
- create anchors from the heading text and normalize it (lowercase, replace non-alphanumerics with “-”, and trim, for example). In other words,
#1 Heading With A TLA (three-letter acronym) and doubled--dashwould become
1-heading-with-a-tla-three-letter-acronym-and-doubled-dash, ensuring they are unique to the page.
Additionally adjust the
idpositioning when the editing bar is positioned across the top (it is positioned to the left by default, but some sites position it across the top) so that there is sufficient clearance and the heading is revealed.
Tests and documentation are required as well.
I don't have answers for the other questions, except that this task would take no more than 1 month and maybe only 1 week, given that this would be an extension of existing code. I expect most of the time is the usual overhead from on-boarding. It would be good to bundle it with other tasks. It could be a good item to get started and have a sense of accomplishment.
Not so sure about that.
As far as I know, all the anchors needs to be unique (ids), so there is a possibility that titles are reused (especially for second level titles), then we end up with two similar ids.
We could 'check for this', but maybe it is better to include a unique 'number'
Maybe having too long ids (and urls to share) is not perfect, maybe just the first xx characters?
where x could be 'count of anchors', but this would also mean that if you share a link and add another heading, the link is not working anymore.
If that is a problem, we probably have to check somehow
… while we are at this subject, I made a 'floating menu' if that should be of interest to anyone (was in fact a bit tricky)… scroll down see it:
I added "ensuring they are unique to the page". How it's done is for the GSoC student to figure out.
A logical extension would be to add to TinyMCE's UI a way to choose an anchor link from another page to link to. Perhaps when an internal page is selected the Anchor tab could show the anchors on that page, or there could be another tab.
Also maybe it is just me, but I think the OOTB design of the TOC looks a bit dated. (Perhaps because it's old fashioned to have a page that is so content rich that it needs anchors...) I assume it is Diazo friendly, but could this project include getting UI and UX designers' suggestions for improvement, and implementing?
Can you share more details about the scope of this project ? Or do I share a draft proposal based on the ideas page and this discussion ?
I introduced myself here:
We had such a functionality in TinyMCE already in 2011:
A key requirement is that anchors once generated must be stable - otherwise links may become unstable. Auto-generated anchor names should be unique IDs and not based on the heading text. Headings change and become inconsistent with an existing auto-generated anchor name. That's why UIDs are better.
So you want:
- auto-generated UIDs instead of content-derived IDs
- auto-generated UIDs for headings, tables and images and related objects.
- in some contexts it makes sense to add auto-generated IDs to block elements like paragraphs
yeah I don't get this idea given we already have it.
however one related concept I'd like to see implimented is more redundant uid links. Currently they break easily for example if you do exports or content gets moved in odd ways. This can be improved by using relative paths AND uids, e.g.
But thats not enough for a GSOC.
What else could be added ? General Testing, Documentation, bug fixes for the whole project ?
Is this not gonna work out ?
Agreed, the overall task is poor and not enough for a GSOC project.
Sorry for having disrupted a discussion again.
You do not want such a plugin since the manual step is superfluous if you auto-generate anchors.
Manual anchor generation is a no-go.
My name is Vivek. I'm studying Computer Science and Engineering at Model Engineering College, Kerala, India.
This is my first GSOC project. Plone seems very interesting to me and I would like to join in the development of the Automatic anchors idea. I really like the idea of automatically generating anchors for headings. Also the positioning of the editing bar needs to be adjusted, which improves the user experience.
I look forward to contributing to this project and learn a lot in the process.
Have a nice day
Given that the deadline for student applications was about 24 hours away when you wrote your message, I'm guessing that it is likely too late to write a substantive proposal for this year. If I'm wrong, and you get one done, that's terrific.
If i'm not wrong, and you are interested in participating, then take a look at the original post for students interested in GSoC and you'll find some steps at the top that can get you started on the right foot for next year. Plone is great for building websites for schools and student organizations, so you can play with our product for a while, get to know what we do best, and what we need, and be in a position to write an amazing proposal for next year.
We hope to see you around!
I hope organisation doesn't dropout on idea of giving students project on this idea, cause I have been working on it for a while, I also had introduced myself to the community in this forum- students interested on GSoC and also specified that I wanted to work on this particular topic. Lately seeing this thread, I am realising not many are impressed to have this idea as a 'GSoC project'. But I think there is more to it.
As specified by @zopyx anchors can be generated by unique IDs rather than headings, but we can also follow approach given in original Idea list provided on Plone's site itself (see suffixing the anchors with number in case of duplication).
Positioning of editing bar is one straight forward concern. If it may seem, this work wont require that much time, I shall be more than happy to take inputs from community and try more creative stuff to enhance user interface, which I have also specified in my proposal that I shall be submitting soon, of course before the deadline.
That is why I chose to work on project called 'Editor Improvement' and not 'Auto-generating anchors for heading and fixing the editing bar position'.
I hope my efforts dont go in vain.
Just submitted my GSoC proposal on this 'Editor Improvements' Idea. This discussions indeed helped me. Thanks for all the support provided by Community. Hope it goes well.
@cekk hope while evaluation of proposal they dont mark an error for mentioning you as mentor for the project in my proposal.
@cekk, Must have been a mis-translation from some other project. I remember you being involved in one of them. Apologies. And no worries, that list is not by any means final, but only a list of possible community members. I swear I won't sign you up without asking.
@Maitreya, do not worry, that's not the kind of thing we grade on when choosing proposals to accept.