Bug report

Describe the bug

The alias is not always saved with existing elements (I use strapi 4.6.0)

Steps to reproduce the behavior

Configure plugin for an existing collection, for exemple with: /[Title]
Edit content on an existing element of the collection.
Let the url generation on autogenerated
An url is generated (visible in the alises list) but using API the element is not found.
Return on the element, the input where the alias should be visible is empty.
Make change (but not in the title) and save.
A new alias is generated (title-0) but still not accessible via API (not found error)

When I fetch all elements of the collection the property url_path_id is null

When creating a new element the alias is saved correctly and accessible via url

Expected behavior

The element should always be accessible using its url

Bug report

Describe the bug

Hello,

when some relations in database is broken, it's trigger an error:

[2022-09-13 11:50:45.360] error: Cannot read property 'url_path' of null
TypeError: Cannot read property 'url_path' of null
    at /srv/app/node_modules/@strapi-community/strapi-plugin-url-alias/server/content-api/services/prepare-path.js:27:41
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async Promise.all (index 5)
    at async traverse (/srv/app/node_modules/@strapi-community/strapi-plugin-url-alias/server/content-api/services/prepare-path.js:18:5)
    at async /srv/app/node_modules/@strapi-community/strapi-plugin-url-alias/server/content-api/services/prepare-path.js:20:9
    at async Promise.all (index 12)
    at async Object.traverse [as preparePath] (/srv/app/node_modules/@strapi-community/strapi-plugin-url-alias/server/content-api/services/prepare-path.js:18:5)
    at async Object.response (/srv/app/node_modules/@strapi-community/strapi-plugin-url-alias/server/content-api/services/prepare-path.js:38:12)
    at async Object.findOne (/srv/app/node_modules/@strapi-community/strapi-plugin-url-alias/server/admin-api/services/override-query-layer.js:18:24)
    at async Object.findOneWithCreatorRoles (/srv/app/node_modules/@strapi/plugin-content-manager/server/services/entity-manager.js:160:20)

Steps to reproduce the behavior

1. Broke any relation to url_path

Expected behavior

No exception, or foreign keys in database

Feature request

Summary

It should be possible to use the url_path field as a target field in other plugins such as sitemap and preview button.
Currently the entities that use url-alias, can only use url_path_id as their target field.

Why is it needed?

If you use url-alias to set urls for your routes, it should also be possible to use it with other plugins such as sitemap and preview button.

Suggested solution(s)

I'm not really sure how the internals work, but a solution would be to have url_path added as a field when the entity is fetched/queried.

Bug report

Describe the bug

Nice plugin! I'm currently trying to work around Strapi's limitation of not being able to have a UID field that checks for uniqueness only across entries with the same locale. At the same time I need a way of fetching an entry by its slug. So this plugin looks very promising. :)

I've run into a bit of an issue however, where I have a URL pattern configured to contain the entry locale, but it's not consistently stored there.

Steps to reproduce the behavior

1. Create a URL pattern with the entry locale in it, e.g. /products/[locale]/[title].
2. Create an entry in the default locale (de-DE in my case), save and publish it. The locale is correctly stored in the URL alias.
3. Change the entry and save again. The locale disappears from the URL alias. (I checked the database, it's really gone.)
4. Unpublish the entry. The locale is again stored to the URL alias.
5. Repeat step 3. The locale is gone again.
6. Publish the entry. The locale is there again.

Expected behavior

The locale parameter should stay in the URL regardless of the entry's state changes.

System

• Node.js version: 16.16.0 LTS
• NPM version: 8.11.0
• Strapi version: 4.3.2
• Plugin version: 1.0.0-alpha.4
• Database: SQLite
• Operating system: macOS Monterey v12.2

Bug report

Describe the bug

In an out-of-the-box installation of Strapi 4.3.2 and a clean install of the URL alias plugin, using the provided endpoint <API-URL>/url-alias/get?path=/custom/path returns a HTTP 403 error:

{
  "data": null,
  "error": {
    "status": 403,
    "name": "ForbiddenError",
    "message": "Forbidden",
    "details": {}
  }
}

I'm not sure if this should be considered a bug, feature request or just a documentation issue, so feel free to move this issue.

Steps to reproduce the behavior

1. Install Strapi and the URL alias plugin:

yarn create strapi-app my-project --typescript --quickstart && cd my-project
yarn add @strapi-community/strapi-plugin-url-alias

2. Set up a collection type
3. Set up a URL alias pattern and an entry using that pattern
4. Save the entry
5. Try to fetch the entry via URL alias plugin at its custom path: <API-URL>/url-alias/get?path=/custom/path
6. See error 403

Expected behavior

The actual entity should be returned.

Code snippets

I ran into the same issue when creating custom routes of my own, and as far as I've been able to research, it seems to have something to do with the API being protected by default. Generating a "read" API token makes the auto-generated routes return content, but it is not sufficient to make the routes of the URL alias plugin work.

What helped for my custom routes was to add an auth section to the routes config like so:

config: {
  policies: [],
  auth: {
    scope: ["find"],
  },
}

I can't do that for the plugin of course, and since this does not seem to be documented by Strapi, I don't know if this is really the correct way of handling it.

System

• Node.js version: 16.16.0 LTS
• NPM version: 8.11.0
• Strapi version: 4.3.2
• Plugin version: 1.0.0-alpha.4
• Database: SQLite
• Operating system: macOS Monterey v12.2

Bug report

Describe the bug

Having [locale] in a pattern is no longer getting resolved. If I have a pattern /[locale]/[title] and saving an entry with title x, then the generated url alias will be /[locale]/x

Steps to reproduce the behavior

1. Create a pattern with [locale} in it
2. Create an entry with it
3. See that the locale has not been resolved

Expected behavior

I expected that the locale would be resolved as, so if the entry has a locale of en I would expect the url apth to be /en/x

Feature request

Summary

I think the url_path field needs a database index, such that finding a url alias by it's path will be faster.

Suggested solution(s)

Take a look at the strapi repo code (or here) for an example.

Feature request

I would like the ability to use populate with the rest API

Summary

At the moment, relations, media fields and components which need the populate parameter to show are not available via the REST API. This restricts the scenarios in which the plugin can be used. The ability to use the populate parameter will ensure that the using the URL Alias Endpoint will allow you to get all the content associated with that page/collection.

Feature request

Summary

RN when you have allready created records in Strapi for your website pages before installing this plugin you will have to manually save them one-by-one for the URL paths to be correctly generated.

Why is it needed?

Because it is a pain to manually save all the records.

Suggested solution(s)

I want to have a way for you to bulk generate the URL paths. This must be an asynchonous method that runs in the background as it could take a while for it to complete when you have a website with say 100k+ pages.

My suggestion would be to solve this by queueing. When a bulk generation is requested we will create a new queue and add jobs to it which will run portions of the task. When we've added the queue and started processing it we can let the user know that the process has started. We can track the progress of the queue and present that to the user so that he knows that something is happening.

Related issue(s)/PR(s)

As of writing this issue I've setup a queueing system in this PR. With this queueing system we can implement the solution I suggested above.

Feature request

Summary

I'd love to be able to remove the ability to edit the path for some administrators the same way I can prevent them to edit patterns.
In the case of an entry creation, the plugin would tehn remain on automatic generation

Why is it needed?

You might want to have some pages that you need the path to stay intact, like the home page, and this could prevent some administrators to break the frontend

Suggested solution(s)

A new option here would be perfect :)

Bug report

Describe the bug

When I try to publish a content type that has draft and publish enabled and webtools, I am now unable to publish it. I get an error saying that the url_path field must be unique

Steps to reproduce the behavior

1. Create a content type with webtools and draft and publish enabled
2. create a pattern for it
3. Create an entry and save it (this should work)
4. try to publish it and see an error.

Expected behavior

I expected that the entry would be published as normal

System

• Node.js version: 18.18.2
• NPM version: 9.8.1
• Strapi version: 4.19.0
• Plugin version: 1.0.0-beta.5
• Database: sqlite
• Operating system: Linux

Additional context

This might have something to do with the content releases that strapi added in this version

https://github.com/strapi/strapi/releases/tag/v4.19.0

Feature request

Summary

If I change the url of one of my pages, no information is stored about where the old url. I would like to be able to know if a url has been moved when querying a url alias.

example:
I have a page /my-page I change the url to /my-awesome-page.
Then when i query /api/url-alias/get?path=/my-page I would like to get some information back that the page has been moved to /my-awesome-page.

I would also like an interface where I can set these redirects up.

Why is it needed?

It is important for search engines and the web in general that you can make 301 or 302 redirects, and currently this is not possible with url-alias.

Let's say another page linked to /my-page, they would be met with a 404, but I really would like them to be redirected to /my-awesome-page.

The page that shows the redirects is needed to set up custom redirects, this is needed when switching from some other site to a new and you should populate the initial redirects.

Suggested solution(s)

Whenever the url alias of a content type changes, the user should be asked if they want to save the redirect. If they choose to, then the redirect would be stored in the database still pointing to the same entity.

If a new entity with the old url is created, it should overwrite the old redirect

A request to /api/url-alias/get?path=/my-page could probably return something like this:

{
  "data": {
    "type": "redirect",
    "reditrect_url": "/my-awesome-page",
    "contentType": "api::page.page"
  },
  "meta": {}
}

Bug report

Describe the bug

When removing items in content manager, the url alias link in wt_url_alias should also be removed.

Steps to reproduce the behavior

1. Create page with url alias generated to it.
2. Remove page. URL alias stills remains in wt_url_alias table

Expected behavior

URL alias is being removed from wt_url_alias table

Bug report

Describe the bug

When trying to delete a locale I am just met with a generic strapi error in the interface. In the console I am getting a more detailed error:

[2023-02-08 14:29:42.995] error: Cannot read properties of undefined (reading '0')
TypeError: Cannot read properties of undefined (reading '0')
    at Object.beforeDeleteMany (/home/.../node_modules/@strapi-community/strapi-plugin-url-alias/server/admin-api/services/lifecycle.js:125:47)

Steps to reproduce the behavior

1. Create a new locale by going to Settings -> Internationalization -> + Create new locale
2. click on the delete button next to it and confirm
3. You will be met with a similar error

Expected behavior

The locale would be deleted

System

• Node.js version:
• NPM version: 9
• Strapi version: 4.6.0
• Plugin version: 1.0.0-alpha.6
• Database: sqlite
• Operating system: NixOS (Linux)

New Strapi project (4.15.5)
Then install plugin
yarn build

Error: Could not load js config file
/path/test-plugin/node_modules/@strapi-community/strapi-plugin-url-alias/strapi-server.js: Package subpath
'./dist/core-api/controller/transform' is not defined by "exports" in
/path/test-plugin/node_modules/@strapi/strapi/package.json

I'm a bit fresh with this but is it the way that it's being imported? I've copied this into /plugins folder and changed to -

// import { transformResponse } from '@strapi/strapi/dist/core-api/controller/transform';
const { transformResponse } = require('@strapi/strapi');

It builds and I can run yarn develop though I haven't tested the api path yet.

Feature request

Summary

Currently you have to create a pattern in the database to use a pattern. This means that you have to set up the patterns locally and in production unless you use other tools such as config sync. I think it would give a better developer experience to have a fallback pattern field which can be configured directly on the pluginOptions preferably next to the enable option in the interface.

I also think it should be possible to disable the custom patterns, such that the fallback pattern is the only one being used and cannot be changed by users who don't know what they are doing.

Related issue(s)/PR(s)

This might resolve the problem in #54

Bug report

Describe the bug

In some cases, when you create a new entry of an existing entry with a new locale, it may copy over the url path id, which could cause multiple errors down the line. One such case is #21

Steps to reproduce the behavior

1. Enable localization in strapi
2. Create an entry of a localized content type that either has no pattern or you do not fill the fields from the pattern
3. Create a localized entry
4. Click 'Fill in from another locale' and select the one you just created
5. Click save without filling any fields from the pattern
6. See that the url path is identical between the two entries

Expected behavior

I would expect url alias to create a new entry without the url_path_id being copied over.

System

• Node.js version: 18
• NPM version: 9
• Strapi version: 4.10.8
• Plugin version: 1.0.0-alpha.6
• Database: sqlite and postgres
• Operating system: NixOS

Additional context

Related to #21

Feature request

Summary

It should be possible to use this plugin with the sitemap plugin to generate a sitemap.
This is also currently possible by setting allowed fields to also accept strings in the sitemap plugin. Then choosing to generate a sitemap from UrlAliasPath and using the [url_path] field.

However it should be possible to generate it from a specific content type such as a page content type. Currently there is only an accessible field for url_path_id which we cannot use to generate a sitemap.

Suggested solution(s)

I am not sure how this should be implemented

Related issue(s)/PR(s)

#9

Bug report

Describe the bug

In some cases there might exist paths with no valid entry, which means the url path is in the database, but there is no associated entry.

This can happen if a content type has enabled url alias and have some entries with paths and then it gets disabled.

Steps to reproduce the behavior

1. Create new content type with url alias enabled
2. Create an entry for that content type with a url path of /home
3. disable url alias from the content type
4. create a new entry of a content type that has enabled url alias and give it a url path of /home
5. observe that the url path will be saved as /home-0

Expected behavior

I think I would expect url alias to clean the old paths up by itself, although this might be a large task with the current setup if done during bootstrap and the instance has a lot of entries.

I think a way to fix this is to provide the user with a button which would clean up the old paths. However this doesn't really seem satisfiable either.

Bug report

Describe the bug

After updating the plugin to version 1.0.0-alpha.5, I get an error when I try to access http://localhost:1337/api/url-alias/get?path=trust-numbers, the api returns an internal server error:

{"data":null,"error":{"status":500,"name":"InternalServerError","message":"Internal Server Error"}}

And in the development console I also get an error:

[2022-08-29 15:38:47.157] error: Forbidden access
ForbiddenError: Forbidden access
    at Object.verify (/home/alexander/source/oak-site/backend/node_modules/@strapi/plugin-users-permissions/server/strategies/users-permissions.js:94:11)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async /home/alexander/source/oak-site/backend/node_modules/@strapi/strapi/lib/services/server/compose-endpoint.js:31:5
    at async serve (/home/alexander/source/oak-site/backend/node_modules/koa-static/index.js:59:5)
    at async returnBodyMiddleware (/home/alexander/source/oak-site/backend/node_modules/@strapi/strapi/lib/services/server/compose-endpoint.js:52:18)
    at async policiesMiddleware (/home/alexander/source/oak-site/backend/node_modules/@strapi/strapi/lib/services/server/policy.js:24:5)
    at async /home/alexander/source/oak-site/backend/node_modules/@strapi/strapi/lib/middlewares/body.js:51:9
    at async /home/alexander/source/oak-site/backend/node_modules/@strapi/strapi/lib/middlewares/logger.js:22:5
    at async /home/alexander/source/oak-site/backend/node_modules/@strapi/strapi/lib/middlewares/powered-by.js:16:5
    at async cors (/home/alexander/source/oak-site/backend/node_modules/@koa/cors/index.js:56:32)

Steps to reproduce the behavior

1. Use a pre-1.0.0-alpha.5 version of this plugin (Not sure if this step is needed)
2. Create a page content type with a title field
3. Make a url-alias pattern on the page content type, label it slug and make the pattern /[title]
4. Create a page and set a url with url alias
5. Access the api /api/url-alias/get?path=[path] where path is the url you just set.
6. See the same error.

Expected behavior

Not make an internal server error

System

• Node.js version: v16.16.0
• NPM version: 8.18.0
• Strapi version:4.3.2
• Plugin version: 1.0.0-alpha.5
• Database: sqlite
• Operating system: Linux - NixOS 22.05 (Quokka) x86_64

Bug report

Describe the bug

When using strapi import / export function to reinstall a strapi instance on another server, the pattern and list is correctly migrated, but every path is actually duplicated to another -0one. the /about path is visible on the list, but on the database, we have /about-0

Steps to reproduce the behavior

1. export a strapi backup with strapi export --file backup
2. Import in another database / another server with strapi import backup.tar.gz

Expected behavior

Path association should remain intact

System

• Node.js version: v18.17.0
• NPM version: v9
• Strapi version: Tested on v4.12.7
• Plugin version: beta.10
• Database: mysql
• Operating system: Linux / MacOS

Additional context

Might be related to #51 and/or to #43

Bug report

Describe the bug

A clear and concise description of what the bug is.

Steps to reproduce the behavior

1. Go to "Content Manager"
2. Tick the checkbox at the top left of the page list
3. Click the "Delete" button
4. Go to settings -> URL alias -> list
5. Aliases remain

This only happens if you use the "delete" button at the top. The bin icon on the right hand side of the listing works ok, as well as deleting from within the page itself.

Expected behavior

Expected behaviour is URL aliases should be removed when pages are deleted.

Screenshots

System

• Node.js version: 16.16.0 LTS
• NPM version: 8.11.0
• Strapi version: 4.2.2
• Plugin version: 1.0.0-alpha.2
• Database: sqlite
• Operating system: Alpine Linux

Feature request

Summary

Inject the path for which the data could be accesible when calling the default strapi API (find, or findOne)

Why is it needed?

Sometimes, you still need to load some data the old fashioned way, for a search engine for instance. When getting the result, you may want to navigate your frontend toward their url-alias.

Right now, we only retrieve the url_path_id, but we have no findOne action on the path content-type.

Suggested solution(s)

The technical solution may differ according to the potential data structure.

• Keeping the current datastructure but enforcing a relationship, this should work by default with populate options
• Keeping the current datastructure with no relationship or changing the datastructure, this should be populated by a middleware

Suggested Workaround

If someone needs the feature until developed, as for the beta 9 version, I got it working by adding a global middleware like this :

'use strict';

/**
 * `inject-url-alias` middleware
 */

module.exports = (config, { strapi }) => {
  return async (ctx, next) => {
    await next();

    if (!ctx.body) {
      return;
    }

    const apiPrefix = strapi.config.api?.rest?.prefix || "/api/";
    if (ctx.request && ctx.request.url && ctx.request.url.indexOf(apiPrefix) !== -1) {
      const { data } = ctx.body;
      if (data && data.attributes && data.attributes.url_path_id) {
          const entry = await strapi.db.query("plugin::url-alias.path").findOne({
              select: ['id', 'url_path'],
              where: {id: data.attributes.url_path_id}
          });
          
          data.attributes.url_alias = entry;

          delete data.attributes.url_path_id;
      } else if(Array.isArray(data) && data.length > 0){
        const entries = await strapi.db.query("plugin::url-alias.path").findMany({
          select: ['id', 'url_path'],
        });

        data.map((model, index) => {
          const path = entries.find((p)=>p.id === parseInt(model.attributes.url_path_id))

          model.attributes.url_alias = path
          delete model.attributes.url_path_id;
        })
      }
    }
  };
};

⚠️ It only works for the data being called, and will not look for other data in relationships

Feature request

Summary

Hi
This is not really a feature request but more of a suggestion for longer term evolution. As it is more a reflexion on data structure, feel free to disagree with me, there's not a single truth on architecture.

⚠ This change wouldn't be backward compatible

Let me explain :)

Why is it needed?

Right now, content types with url alias enabled have an injected url_path_id, which means your content-type is aware of the plugin managing it. This creates a few caveats :

• When enabling the possibility to deactivate aliases for some content-type (beta 9), older content-type created before the update would require a manual cleanup on both files and database.
• Future similar evolution could create the same issue
• Removing the plugin leaves some unwanted data on every content-types that used to be managed by the plugin

Suggested solution(s)

the table url_path should be storing the "remote" content-type id also, which would lead to the following structure :

• id
• url
• contenttype
• rid (remote ID, content-type entry UID)
• generated

This way, you have no field created on your content-type which leads to a lower footprint on user's data.
The only caveat I've came across is that when creating a new content-type entry, you need to store the URI in a temporary table because you need to get the "remote id" after the entry create (using the afterCreate hook) as you can't guess it before the entry is effectively created. It could lead to concurrency issues but Strapi isn't really good a concurrent edition anyway.

Disclosure

I used to maintain the "custom-link" plugin available on strapi marketplace with a former coworker but I don't have enough time right now to work on it right now. I guess I should focus on trying to improve this one instead.

This is the approach we had when starting the project. I should try to implement it in here if you feel interested :)
Let me know what's your opinion on this

Feature request

Summary

Define different paths (or path section), according to the different locales

Why is it needed?

People use Url paths for structuring the content.

If we have a Page collection, and 2 languages EN and PT, and a structure like /[locale]/page/[title], currently the plugin will generate examples like:

• /en/page/test-1
• /pt/page/teste-1
• /de/page/test-1

However, almost every time I'm trying to find a way to generate a localised part of the path, like:

• /en/page/test-1
• /pt/pagina/teste-1
• /de/seite/test-1

This would also benefit a lot when building a website, as:

• a single-source of truth where the URL paths are defined
• no routing re-creation of each page route on the front-end app (like a website)
• the url can be used to fetch the data immediately from the api, unambiguously.

Suggested solution(s)

Coming from several years on the Drupal world, they had a PathAuto module, which works really similarly, but with a key difference - each pattern would be defined for each locale.
Instead of defining /[locale]/page/[title] for each collection, they would define it for each locale:

en: /en/page/[title]
pt: /pt/pagina/[title]
de: /de/seite/{title]

Thank you for the attention, and hoping this goes through.

### Tasks

Bug report

Describe the bug

After setting up both the the sitemap plugins with the core, we want to generate the URL patterns, we go to the screen, and it does not load.

Steps to reproduce the behavior

1. Go to Admin Panel
2. Click on Webtools
3. Click on URL Patterns
4. See error

Expected behavior

We should see the screen available so we can edit the URL patterns.

Screenshots

Code snippets

If applicable, add code samples to help explain your problem.

System

• Node.js version: v20.12.2
• NPM version: 10.5.0
• Strapi version: 4.24.4
• Plugin version: 1.0.0-beta.11
• Database: SQLLite
• Operating system: Manjaro Linux

Additional context

I was using an old version of Sitemaps and I defined the URLs also; as there is no migration guide, I didn't migrate anything.

Feature request

Summary

I liked the "url_path" field in the old url-alias plugin, it is useful in some cases.

Why is it needed?

You may need to have the path of the content you're retrieving (for links, reference...)

Can findMany be added to the content-api for the ability to get all pages with their aliases?

Feature request

Summary

I think it would be a good idea to move this plugin to use typescipt, as it can really improve maintainability and type safety during runtime.

Why is it needed?

I would like to contribute to this plugin, but I think it is much easier to write code in typescript compared to plain javascript. It would also help avoid bugs in the future. I know that Strapi's type definitions are really bad, but we can implement our own when needed.

Suggested solution(s)

I would suggest just switching all js files to ts files to get started, just doing this should not raise any issues.
After this we can slowly add more specific types whenever we need them.

Maybe I am doing this wrong, but I would like to have my URL look like this:

/blog/[category]/[createdAt]/[title]

The category is a relational field type and the createdAt date is auto generated for each post.

For an example, all my URL alias's should look like the following. Each post is neatly organized into the year, month and day.

/blog/how-to/2022/10/12/upgrade-your-crosshair-vi-hero-motherboard-firmware-with-system76-s-pop-os/

Feature request

Summary

As of now custom fields are still in Alpha, though when the custom fields are stable I think this plugin could benefit from registering one of it's own custom field types: Link.

Why is it needed?

This plugin effectively attaches a URL to a record in Strapi. So when you want to link from one page to another, you're gonna be looking at the URL path to link to. Having said that it makes sense to have a "Link" custom field type that is a reference to a specific URL path record. This field can for example be used as a button field to link to another page.

Having it set up this way when you start changing URLs the links keep working, as it is still a reference to the same URL path record that belongs to a specific page.

Suggested solution(s)

A custom field type named "Link" which is a reference to a URL path.

Bug report

Describe the bug

The part of the code that checks if there have been migrated from url alias to webtools does not work in production, since one would already have changed the pluginOptions during development.

Expected behavior

I would expect the migration function to create links once.

Bug report

Describe the bug

Existing entities created before installing the url-alias plugin do not have the url-path column. After installing the plugin many api requests fail because of the preparePath service Promise.all not handling any errors.
Checking out the code, most promises are used in the async-await style, skipping any error handling, which is a "too optimistic way" of managing Promises.

Steps to reproduce the behavior

1. Install Strapi without plugins
2. Create and populate a couple of entities
3. Stop Strapi nd install url-alias plugin
4. See error:

error: Cannot
read properties of null (reading 'url_path')
TypeError: Cannot read properties of nul
l (reading 'url_path')

Expected behavior

No server errors when using the api directly (not using any url-alias).

System

• Node.js version: 16.15.1
• NPM version: 8.11.0
• Strapi version: 4.3.3
• Plugin version: 1.0.0-alpha.4
• Database: Postgres
• Operating system: Linux, Mac

Workaround

In file: node_modules/@strapi-community/strapi-plugin-url-alias/server/content-api/services/prepare-path.js
At the end of the Promise.al on line 18 (should be line 32), add a catch:
.catch(_err => { return; })

Bug report

Installing the plugin breaks the user admin panel

Breaks on: 1.0.0-beta.10, 1.0.0-beta.9
Works on: 1.0.0-beta.7, 1.0.0-beta.8

Steps to reproduce the behavior

1. Install plugin
2. Got to http://localhost:1337/admin/settings/users?pageSize=10&page=1&sort=firstname

Screenshots

System

• Node.js 18
• NPM version: 10.2.4
• YARN version: 1.22.19 (on Linux)
• BUN version: 1.1.1 (on Windows)
• Strapi version: 4.22.1
• Plugin version: 1.0.0-beta.10, 1.0.0-beta.9
• Database: sqlite
• Operating system: Windows 10/Linux

Feature request

Summary

For some content types, it does not make sense to have a url. But for all content types there are shown a url alias field.

Why is it needed?

It can be confusing for the end user why there is a url field for content types that does not have a url.

Suggested solution(s)

• Make it possible to define which content types url alias applies to (or should be ignored) in the plugins config file

Bug report

Hello, thanks for great plugin.
I found issue very similar to #17, but with graphql

Describe the bug

When I tried make query like this:

query {
  urlAliasPaths(filters:{url_path:{eq:"/test"}}) {
    data {
      id
    }
  }
}

I'm getting error message:

{
  "errors": [
    {
      "message": "Forbidden access",
      "extensions": {
        "error": {
          "name": "ForbiddenError",
          "message": "Forbidden access",
          "details": {}
        },
        "code": "FORBIDDEN"
      }
    }
  ],
  "data": {
    "urlAliasPaths": null
  }
}

It's happens because of missing permission plugin::url-alias.path.find, that I expect - should be generated by plugin, and inserted to strapi db.

After manually adding permission to database (via config-sync plugin, and allow it, everything works fine:

{
  "action": "plugin::url-alias.path.find"
}

Steps to reproduce the behavior

1. Execute query
2. Got error

Expected behavior

Plugin should create permissions in strapi db (like here) or expose it somehow to strapi.

Screenshots

System

• Node.js version: v14.20.0
• NPM version: 6.14.17
• Strapi version: v4.3.8
• Plugin version: 1.0.0-alpha.6
• Database: postgres
• Operating system: linux

Bug report

Describe the bug

Whenever I create a content type with localization enabled, create some (translated) entries for it, and try to generate the sitemap I get the following error:

  TypeError: Cannot read properties of undefined (reading 'replace')
      at otag (/Users/boazpoolman/Code/boazpoolman/strapi/strapi-plugin-webtools/node_modules/sitemap/dist/lib/sitemap-xml.js:22:14)
      at element (/Users/boazpoolman/Code/boazpoolman/strapi/strapi-plugin-webtools/node_modules/sitemap/dist/lib/sitemap-xml.js:44:16)
      at /Users/boazpoolman/Code/boazpoolman/strapi/strapi-plugin-webtools/node_modules/sitemap/dist/lib/sitemap-item-stream.js:128:49
      at Array.forEach (<anonymous>)
      at SitemapItemStream._transform (/Users/boazpoolman/Code/boazpoolman/strapi/strapi-plugin-webtools/node_modules/sitemap/dist/lib/sitemap-item-stream.js:127:20)
      at Transform._write (node:internal/streams/transform:175:8)
      at writeOrBuffer (node:internal/streams/writable:447:12)
      at _write (node:internal/streams/writable:389:10)
      at Writable.write (node:internal/streams/writable:393:10)
      at SitemapStream._transform (/Users/boazpoolman/Code/boazpoolman/strapi/strapi-plugin-webtools/node_modules/sitemap/dist/lib/sitemap-stream.js:74:24)

Steps to reproduce the behavior

1. Enable localization for a content type
2. Create some entries for that content type
3. Translate those entries
4. Add the content type to the sitemap URL bundles
5. Generate the sitemap

Expected behavior

A sitemap would be generated like normal.

System

• Node.js version: 20.8.1
• NPM version: 10.1.0
• Strapi version: 4.19.0
• Plugin version: master
• Database: Postgres
• Operating system: MacOS

Bug report

Describe the bug

Hi, it's me again 😬. I have a problem when duplicating stuff.
Duplicated content (created with duplicate button) also duplicate the wt_url_alias relation table row without changing the id reference and without creating a new entry in the wt_url_alias table.

Thanks 🍻

Steps to reproduce the behavior

1. Create an item of a collection type
2. Insert an url alias and unselect Generate automatic URL alias
3. Save
4. Duplicate the item with the duplicate button from the list view

Expected behavior

A new item without url alias or with an automatic generated url alias is created.

System

• Node.js version: v20.11.0
• NPM version: 10.2.4
• Strapi version: 4.20
• Plugin version: 1.0.0-beta.7
• Database: Postgres
• Operating system: Linux

Feature request

Summary

As of now each content type that is visible in the content editor view will get the URL alias fields attached to it by the plugin.
Though you might only need the URL alias functionality for one of your content types.
Having said that it makes sense to let the user enable the sidebar instead of having the plugin enable it for all content types without notice

Suggested solution(s)

I want to have a checkbox in the CT settings just like how you can enable localizations for a CT.
See the screenshot below

Bug report

Describe the bug

Every time a content type is saved the plugin try to regenerate the path and it bounce between /[path]/ and /[path]/-0

Steps to reproduce the behavior

1. Create an item of a content type with url_alias enabled and url_pattern like "/[title]/"
2. Add a title and save
3. You see the correct path "/[title]/"
4. Change some field (not the title) to trigger the ability to save again
5. Save
6. You se the wrong path "/[title]/-0"

Expected behavior

Once the path is generated it updates only when the pattern fields are modified

Screenshots

Code snippets

If applicable, add code samples to help explain your problem.

System

• Node.js version: 20.11.0
• NPM version: 10.2.4
• Strapi version: 4.20.0
• Plugin version: 1.0.0-beta.7
• Database: Postgres
• Operating system: Linux

Feature request

Summary

I mostly use urls without trailing slashes, but some of the users of our strapi deployments may mistakenly set a trailing slash when creating a custom url alias. For example /about/, this mean I cannot fetch the entry by using /webtools/router?path=/about. From a user perspective /about and /about/ will be the same, this it would be nice to have an option such that they would resolve to the same and you could not have a page with both paths.

Why is it needed?

Some users are not the most technical and I also believe it is needed for "idiot proofing"

Suggested solution(s)

1. No duplicates: whenever a path is updated or created, we should check whether or not the path exists with or without trailing slash.
2. Enforce style: Whether or not the plugin should enforce using trailing slashes or no trailing slashes. This would mean that it should check the url path before saving and either remove or set trailing slashes.

Feature request

Summary

Hello.
Now that we can disable URL-Alias for some content-type, I think we could benefit from having certains content-type alias not bein editable (ie, only generated).

Why is it needed?

The base idea of using URL-Alias is to be able to have your frontend router agnotic about URI, giving more power to the adminitrator to create pages. It also mean using a single endpoint to retrieve all (or almost all)your content-type
Sometimes though, for specific pages, it could be useful to enforce a specific layout on router side, while maintaining the single endpoint. This would also give the strapi administrator the information about the URL on frontend.

Ex: Having a list of tag with generated URL only (/tags/[slug]) would correspond on frontend side to a specific component (/tags/[slug].vue using nuxt 3 for instance) which would do some more complex behavior than a single page, displaying several articles related to the tag.

Suggested solution(s)

Adding another checkbox on content-type options to prevent Alias edition.

Disclosure

I used to maintain the "custom-link" plugin available on strapi marketplace but I don't have enough time right now to work on it right now. I guess I should focus on trying to improve this one instead.

Bug report

Describe the bug

When creating a new content-type, the plugin isn't activated by default. If you leave it that way, and create your content-type, then go to create an entry, the side panel is available.

Reason is, when creating a content-type, the pluginOptions isn't created if not selected. Then if the plugin option isn't found, the plugin consider to be activated by default.

Steps to reproduce the behavior

1. Go to the content-type builder
2. Create a "testData" content-type
3. Leave the plugin url-alias unchecked
4. Go and create a new testData entry
5. Panel is showing on the right side

Workaround :

1. Go back to the content type builder
2. Check the url-alias option, save
3. Uncheck the url-alias option, save

This time the pluginOptions is being written in the shema and the plugin is working accordingly

Additional context

Should be easily fixed by either :

• Matching the default behavior for both the admin UI (checked or unchecked) and whatever the plugin assumes when not finding any pluginOptions object.
• Write the pluginOptions when a new content-type is created, be it true or false.

Bug report

Describe the bug

When adding a new entry for a content-type you forgot to add a pattern for, the plugin ends-up adding a strange -0 path. This path then stays in the database when either adding a pattern or adding a custom "manual" path.

Steps to reproduce the behavior

1. Add a new content-type "Foo" with url-alias activated
2. Go to add a new "Foo" entry
3. Save
4. path is now -0 and associated with no entry

Expected behavior

Either deactivate the automatic generation if no pattern is found, or rely on a generic pattern such as /[content-type]/[id]
(ie: /foo/1)

• Node.js version: 18.17.0
• NPM version: 9.x
• Strapi version: 4.12.7
• Plugin version: beta.10
• Database: mysql
• Operating system: ubuntu / MacOS