Prevent apostrophe-workflow from adding a digit to the slug of every page when it goes live

[juliageek]

I have an ApostropheCMS project that uses apostrophe-workflow. I now started committing my website pages so the users who are not admin can see them on the website. As I was doing so, I noticed that apostrophe-workflow appends a digit to all the slugs for the live version. So for example, if the page slug is /parks, in the live version, it's /parks2 and so on.

I'd want to prevent this from happening, because I have a navigation on the website and now I get a 404 Not found for every page because each page has a digit appended to its slug.

I read about the issues that other devs had regarding parked pages, but I don't have this flag active in my configuration, so I think the problem comes from somewhere else.

[abea]

@juliageek Are you using the latest version of Apostrophe and Apostrophe Workflow? I seem to recall something like this being resolved at some point. I'm not able to reproduce the bug myself. Maybe if you can share any relevant configuration that may help.

[abea]

I'm not sure I understand the part about workflow versions since 2.38.2 is more recent than 2.9.1. But those versions should allow the latest versions to install. Your package-lock.json file may have you pinned at an earlier version, though. All that is to say that the first thing I would try (locally, not in production) would be to npm update apostrophe && npm update apostrophe-workflow to get on the latest versions and confirm that it doesn't help.

We try to avoid any backwards compatibility breaks within a major version, so there should not be any problems with upgrading and you could get some bug fixes you're missing.

[juliageek]

@abea Yes, you are right, 2.38 is way greater than 2.9. I ran the commands you recommended npm update apostrophe && npm update apostrophe-workflow. Now I have version ^2.116.1 for apostrophe and version ^2.38.3 for apostrophe-workflow. Now, when I navigated to the draft version of one of the pages, it asked me to commit it (although to my knowledge, my page didn't change in the meantime). I committed it. Before, the slug was /antiquity6, now it became /antiquity2. So I'm not sure if that digit is supposed to be some sort of version, because I expected it to increase, not decrease 😓

[juliageek]

What bugs me is that I would want to change the slug, to make it the same between the draft and the live version, but I cannot, because changing is disabled (see printscreens below).

[juliageek]

Ok, so I noticed something interesting (that may be related to the bug mentioned in the issue I linked above). So, I have 6 blogs on the page, each blog with its own articles. Now, when I looked at the Manage Pages modal, I could see something interesting:

• in the general Trash section, there were 7 pages, and I tried to Batch Trash them, and even if there were no errors, the pages cannot be deleted (every time I open the modal, the 7 pages in trash are still there).
• one single blog page has its own Trash section, and that's the only page that doesn't append a digit after the slug, so I have the same slug in draft as in live.

I compared the index.js files and the way I add the 2 types of pages in app.js and I couldn't notice anything different between them, so I'm not sure why that one page has a separate trash section.

[abea]

The multiple trash sections is intentional, though confusing (I think we're ditching it in 3.x). The nested trash section is to maintain page tree structure in case things are brought back out.

As a test, I might suggest you test out a fresh local database with the updated packages. You could change the shortname in your project to get a new db or simply use node app @apostrophecms/db:reset && node app @apostrophecms/user:add admin admin to clear it and create a new admin user if you can sync the prod data down after. I would expect that the draft/live number additions won't happen again, but if they do then it could lead to something more systemic. If not, then the updated versions might be what's needed, along with some data cleanup.

[juliageek]

The problem was solved by resetting the database as suggested by @abea. Once apostrophe-workflow and apostrophe were update and the workflow documents were re-created, the problem solved by itself. Hence, I will close the issue now.

[abea]

Nice! Yeah, once the database is messy it can be tough to let the new code do the work. We don't do enough to talk about how to clean up code with migrations. https://docs.apostrophecms.org/advanced-topics/migrations.html

[boutell]

Glad that worked out, sorry for the hassle!

…

On Mon, Mar 15, 2021 at 10:22 AM juli4g33k ***@***.***> wrote: The problem was solved by resetting the database as suggested by @abea <https://github.com/abea>. Once apostrophe-workflow and apostrophe were update and the workflow documents were re-created, the problem solved by itself. Hence, I will close the issue now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2806 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAH27MUHV3YAAV3AIZ4PNDTDYJZVANCNFSM4Y6MU6LA> .

-- THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER APOSTROPHECMS | apostrophecms.com | he/him/his