Diego de Oliveira

Jeff, yes, it is. mysite.com/login/ is the page that TML created, and also the page that the default instance of the [theme-my-login] shortcode is placed. Then, on all posts, when the user is logged in, I tried, like I explained above, adding both [theme-my-login] shortcode and wp_login_form(). only wp_login_form() sent me to the /login/ page showing the error messages correctly. [theme-my-login] sends me to the /login/ page, but without error messages.

An update: I made a quick test. On the article page, I replaced the [theme-my-login] shortcode with a default wp_login_form() function. This function rendered the default WP login form on the article page. When I submitted the form, I was redirected to the /login/ page, BUT on this case, the error message was properly displayed (like I was trying to achieve at the beginning). So, basically, using wp_login_form() works (redirects to /login/ page, with proper error messages), but using [theme-my-login] shortcode or widget doesn’t (redirects to /login/ page, but doesn’t show any error messages).

Hi, Jeff!

Tried that, but it didn’t work. So I’m trying a different approach. Instead of “syncing” the login forms, I just want that the login form on the article page doesn’t redirect to /login/. So this is how it should work:

1) User goes to article page.
2) User sees the paywall with the login form. User fills the form and submits.
3) If username / password is incorrect, reload the article page with proper error messages.
4) If username / password is correct, log in the user and reload the article page.

So, I tried, on the article page, using the shortcode, with or without the instance parameter. Also tried adding the TML widget. Now the login form stays on the article page when username / password is incorrect, but none error messages are displayed. On the /login/ page, error are properly displayed. What am I doing wrong?

Wow, that’s new! Good to know that, David, thanks!

Hi, mbsouth,

I didn’t found a good solution. What I was doing was loading all CF assets manually, it kind of worked but wasn’t a elegant solution. But I don’t have the code anymore, the client ended up using Wufoo with an iframe.

Hi, Daniel,

I don’t have a problem with nested UI’s. The way shortcake works right now is great. I have created a set of fields that passes the necessary attributes to the [table] shortcode, so the issue is not with Shortcake’s UI. I just wanted to render the [table] shortcode inside the Shortcake preview (this is why I’m using do_shortcode), but it’s rendering [table] as a shortcode string instead. Using do_shortcode inside another shortcode is the expected approach from the Shortcodes API on Codex:

If the enclosing shortcode is intended to permit other shortcodes in its output, the handler function can call do_shortcode() recursively:

function caption_shortcode( $atts, $content = null ) {
   return '<span class="caption">' . do_shortcode($content) . '</span>';
}

This is basically what I’m doing.

So, the nested shortcode being rendered as a normal string inside a Shortcake preview is the defaul behavior? Just want to make sure we can’t do anything about it.

Thanks again for your help!

Yep, that did the trick. Now it’s working great!

Thanks, Daniel!

Hi, Daniel, thanks for your response!

I can’t provide here direct access to the file containing the issue because is a private project for a client. But I can send you a secret gist by email so you can take a look at the entire code if you want. What do you think?

We’re not rendering the editor at the frontend. At the backend, we created a page and added the shortcode. The placeholder shows up correctly. But at the frontend, instead of rendering the shortcode, it just renders the placeholder.

I took a look with WP_DEBUG on and we’re getting this error on the frontend page that contains the shortcode:

Notice:Use of undefined constant SHORTCODE_UI_DOING_PREVIEW - assumed 'SHORTCODE_UI_DOING_PREVIEW' in (...)

Seems like is related to the issue – if the SHORTCODE_UI_DOING_PREVIEW constant is assumed as defined at the frontend too, it’s logical that it just renders the placeholder, right?

Thanks for the help!

Same here, all working great now! Thanks!

Same issue here! I have marked the “Group occurrences” option, and created one single event that occurs every week, from tuesday to saturday. The ideia is to show the event only one time. I tried set group_ocurrences_byto series and occurrences, but both gave me the same result (an item showed for every day).

I tried to create the event in these two ways:

1) An event with a start date on tuesday, an end date on saturday, and repeating every week on tuesday. This gives me an item for each tuesday.

2) An event with start and end date on tuesday, and repeating every week on tuesday to saturday. This gives me an item for each one of the repeating days.

How can we make an event like this to be showed only one time?

Thanks for any help.

Maravilha! Obrigado pela rápida corre??o!

Já fiz um teste aqui e vi que rolou tudo certinho agora! ??

Boa tarde, Claudio!

Maravilha! Consegui fazer uma “gambiarra” aqui pra criar a metabox com os cálculos necessários, mas vou aguardar ent?o a sua implementa??o oficial!

Valeu!

Hi, David,

Thanks for the plugin, it works like a charm! It’s perfect for what I needed, simple and very usefull stuff.

Keep the nice work!

Cool! Thanks for the quick update! I’m already using it!

And please, keep the good work, Hannes!

Thanks!

Wow! My mind is blown! O:

I followed your instructions, and it worked like a charm! Thanks, David!

That’s not just the best form builder, but I think it’s one of the most powerful form system! I can think a ton of use cases for this type of feature!

Again, thank you for your answer! And please, keep the awesome work you’re doing!