qtranslate slug

[andreysneg]

Hello.

Qtranslate cannot be used without "Qtranslate slug" plugin. All SEO die without slugs for every language.

Now "Qtranslate slug" plugin removed from wordpress repository.
And last update was 6 years ago.

Github of project here. But github plugin have many errors and dont work normally.
https://github.com/not-only-code/qtranslate-slug

Here my slightly modified for php 8.1 plugin version:
https://sneg.ee/qtranslate-slug-php8.1.zip

I suggest either inserting this plugin directly into the Qtranslate (with the permission of the developer) or simply rewriting it with an alternative code. This is small plugin.

Thank you.

[herrvigg]

We opened this discussion long ago, see #671.
It is happening right now. A fork of qtranslate-slug has just been merged as an experimental module, see #1060. The integration is still in progress, but please test it.

[Hr0bar]

As a common plugin user, it would be ideal to have this happen automatically/on forced prompt question when its detected that "qTranslate slug" is installed on qtranslate-xt activation AND automatically/on forced prompt question on update of qtranslate-xt version that adds the slug integration, so next version to be released (but the on forced prompt may not be technically possible im afraid in wordpress - what if admin does not visit the page etc, only replaces plugin folder and so on)

So I vote for "manual button in the slugs settings". Also gives more control to the admins instead of doing automagical things automatically, which many people do not like. Also if the admin is removing the old plugin then he is already consciously tinkering with the wordpress instance, so it makes sense to be more manual on QTS side as well then.

[spleen1981]

If we want to provide the migration feature from qtx settings, a button to remove the old plugin folder included in a notice on slugs module activation could be enough...
I would avoid messing up with existing metadata from posts terms etc.
Even if we do, that should be triggered by a manual action given the implications (no way back).

[herrvigg]

QTX should never uninstall any other plugin. This action is entirely left to the admin.
What do you mean by messing up metadata? The current state is messed up because there's no clear ownership. The "QTS" data are now owned by both the QTS and QTX plugins. QTX is a different plugin, it's too risky to say "don't uninstall QTS otherwise you lose all in QTX as well".

It's technically feasible to have a prompt question, we have such feature already in QTX. The admin button could also be interesting for more advanced admins, but I don't think it should be in the main slugs settings because it's not something you should act on normally.

[herrvigg]

Resolved by #1171 migration of QTS.

[herrvigg]

The import feature from QTS has become a migration with #1171, now merged in master. The release 3.12.0 is approaching. Please test this and let us know how it goes.

There's a temporary hack to revert the renaming of qts_options in master before migration. That's meaningful for those who worked with the slugs module on master recently cc @bagaweb. The migration is expected to be done once from this point. This hack will be removed before release so those not using master in development are not impacted by this.

[herrvigg]

For precision: the hack to rename qts_options is just to ensure the current post type / taxonomies slugs are not lost during the migration (user data in the slugs settings). It doesn't affect the slugs functionality after migration.

[bagaweb]

Thanks for all your work!
I'm going to test the new master and check if everything works fine. Will test it both on the website where I was testing last week, and on another website which still uses the old slugs plugin.

[bagaweb]

I don't understand if the second checkbox should be checked or not...

Confirm migration of QTS slugs in database. Attention! Existing slugs are replaced. Leave unchecked for a dry-run.

[herrvigg]

Maybe with a notice for backup.

Confirm migration of QTS slugs. Attention! Existing slugs are replaced. Leave unchecked for a dry run test. Before confirmation, it is recommended to backup your database.

[herrvigg]

"Existing slugs are replaced." may sound confusing. It's quite complicated to summarize it all briefly. Perhaps it's better remove it and keep just this:

Confirm to perform the migration of QTS slugs. Attention! It is recommended to backup your database before confirmation. Leave unchecked for a dry run test to see how many items are erased / migrated.

[spleen1981]

I think we could remove all mentions to "erased/deleted items" in the notice to make it simpler, and just reporting the migrated ones.
Adding to the second checkbox the disclaimer "All current module slugs data (if any) will be replaced." after the first sentence above should be sufficient.

[herrvigg]

In reality it's not all current data that are replaced, but only those that would conflict with the migrated ones.

[herrvigg]

Updated as:
Confirm to perform the migration of QTS slugs, or leave unchecked for a dry run test without update. Attention! Current module slugs data may be overwritten.

[bagaweb]

Alright thanks for clarifying this.

I've tried the migration leaving the second checbox unchecked and this is the result:

Dry-run mode: Deleted 0 slugs from wp_postmeta (qtranslate_slug_). Migrated 52 slugs from wp_postmeta (_qts_slug_). Deleted 0 slugs from wp_termmeta (qtranslate_slug_). Migrated 4 slugs from wp_termmeta (_qts_slug_). Deleted 2 types from options. Migrated 9 types from options.

The slugs seems to be gone, should I run the migration again checking the second checkbox?

[herrvigg]

@bagaweb please can you create a separate issue for the case after migration? It will be easier to follow than in this "discussion" thread. It's also for better visibility for others. At first sight it looks different, but it may have the same origin.

[bagaweb]

Is your page published?
Yes pages are published.

@bagaweb please can you create a separate issue for the case after migration?
Is it ok if I reply to #1180 or should I open a new issue?

[herrvigg]

If you think it's a different issue, better open a new one. The problem mentioned in #1180 is about rewrite rules.

Please let us know what you have after migration for the child post here:

SELECT * FROM wp_postmeta WHERE post_id=<ID>

[bagaweb]

I think there's no need to open a new issue because the problem looks solved!

After migration I have :
qtranslate_slug_it
qtranslate_slug_de
qtranslate_slug_en

[herrvigg]

That looks correct!
How is the problem solved? With the last patch on master (from #1180)? In that case you can also comment in that issue, yes.

[herrvigg]

New module Slugs has been released in 3.12.0.