Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom post type and Custom taxonomy linking problem #65

Open
hatsumatsu opened this issue Aug 14, 2014 · 21 comments
Open

Custom post type and Custom taxonomy linking problem #65

hatsumatsu opened this issue Aug 14, 2014 · 21 comments
Assignees
Labels

Comments

@hatsumatsu
Copy link
Contributor

I have a setup of two languages in a Wordpress Multisite environment, based on paths:

Main language:
http://example.com/
Second Language:
http://example.com/en/

When I register a custom post_type width slug => "my_post_type" I get the achive pages:

Main language:
http://example.com/blog/my_post_type/
Second language:
http://exmaple.com/en/my_post_type/

(Note the /blog/ permalink fragment, that should stay there following the WP Codex http://codex.wordpress.org/Before_You_Create_A_Network )

This results in the language switcher to point me to http://example.com/my_post_type/ when switching from the second language to the main language, missing the /blog/ part of the URL or to http://example.com/en/blog/my_post_type/. Both throw an 404. Same behavior occurs on custom taxonomy archives.

@lloc
Copy link
Owner

lloc commented Aug 15, 2014

Go to the permlinks settings after creating a new post_type. Let me know...

@hatsumatsu
Copy link
Contributor Author

I updated permalinks settings after registring the post type, permalink structure is set to /%postname%/ on both sites. I produced a reduced test case and the bug still appears:

  • fresh wordpress install under http://multilanguage.local/
  • no plugins
  • setting permalinks to /%postname%/
  • Creating a sub-directory based Network following http://codex.wordpress.org/Create_A_Network
  • Creating a second site in the network under http://multilanguage.local/en/
  • Installing a simple theme that registeres a post type with 'rewrite' => array( 'slug' => 'projects' )
  • Checking and updating permalink settings on both sites (still /%postname%/)
  • now the main sites post type archives lives under http://multilanguage.local/blog/projects/, the archive of the second site under http://multilanguage.local/en/projects/
  • Using the Multisite Language Switcher widget to switch from one language to another on these archives points either to http://multilanguage.local/en/blog/projects/ (main site > second site) or http://multilanguage.local/projects/. Both trow an 404.

@lloc
Copy link
Owner

lloc commented Aug 16, 2014

Strange ... I will try to reproduce that when I'm back at home (next weekend).

@hatsumatsu
Copy link
Contributor Author

Could you reproduce the problem?

@lloc
Copy link
Owner

lloc commented Aug 28, 2014

Yes, after playing a little bit with WordPress 4.0 I had the same issue.

@lloc lloc added the Bug label Aug 28, 2014
@lloc lloc self-assigned this Aug 28, 2014
@lloc
Copy link
Owner

lloc commented Sep 1, 2014

This should do the trick 8821ef1

Let me know,
Dennis.

@lloc lloc closed this as completed Sep 1, 2014
@hatsumatsu
Copy link
Contributor Author

thanks for the fix!

@hatsumatsu
Copy link
Contributor Author

I think the bug is only fixed in parts: Switching between languages on Custom Post Type archives and Custom Taxonomy term archives works well. But going to another language on a single post view of a custom post type still doesn't work.

@lloc
Copy link
Owner

lloc commented Sep 17, 2014

The fix is just for taxonomies where the get_term_url relies on $wp_rewrite. MSLS uses get_permalinks for all post_types where this problem should not exists. Could you double-check this please?

@lloc lloc reopened this Sep 17, 2014
@hatsumatsu
Copy link
Contributor Author

Ich checked it again in my testing environment, the connection between single views of custom post types (posts and pages work well) seems somehow broken:

Sticking to my example above, a single view in the main site is located under
http://multilanguage.local/blog/projects/projekt-deutsch/. In this view the language switcher points to the connected post under http://multilanguage.local/en/blog/projects/project-english/ (notice the wrong /blog/ part of the URL). The second site's post is found under http://multilanguage.local/en/projects/project-english/ but the language switcher points to http://multilanguage.local/projects/projekt-deutsch/ (here the /blog/ part is missing).

I'm using v.1.0.1 of the plugin from github and WP 4.0

@lloc
Copy link
Owner

lloc commented Sep 18, 2014

Is the custom post type projects registered with hierarchical set to true or false?

@hatsumatsu
Copy link
Contributor Author

Not defined, so defaults to false. Here is my Custom post type and taxonomy setup:
https://github.com/hatsumatsu/Port-F/blob/master/functions.php#L109

@lloc
Copy link
Owner

lloc commented Sep 18, 2014

Maybe this is useful too: http://wordpress.stackexchange.com/questions/133498/remove-multisite-blog-slug-from-specific-custom-post-type ... I will test a little bit more because I'd like to understand if this should be corrected in the core or in the plugin. In my opinion get_permalink should act always in the same manner.

@hatsumatsu
Copy link
Contributor Author

Thanks for the hint and your effort, but it turns out to add even more complexity to the issue: I added 'with_front' => false to the rewrite array both in register_post_type()and register_taxonomy() to get rid of the odd /blog/slug in the URLs on the main site. After refreshing the permalink settings on both sites the connection between single views of custom post types works, but it breaks the connection between custom post type archives and custom taxonomy term archives in one direction:

  • on http://multilanguage.local/projects/ (main site) the language switcher points to http://multilanguage.local/en/projects/ : Works
  • on http://multilanguage.local/en/projects/ (second site) the language switcher points to http://multilanguage.local/blog/projects/: Fails

Same issue occurs on custom taxonomy term archives.
I guess it all comes down to this odd hard-coded behavior of the WP core to add the /blog/ slug (only) to the main site's URLs...

@hatsumatsu
Copy link
Contributor Author

just curious, any news on this issue?

@lloc
Copy link
Owner

lloc commented Nov 4, 2014

I plan to write an add-on (like MslsMenu) that can manage the localized slugs and offers inputs for correcting the $wp_redirect-rules.

@giovannetti-eric
Copy link

Hi lloc,

Thank you for your great work.
I see this issue is still open and it's seems I have the same problem.

I have set custom permalink to /news/%postname%/ for my two sites (the /blog/ part was removed) :

  • mysite.local/news/
  • mysite.local/fr/news/

I have a /news/ archive page set as Posts page in Reading Settings, and posts like this :

  • mysite.local/news/my-post

The Msls links correctly the news archive page and the post pages.

However I have some custom post types archive pages like /services/, and there I have this :

  • mysite.local/services/ links to mysite.local/en/services/ = OK
  • mysite.local/en/services/ links to mysite.local/news/services/ = NOK

When I look the register_post_type, there is the rewrite argument with the with_front parameter set to false.

There may be something I have not done properly ?
Thank for your time.

@hatsumatsu
Copy link
Contributor Author

Hi, just checking back on this issue. Is there anything we can do to help solving this?

@s-a-s-k-i-a
Copy link

Is this still an issue?

@lloc
Copy link
Owner

lloc commented Sep 13, 2017

There is a function active in the plugin's options that should show you if there are any translations active.

@stijnjanmaat
Copy link

Hi, i'm experiencing the issue @hatsumatsu described with the custom taxonomy terms losing links in one direction. And is this an issue with WP core, or should msls handle this?

And for now the work-around would be keep using /blog/ on the main site?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants