mermare

margin is also duplicated in that CSS declaration.

Edward,

It doesn’t look like the staff member slug can be edited. Is that true? For our use case, since the “staff” rotate frequently (church positions) – it makes the most sense to have the permalinks for the staff be the position rather than the staff members name so that even though the title will show the staff member’s name, I would have the staff position as the permalink. This way it is easy for the church to swap out the content of a staff member, when the position rotates. This also helps in areas where that position is referenced in other places of the site, or in the newsletter, or wherever so that the link doesn’t need updating and 301 re-directs and it helps to maintain that SEO. So, …can we edit the staff member slug?

Thank you.

Hi Edward,

I can retrieve the custom CSS as it is in my child theme. What I meant is that the update to v2 has rendered my styles useless since it is no longer using the two templates that you had made as an integral part of the Staffer plugin to display Staff (pre v2). It seems that your new version of Staffer should be a different plugin altogether if it cannot maintain fundamental backward compatibility and the permalink structure of staff created by the pre-v2 users. At the very least version 2 should have come with a warning that installing it could seriously impact functionality and appearance for those who have been using the pre v2 Staffer plugin.

When will we have access to the old version of Staffer?

Where will it be posted?

Will rolling back work properly?

Can we expect that the old version will continue to be secure and compatible with current versions of WordPress?

I’d appreciate your answering these questions thoroughly.

Thank you.

This is a problem for our site using the Staffer plugin with Justin Tadlock’s Members plugin too.

We have the same issue and request.

Same here. It seems that providing users of Staffer to have the choice to have the individual staff pages open as they had (in a direct url) prior to the new version (which now opens individual staff in a lightbox) in order to preserve backwards compatibility is essential to avoid a nightmare of links to staff returning 404 errors. I really hope that CodeWrangler, Inc. is monitoring this support area and will provide a fix soon.

I am adding that I do have email replies setup within Stripe and I have tested them and they work. They also work with other Stripe connected accounts I have but don’t work on the Gravity Forms + Stripe forms despite the payment processing.

• This reply was modified 7 years, 4 months ago by mermare.

Hi David,

That worked and no noticeable errors. Thanks lots for the quick fix especially on a Sunday! ??

@esmi and @ddolenc – i started my own thread for this issue here: https://www.ads-software.com/support/topic/gravity-forms-mad-mimi-add-on-plugin-issues-after-20-update

I have the same issue as ddolenc. And in the plugins directory there are two 2.0 versions one (stable) and one (beta). And if I try to delete one of them, it will delete the files for both plugins however I just have the (beta) activated. What’s happening here?

Thanks.

I just had this same issue. I ended up deactivating and deleting WordPress SEO and reinstalling and reactivating it to get rid of the OpenGraph data. I wish I did not have to do that since I lost my settings for WordPress SEO and had to redo them.

Hello,

Can you guide to where to check that?

I have since added Contact Form 7 to the site and that clears correctly.

Thanks for the help,
Marianne