dauidus

As of now, this plugin only supports up to 5 custom taxonomies. I’m looking to improve the logic behind this in the future. The quick-fix for now would be to only use 5 custom taxonomies.

-D

I’m still marching forward with development, but am still working on the custom fields implementation. It seems, each time I take a step forward, I take two steps backward… fairly common in development cycles.

Beta testing is still on the horizon. I have many other features working fine, but the one you’d like to test is still in development.

I can tell you that the first release of PRO most likely won’t have support for CF logic filters… only the fields themselves.

I will post here with news when I have it. ??

-D

Well, logic filters is one area that isn’t going to be covered in the first PRO release. Turns out, supporting this for the top 5 custom fields plugins is somewhat of a nightmare, as they all handle logic in different ways. I will get there… just not enough hours in the day, as it stands.

I teach full-time at University, run a small dev shop and get sucked into more volunteer hours than anyone should around town – so admittedly, development on this has been slower than desired. But, it will eventually get there.

-D

sk8walker96,

I’ve been receiving a lot of excitement about the release of the paid version – and, I’m nearly there, as far as a release date. The PRO version adds a ton of extra functionality (not just custom fields) and I’ve got a few bugs to work through. I’m hoping it’ll be close enough for some initial beta testing, starting as soon as next week.

I’ll be sure to contact you with some information as soon as I have it.

As far as paying beforehand – I’d be more interested in giving it to you for free, in exchange for some closed testing, and/or a second pair of eyes on the code, in the coming days.

??

-D

Dax87,

Due to the many requests for this functionality, I have decided to add it in a PRO version of this software, coming in the next 2 months.

y goal is to automatically add required custom fields created by 3rd party plugins to the requirements list. This is difficult, because of the many ways 3rd party plugins deal with required settings.

It will be released soon-ish… I’m working on it in between many other projects.

-D

Andrzej,

Have you come across anything that’s helped here?

Thanks!

Miguel,

I am experiencing the same issue. I’m using the widget and selecting my custom post types, but all generated links point to the default post archive pages, not my custom post type archive pages. I’ve not tried this with the shortcode.

I’m using the ‘types’ plugin to create post types, and have checked through that plugin’s settings to ensure everything is set properly. I’ve also disabled other plugins on the site to ensure nothing is conflicting, with no effect.

For now, I’m using another widget to simply list post type archives by month, but we’re really missing the jquery dropdown functionality. We’d like to resolve this soon.

Thanks!

Good point about a million users to a couple hundred complaints. I’m sure more than that have been affected, though. And, most of them have probably dealt so in silence. I did write a review of their new version, but I hardly ever do so – usually easier to just move on and choose another option.

Their interface change is clumsy. And, I’m sure they’ll fix it at some point. Hopefully, you don’t have too many posts (it could take forever to copy/paste that description on every page). I manage some sites with thousands of posts (magazine/ news sites) and the thought of manually fixing that problem seems daunting. If that’s your case, rolling back might be a good temp solution. Otherwise, roll on!

Thanks again for the issue report… I’ll keep an eye on Yoast as they move forward on this.

-D

marking as resolved

ghoush,

Actually, I’ve looked into it some more and it turns out, my plugin does seem to be working with the new version of Yoast SEO (3.0.3).

The input fields have changed in Yoast (now, they’re using hidden fields to contain input values, rather than visible ones). But, those fields hidden fields have the same ID’s as the visible ones did, and I’m not running into an issue.

What has changed is that the default value for the description box (the one added automatically based on WYSIWYG content) is not contained in the new hidden field, but only in the visible one. So, if you use my plugin to require a meta description, the user must enter a custom meta description. That is confusing for users, but I feel its an issue with Yoast’s UI, more than my own. Nonetheless, I will update my plugin to fix that issue. Until then, you might want to uncheck the meta description box in my plugin.

I am interested to hear your thoughts.

I’m also wondering if adding an option to require a good SEO score (a green traffic light, if you will) would be more beneficial than individual settings for fields. I do know of people (myself included) who don’t necessarily aim for a green light every time. But, that is what seems to set Yoast SEO apart from the others. Please share your thoughs.

And, my apologies for all the replies – this is a confusing issue report.

-D

ghoush,

Well, I have some bad news here. It seems the 3.0 Yoast update wasn’t very well tested and broke much of the functionality in their plugin. There has been an outcry among long time users, and many users have already chosen to switch plugins.

How does this affect our situation? It tells me that Yoast will probably see another update in the near future that brings back some of the original functionality. I’m all for updating code to make this plugin work again. But, I’m more for future-proofing my own plugin. In other words, if I need to support other plugins that are broken, my plugin will become messy, unreliable and difficult to maintain. Until Yoast figures out their problems, my plugin will only support working versions of it.

So, I highly suggest you roll back to the last Yoast version before their 3.0 release. I know its not ideal, but its what I need to do to maintain my own codebase. If you absolutely need to use Yoast 3.0 or later, I am available for custom work at an hourly rate.

I Hope you understand my position on this. Let me know if you agree.

-D

ghoush,

Goodness, yes they did. I’ll have Requirements Checklist updated within the next few days. It will include fallback support for older versions going back one year.

Thanks for the heads-up!!

In the meantime, you might want to roll back to the last Yoast update before 3.0, to retain functionality for your users.

I’ll post back here once my update has been pushed.

Cheers!
-D

ps3hero,

I am including this feature in a PRO (paid) version of this plugin, to be available in the coming months. I’ll let you know as this release gets closer.

-D

Courtney,

After much thought, I have decided to move SEO requirements into a paid PRO version of this plugin, which will be available when the next major release drops. This, and many other feature enhancements and additions will make the PRO version a very powerful tool for content managers.

However, if you’d like to stay with the current version of the free plugin, you are free to do so. But, you will not enjoy the benefits of many bug fixes and additional functionality.

I’ll let you know as I get closer to the PRO plugin, so you may make an informed choice.

marking as resolved

-D

lamonlythird,

This feature has been implemented and will be available as a paid feature when the next major release drops.

-D

mrickan,

CSF support has been added to the development queue and will be available when the next major version is released. This goes for all custom fields, too, as well as some other features, as per our email conversation.

-D