custom posts
-
And another question…
I’ve noticed that a custom post with private information (dashboard only) has SEO settings for every post. That looks like a bug. And in the dashboard screen for that custom post there is a SEO column with only “TGDGIFA”, so no colors. I guess that that column also doesn’t need to be there.
I do notice that the entries don’t end up in the sitemap. So that looks fine.
Can you tell me under what circumstances the SEO settings are added to custom posts? Can you tell me under what circumstances custom posts are added to the sitemap? Or can I find more about that in the documentation?
I have other websites with other types of custom posts and will check them later.
-
Hi allm,
Is it a special post type? And if so, how did it get there?
The requirements for these items to show up the SEO settings is when they have an editorial interface (content) and Title input available.
The reason they’re not colored is because no CSS is loaded, so not all checks seems to pass correctly on this specific post type.They’re not shown in the sitemap because they’re not public. This might correlate with the absence of the CSS.
The sitemap adds anything that abides to the above three rules. Plus another one. Listed:
1. Publicly accessible.
2. Have a title entry available.
3. Have a content entry available.
4. Do not have “noindex” enabled within the “in-post” SEO settings.I hope this clears things up! I await your reply so I can fix this bug :). Thanks!
I have the same with the WP Help plugin. It generates a backend use only custom post type
wp-help
and it shows the SEO Metabox as well as the SEO column without colors as @allm above reports.Any chance to make an option available where the admin can set where the SEO Metabox should show?
Thanks for the example Piet! I’ll look into it.
Every post type has its own “Screen Settings” found at the top right of the dashboard, on which you can enable or disable the SEO bar’s output.
Hi Sybre,
In this case it is a custom post from a plugin that I have written myself. The custom post does not result in pages on the website, but the info is used to display widgets on the dashboard.
It is perfect that this custom post is not in the sitemap, but there is also no need to display the SEO metabox (and the column I described).
It does have a title and content, because I need that.
Isn’t it an idea to make it possible for people to edit for each (custom) post whether they want:
. show it in the sitemap
. add the seo metaboxOf course you can always guess what people want and provide that as a default, by looking at the custom post parameters, but the possibility of overwriting that would be a good idea. The possibilities with custom posts are almost endless, so giving people some flexibility might be a good idea.
I have some other examples that I can test. If you want to know more about the details of my current example I can mail you the specifics.
Every post type has its own “Screen Settings” found at the top right of the dashboard, on which you can enable or disable the SEO bar’s output.
Yes, I am aware, but if I’m building sites for people, then it needs to be gone before they login and it is a bit cumbersome for me to login as each individual user and fumble with the Screen Options ??
@piet, you might want to start your own thread. My question gets lost like this.
@Sybre: Hope you look back in this thread to find my reply…
Hi allm,
I read every reply carefully :).
The parameters you’re both discussing, are somehow very related.
At both Piet and allm’s questions:
This requires an extension that looks for all available post types and then adds global options for those. It’s planned, but it might not be released as early as this year.From here, I diverge it into two answers.
@realblueorange:
In general, it looks for if the post type is publicly accessible (as explained in my first reply). These parameters, as you’ve already guessed, are used as the “guess”.
Adding specific options for this is asking for an unwary user’s input.
Explained here:When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.
Many options might look cool, and it is cool for advanced “power-users”, but could harm many other users. It’s verbose, and very confusing.
This is something I’ve learned in a Game-Design study :).An option also needs to be maintained, and needs be considered and tested against in every update. This takes vasts amounts of time.
In the early days of this plugin, I could release an update in a few hours and I knew it would work. Now it takes over 2 months and bugs still come up afterwards.For this reason, I’ve added many filters, instead of visible options. The filters can be found here. I still need to update that page for 2.6.0+.
To add onto that, as I stated earlier, the filters are planned to be put into options; through extension plugins. These plugins still have to be started on, and require a lot of time which I currently can’t obtain.
@senlin:
As it takes a lot of time to conduct such an extension — if you’re faster than I am, go ahead :D! In the other thread you’ve discovered and used the available filters for this already :).@Sybre
Thanks for your reply. I fully agree that more options should be added with the utmost care.
But then I come back to my original question: I’ve got a custom post that is for dashboard / internal use only, so it doesn’t need the SEO metabox. The guessing you do right now doesn’t always seem to work. And there seems to be a CSS problem as well.Wouldn’t it be better to guess that if a custom post is not in the sitemap, it probably won’t need the SEO metabox (and related functionality)? The guess you are now making depends on the availability of the title and content. But they can be available for private custom posts as well.
Can I help in any way to get this fixed / make this better?
Hi allm,
You’re right. And it is intended like this as well. The guess for the sitemap is the same as with the SEO metabox. Alas, something is not fitting the puzzle quite well, which is caused by a bug.
The “guess” is both “being public” and “having a title and editor”. For all cases :).
I’ll see if I can fix the bug as soon as possible. Until then, have a great day!
Hi Sybre,
Great! It is a good idea to check out what “being public” means for a custom post. If I understand correctly it is possible to set the “public” parameter for a custom post to “true” and then setting the related parameters so, that in fact it is not public. And vice versa.
If the “rewrite” parameter is not false there is a good chance the custom post is public.
Having a title and a content box does not in any way decide whether a custom post is public or not.
Maybe someone else can specify the conditions under which there is 100% certainty whether a custom post is public or not.
Thanks for all your hard work. Really appreciated!
PS tonight I thought of creating a seperate plugin to manually set your SEO metabox and your sitemap on or off for all the (custom) posts in a website. That way your guess is the default, but if you want to you can do things otherwise. Can I use any of your filters to turn sitemap generation on or off for specific custom posts? And the SEO metabox? For now I will leave that for some future moment when the need arises or having too much time on my hand…
@allm I have the filter that Sybre provided with his plugin working with a conditional. If you want to use it on your own site, then adapt it for your own use:
add_action( 'current_screen', 'so_hide_seo_backend_output_cpt', 9 ); function so_hide_seo_backend_output_cpt() { $current_screen = get_current_screen(); if ( $current_screen ->post_type === 'wp-help' ) { // change wp-help into your own CPT add_filter( 'the_seo_framework_seobox_output', '__return_false' ); add_filter( 'the_seo_framework_show_seo_column', '__return_false' ); } }
Hope it helps.
Piet@Sybre: please take a look at my latest reply, before Piet’s reply.
@piet: thanks a lot for providing this function. Do you know if there is a filter to set the SEO metabox ON for certain custom posts? So if the plugin decides to switch off the SEO metabox for some custom post I can turn it back on again.
Have you looked at turning on/off generating sitemap info for certain custom posts? Is there a filter for that as well? In case you haven’t maybe @Sybre can provide the answer to that…
By the way: I have made a small change to your code. You can get $current_screen as an argument, in stead of having a new function call. For more info:
https://codex.www.ads-software.com/Plugin_API/Action_Reference/current_screenadd_action( 'current_screen', 'so_hide_seo_backend_output_cpt', 9 ); function so_hide_seo_backend_output_cpt( $current_screen ) { if ( 'wp-help' === $current_screen->post_type ) { // change wp-help into your own CPT add_filter( 'the_seo_framework_seobox_output', '__return_false' ); add_filter( 'the_seo_framework_show_seo_column', '__return_false' ); } }
@allm: awesome, thanks for beautifying and simplifying the function ??
I have not tried, but I would assume that if you set the action set false to true, it should work to force the backend output to show for certain post types?
Sorry I have not yet looked at how to do something similar for the sitemap output, hopefully @Sybre has something for that.
Hi guys,
I think most of this topic has already been settled or discussed. Nevertheless, if you can’t go up, you can always go down. The “
!
” is always there for you in PHP.There are many filters to apply such conditions, I’ll direct you to them on GitHub below, as I still need to catch up on my documentation:
Title and editor support.
Post type supports (bypasses above filter).
Post type supports 2 (undoes/supports above bypass).
Excluded CPT from sitemap.
Disabling transients for debugging.As it’s so much text to process, let me know in numerical questions so I can answer without confusion :).
I hope this helps! Keep me updated :).
Hi Sybre,
Thanks for your reply. I’ve looked at all the links and I have a hard time finding the right answers. Or maybe I am posing the wrong questions…
Earlier today I made a numbered list in a new thread (as you just requested ;-), just to get things organised again. You can find it here:
https://www.ads-software.com/support/topic/custom-posts-wrapping-it-up
I’ve set the current thread to resolved.
- The topic ‘custom posts’ is closed to new replies.