Forum
Republish a collection
I've just updated a template, as I've realised I need a slug field. It would be great to be able to Republish my collection, so that it updated. Similarly I've removed some fields, so Republish would remove a load of redundant data for me. Otherwise, I think I'm going to have to save each item my collection again.
I asked before about slug field uniqueness. You said that you weren't going to ensure slug uniqueness (say by adding a "1" to the end of the slug if that slug already exists). To me, that would be welcome, even if it meant adding a unique="true" in the template. I see that slugs can now be editable, which again I think is neat.
Is there a way for me to create my slug out of two fields? I guess I could create a composite field and then slug that? How about including the category in the slug field? I think that would be enough to guarantee uniqueness.
You can specify multiple IDs in the
for
attribute:I think you misunderstand the nature of republishing. The republish option recompiles the HTML output based on the stored data. This doesn't apply to collections, because they don't precompile the HTML.
Can the slug field be a category field though? Or a relationship field?
Re republishing, it does sound like I thought it did more than it does. I understood that it would recompile the HTML, but I thought it would also create any extra fields (such as slug fields) that might be in the template. Guess it doesn't, and I'll have to go through and save all my entries again. I guess in future I should make sure my templates are nailed with a few example bits of data before I enter them all?
It can't. A relationship is literally a link to another whole item of content. What would the value of that slug be?
A little bit of planning before entering large amounts of content is always a sensible idea.
That's a fair question - I guess the value of the slug would be a slugged version of the "title" of that content, but I can see that as it's relationship, the item could get changed at a later date. Also, I hadn't thought that an item could be related to more than one item or category, so maybe that's not such a good plan.
I'll bear in mind and try to plan better in future - I guess ideally I would be able to work in either order, but I can see the sense in working this way.
I'm still struggling now to see a way to guarantee slug uniqueness in a way that won't involve my client having to think about it. Any thoughts? My "projects" collection is really just a title, and some relationships to churches and some categories. I have three projects with the same name, but related to different churches. They're probably in the same category to that might not help. Any ideas? I don't want to have to manually edit the slug, or even expose it to the client. Also they wouldn't get a warning about the slug not being unique, and I'd only find out about it when something on the site links to the wrong place.
In what context should it be unique? Within the collection?
Yes, although within the site would be fine too - in this particular context it would have the same effect I imagine.
Within the entire site is actually very complex. Within a collection might be possible at some stage.
That would be great, Drew. Appreciate your help. Perch is working brilliantly for us and with a few tweaks it will be perfect.
I've been looking at this today - I've written a new fieldtype based on the Perch native "slug" but it checks for the uniqueness of the slug... it's called brd_slug. Here it is:
In the template, you need to specify the collection
(I could get the collection from the URL, but this way it only triggers the unique slug functionality when I really want it to - otherwise it just works like regular slug).
Any thoughts/comments/suggestions on this? (It's my first time writing code to query the Perch database, so it can probably be improved, but it does seem to be working reliably here to give a unique slug by adding a number to the end if the slug has already been used).
I'd be a bit worried as to how that might scale. It could be better to inspect the index, which is designed for these sorts of things.
Ah, thanks, Drew. I hadn't noticed that the slug is already in the index, so that avoids me having to mess with any JSON etc. I'll rework accordingly.
Here's my latest version using the index. No warranty, but it seems to be working.