batman42ca

I had previously refreshed the page with an uncached version by pressing Ctrl-F5 within my browser, but that didn’t help. A quick search showed me how to clear my computer cache and that solved the problem. I didn’t expect that to work because I would have expected both links to fail or succeed together, but there’s no arguing with success. Clearing my computer cache fixed the problem. Pressing Ctrl-Shift-Del on my PC brought up the window that enabled me to clear my computer cache.

Thanks for your help. I’m glad to discover the problem had nothing to do with your plugin.

• This reply was modified 4 years, 10 months ago by batman42ca.

It looks like this is the CSS that is needed. No change to the HTML is necessary:

[data-bind="if: extReferer()"] a {
    color: #f00;
    font-weight: bold;
}

• This reply was modified 7 years ago by batman42ca.

Your suggestion helps but not all referrer urls contain “www”. Hopefully a small css change can restore the highlight of referrers in the next update.

Thanks.

Thanks for the replies. Too bad events can’t be viewed from within the plugin. It would be a useful feature.

I typed this into google:

“wordpress twenty thirteen release notes”

and one of the pages was this one:

https://codex.www.ads-software.com/Twenty_Thirteen_Theme_Changelog

I finally have a solution that works. The basics of the code is as follows. In my custom functions.php file:

// ensure a session is started even if running via an AJAX call.
if (!session_id()) {
  session_start();
}

function interceptCf7 ($cf7Form) {
  $cf7 = WPCF7_ContactForm::get_current();

  $submission = WPCF7_Submission::get_instance();

  // if a form was submitted
  if ( $submission ) {
    $_SESSION[cf7Data] = $submission->get_posted_data();
  }
  // don't send the email
  $cf7->skip_mail = true;
}
add_action("wpcf7_before_send_mail", "interceptCf7");

I also configure the extra settings in my form admin with this:

on_sent_ok: "location = 'https://myWebSite/myPage';"

With that, I have access to he form data so I can do whatever I want with it. Submit it to a database, display in on the web page, pre-fill a PayPal form, whatever.

I had tried using $_SESSION earlier, but it failed because I called session_start() in header.php, but header.php is not going to be included during an AJAX call. Realizing that, and adding another session_start() call where my custom functions exists so that during AJAX call, a session will be started, gave me access to the data that I wanted in the way that I wanted it.

NOTE that the above code would be applied to ALL contactForm7 forms. I haven’t tested it yet but I believe it may be possible to check one of the following variables to test if the desired form is the one being processed (placed inside my “interceptCf7 function above”)

$cf7 = WPCF7_ContactForm::get_current();

// check one of these to see if it matches the desired form
$cf7->id // ex: 867
$cf7->name // ex contact-form-1
$cfg7->title // ex Contact form 1

Hopefully this helps someone else.

According to eventualo, it’s been fixed, but in the past, I experienced no problems after I removed the email addresses from the unsubscribe table. That seemed to be good enough.

I appreciate the help, but I don’t think you’re fixing the problem I’m having. This has nothing at all to do with /r or /n characters. This has everything to do with HTML angle brackets being encoded.

The angle brackets are being turned into HTML entities. See this page:

https://www.w3schools.com/html/html_entities.asp

I need WordPress to stop turning my angle brackets into HTML entities. This seems to be something new since I upgraded to WordPress 4.1

Thanks but that won’t work. The $translated text in my sample is already the correct HTML. It’s whatever happens after it is returned by my function that is the problem. My problem is that I want the

<br />

to remain that way and be echoed to the browser as an HTML line break. Instead what I see displayed is a literal less than sign, the text “br /” and then the greater than sign even though I’m returning the proper HTML from my function.

I checked my return value before I returned it and it was correct. Something somewhere else is changing it.

I think I just realized the cause of my problem. My entire site is not https. Only a few select pages are https, so site_url() (which I suspect comes from the database) will correctly return “https://something” even though the page on which the login form exists is “https://something”.

I now think this is actually a subtle WordPress bug. The solution is to do what I already did, or run the entire site under https.

Thanks for your help.

Thanks but where is that call being made? I’ve searched all the Profile Builder .php files but I don’t see that code anywhere. I’m using version 2.08.

I searched for esc_url, I also searched for wp-login.php and did not find the code you quoted.

Note that there are still places where http is hard coded. For example. I see the following on line 138 and 178 of class-formbuilder.php

$redirect_location = ( wppb_check_missing_http( $this->args['redirect_url'] ) ? 'https://'.$this->args['redirect_url'] : $this->args['redirect_url'] );

$location = ( wppb_check_missing_http( $this->args['redirect_url'] ) ? 'https://'.$this->args['redirect_url'] : $this->args['redirect_url'] );

I’m using it with 4.1 and is seems to work fine.

Ooops. I was debugging 2 plugins at the same time and I just realized it is the other plugin that is causing me problems. Please ignore this.

I found a place in my code where I was doing this to suppress new registration notification:

add_filter ('wppb_register_admin_message_content', array($this,"_suppressNewUserEmail"), 10, 5 );

Has this changed?

Although not ideal, I have a temporary solution to my problem.

I used javascript to alter the action of the Profile Builder login form to post to https instead of http, and then I used a plugin to force the WordPress admin pages to use https.