ernst1234

@eric4969
You are correct. Upgrading “Send PDF for Contact Form 7” to version 1.0.18 solved the problem. I saw the offending code in the 1.0.17 version.

Awesome, it’s solved.

• This reply was modified 11 months, 3 weeks ago by ernst1234.

@eric4969
Do you have the same theme?
Other plugins in common?
And lastly, PLEASE, if you find a solution, let us know ??

Theme: Divi (by Elegant Themes)

Plugins:
Akismet Anti-spam: Spam Protection: version: 5.3
Beautiful and responsive cookie consent: version: 3.1.0
Conditional Fields for Contact Form 7: version: 2.4.3
Contact Form 7: version: 5.8.3
Contact Form 7 Signature Addon: version: 4.2.2
Divi Plus: version: 1.9.10
Flamingo: version: 2.4
Plugin Organizer: version: 10.1.10
Post SMTP: version: 2.8.5
Send PDF for Contact Form 7: version: 1.0.1.7
ShortPixel Image Optimizer: version: 5.5.2
Site Kit by Google: version: 1.114.0
TablePress: version: 2.2.3
UpdraftPlus - Backup/Restore: version: 1.23.13
Wonder Grid Gallery Pro: version: 16.6C
Wordfence Security: version: 7.11.0
WP Rocket: version: 3.15.5
Yoast SEO: version: 21.6

Hi
Here is the temp link to the image: https://ibb.co/KwStpCV It’s not showing on the “Add Tracking Info” modal “popup”.

Thanks

• This reply was modified 1 year ago by ernst1234.

Thank you. Implemented – will test and comment here if any issues with this.

Any idea why the “Mark Order as:” is not displaying? As mentioned, even changing the “wc_ast_hide_from_to” option to 0 made no difference. (Not sure that option is the one supposed to control this.) Or perhaps a restart of services is required after changing the option. Would appreciate some insight here.

Also checked the wp_options, and these are the values which may play into this problem:

wc_ast_default_mark_shipped                    | 0
wc_ast_unclude_tracking_info                   | a:19:{i:0;s:1:"1";i:1;s:15:"partial-shipped";i:2;s:16:"updated-tracking";i:3;s:7:"shipped";i:4;s:14:"shippedpartial";s:10:"processing";s:1:"0";s:9:"completed";s:1:"1";s:15:"partial-shipped";s:1:"1";s:16:"updated-tracking";s:1:"1";s:9:"cancelled";s:1:"0";s:7:"on-hold";s:1:"0";s:8:"refunded";s:1:"0";s:6:"failed";s:1:"0";s:24:"show_in_customer_invoice";s:1:"0";s:21:"show_in_customer_note";s:1:"0";s:7:"shipped";s:1:"1";s:14:"shippedpartial";s:1:"1";s:15:"awaitcollection";s:1:"0";s:14:"checkout-draft";s:1:"0";}
wc_ast_show_orders_actions                     | a:16:{i:0;s:1:"1";i:1;s:9:"completed";i:2;s:7:"shipped";i:3;s:14:"shippedpartial";s:10:"processing";s:1:"1";s:9:"completed";s:1:"1";s:15:"partial-shipped";s:1:"0";s:16:"updated-tracking";s:1:"0";s:7:"on-hold";s:1:"0";s:9:"cancelled";s:1:"0";s:8:"refunded";s:1:"0";s:6:"failed";s:1:"0";s:7:"shipped";s:1:"1";s:14:"shippedpartial";s:1:"1";s:15:"awaitcollection";s:1:"0";s:14:"checkout-draft";s:1:"0";}
wc_ast_api_date_format                         | d-m-Y
wc_ast_status_shipped                          | 0
wc_ast_status_delivered                        | 0
wc_ast_hide_tracking_events                    | 2
wc_ast_select_tracking_page_layout             | t_layout_1
wc_ast_link_to_shipping_provider               | 1
wc_ast_hide_tracking_provider_image            | 0
wc_ast_hide_from_to                            | 1
wc_ast_hide_list_mile_tracking                 | 1
wc_ast_remove_trackship_branding               | 1

I did try updating the value of wc_hide_from_to to 0, but that did not cause that “Mark Order as” to display.

<fieldset class="form-field change_order_to_shipped_field">
  <span>Mark order as:</span>
  <ul class="wc-radios">
    <li>
      <label>
<input name="change_order_to_shipped" value="change_order_to_shipped" type="checkbox" class="select short mark_shipped_checkbox" checked>Completed
      </label>
    </li>
  </ul>
</fieldset>

Further info :
The html elements related to “Mark Order as:” still exists on inspection. I doubt I have any css hiding this. So this is probably a script that hides it. You will notice the “Completed” option is checked. That’s why our order status are getting updated to “Completed” when we hit the button.

Hi
Our need is a bit too urgent to wait for feature additions. I’ll have to do this myself.

Just two questions, please, then I’ll go away ?? :

1. Does your plugin trigger TrackShip’s process, e.g. via API? Or do TrackShip’s plugin hook into order status updates and then check db: postmeta for the info it needs?
2. I did find your article on adding tracking info via php: https://docs.zorem.com/docs/ast-pro/developers/adding-tracking-info-to-orders/
   All I want to know here is: Is there any special imports needed before using this code in child theme’s function.php ?

Thank you!

@smashballoonlouis
That’s interesting!
I re-enabled Hummingbird Cache and the problem re-appeared.
We’ll probably be moving to WP-Rocket anyways, so I’ll check if the problem persists after that change. And I’ll report back. We are not in a rush, so it may not be soon. But I’ll remember to update here for other users.

Thanks again.

@smashballoonlouis
Hummingbird cache plugin disabled.
Also hit the “clear cache” before deactivating.
Let me know if anything else is needed.
We are not on a CDN or anything as yet, so there should not be other cache’s except browser caches.

Hi @smashballoonlouis

I thought that had fixed it.
I even found further a further problem that may have been the cause – missing ca-bundle for SSL. That fixed issues on another plugin with https issues.

But the issue is back – it shows the mixed content warning again.

The stack that we are building on does not read .htaccess files in any wordpress directories or subdirectories. Do you make use of custom .htaccess files?

If not, any other ideas? It’s just the cff-avatar.png which has an http request instead of https.

I was starting to look at the code and trying to make sense of where the issue might originate. But I’m not a php guy, so it’s slow-going.

Please see if you can track this down.

Problem solved:

Note: It could well be, that none of the below was necessary to fix the problem for others. The reason might just have been that I had connected to the facebook page source in Facebook Feed Plugin Settings, when our site was still http. And then we moved to https. But either way, the below worked for us.

What I did was edit wp-config.php:
1) Regenerated new salts/keys for the auth section.
2) Added:

define( 'WP_DEBUG', false );
define( 'WP_SITEURL', 'https://YOUR_DOMAIN/' );
define( 'WP_HOME', 'https://YOUR_DOMAIN/' );
define( 'WP_CONTENT_URL', 'https://YOUR_DOMAIN/wp-content');
define(' WP_CONTENT_DIR', '/bitnami/wordpress/wp-content');
define( 'WP_PLUGIN_DIR', '/bitnami/wordpress/wp-content/plugins' );
define( 'PLUGINDIR', 'bitnami/wordpress/wp-content/plugins' );
define( 'WP_PLUGIN_URL', 'https://YOUR_DOMAIN/wp-content/plugins' );

Replace YOUR_DOMAIN with your actual domain.

In other words, explicitly defined the correct urls and directories as there were issues reported of plugins not correctly resolving relative urls in wp-content and sub-directories. Specifically, /opt/bitnami/wordpress/wp-content is sym-linked to /bitnami/wordpress/wp-content, and some plugins experience issues with this.

Note, these definitions of …DIR, are JUST for bitnami and might not hold for future releases of their software even. Check docs and understand your wordpress folder structure. It may not be appropriate in other’s cases.

After the above was done, the Facebook Feed Plugin disconnected from the facebook page source and I just reconnected again in Settings. After the reconnect it worked fine and the mixed content warning/error disappeared.

This might help someone. Thank you.

• This reply was modified 2 years, 4 months ago by ernst1234.
• This reply was modified 2 years, 4 months ago by ernst1234.

Hi Manuel

Thanks for the response.

All settings on my site are https. Specifically “home” and “siteurl” settings. But also all other settings in the db related to url of our site. I doubt there is an http hardcoded in our php or other files.

Look, it must be your code that is referencing that png. And if the reference is relative to siteurl, then it should not give an issue. But it must be enforcing http somehow. Where might it be getting that http url from? If you can tell me specifically how this is picked up, then I’ll try and find it. Otherwise I’ll need to search through your plugin code to locate why it is asking for an http url instead of https.

If you cannot determine this, then it’s OK.

We did recently migrate the site and I guess some issue crept in with this migration causing the above problem.

Thank you

OK, you suggestions got me on the right track. Here is the code I eventually ended up with, which changes the Ultimate Tables, but not the other tables.

.dataTable tbody tr.odd {
background-color: #FF7E00 !important;
}
.dataTable tbody tr.even {
background-color: #FF6400 !important;
}
.dataTable tbody tr:nth-child(even) {
background-color: #FF6400 !important;
}
.dataTable tbody tr:nth-child(odd) {
background-color: #FF7E00 !important;
}
.dataTable tr {
background-color: #000 !important;
}

Could probably work without the tr.odd and tr.even section, but might provide some compatibility for older browsers. Not sure.

Also note, the .dataTable did not work when I had it inside the {}, but when removed there, worked well.

And as you can see I also removed other parts of the code, like the .zebra, which did not seems influence the results visually.

Thanks for the help and I hope this can also help someone else.

Thanks, but now a contact form, which is based in an html table is not working right, the code example:

<table style="width:100%;background-color:transparent">
<tr style="background-color:transparent;height:50px">
<td style = "vertical-align:top;text-align:right">Name & Surname * &#160 &#160</td>
<td style = "vertical-align:top;text-align:left">[text* your-name size:30]</td>
 </tr>
</table>

So if I understand it correctly, the CSS code you gave, with the !important has essentially given the custom CSS styles complete priority over all “tr” objects. Is that right?

Is there a way to change the CSS code you gave to ONLY affect the ULTIMATE TABLES’ tables? Eg

ultimate_table.tr.odd
etc etc

Apologies for the follow up question, but I didn’t know this would affect the other table like this. In fact, the original problem might NOT have been after the ultimate tables update, but rather after the new contact form table.