Felipe Figueroa

@skywalamedia If you don’t mind repeating the following step on each of your products, the simplest way it’s to add a style element right after your submit field. Your form would end with something like:

[acceptance Consent-6 ] <span style="font-size:65%;color:#F5F5F5"> I accept the </span> <a href="/terms-and-conditions/" target="_blank" rel="noopener"> terms & conditions</a> <span style="font-size:65%;color:#F5F5F5"> and </span> <a href="/privacy-policy/" target="_blank" rel="noopener"> privacy policy </a><span style="font-size:65%;color:#F5F5F5">*</span> [/acceptance]

[submit "Send me the Template"]

<style>
  .wpcf7 .wpcf7-form-control-wrap .wpcf7-form-control.wpcf7-acceptance {
      background-color:inherit !important;
  }
</style>

Oficially, style tags belong to the document’s head and also this fix is a tad inneficient, having to copy and paste this style on every form. But if you’re not accustomed to tweak your themes and plugins yourself, then by all means play it safe.

• This reply was modified 2 years, 6 months ago by Felipe Figueroa.

@erickaburu you’re using the same plugin as @boehmbernd. It’s sending the date with format DD/MM/YYYY verbatim, which is invalid.

Nowadays, every browser has support for date, time and even combined datetime inputs, and CF7 too, accordingly. Use those field types and let the browser do its job.

If you insist in using a plugin, due to an aesthetical consideration, by all means look for a plugin that delegates to modern datepickers (e.g. pickaday or flatpickr). jQueryUI datepicker widget has been obsolete for almost a decade now.

• This reply was modified 2 years, 6 months ago by Felipe Figueroa.

@boehmbernd in your case, the invalid input is the date field. This is what comes in response to the pre-validation

{
    "contact_form_id": 687,
    "status": "validation_failed",
    "message": "Ein oder mehrere Felder sind fehlerhaft. Bitte überprüfe sie und versuche es noch einmal.",
    "invalid_fields": [
        {
            "field": "your-date",
            "message": "Das Datumsformat ist ungültig.",
            "idref": null,
            "error_id": "wpcf7-f687-p688-o1-ve-your-date"
        }
    ],
    "posted_data_hash": "",
    "into": "#wpcf7-f687-p688-o1"
}

So I’d say in your case the culprit is Contact Form 7 datepicker. I wouldn’t know which specific datepicker plugin do you use, but current browsers, all of them, have native support for date inputs with nice datepicker controls.

CF7 also supports date inputs natively.

However, please note that, as per the HTML5 standard, the visitor is presented with his own locale format, but internally the browser send the value formatted as per ISO-8601, YYYY-MM-DD. Your plugin, instead, sends the displayed format DD.MM.YYYY verbatim. My suggestion is: deactivate that plugin and replace the input with a date field.

Ref: MDN’s documentation:

Note: The displayed date format will differ from the actual value — the displayed date is formatted based on the locale of the user’s browser, but the parsed value is always formatted yyyy-mm-dd.

@skywalamedia it seems the only inconvenient would be the consent form control group showing up with a light gray background.

This is caused by a stylesheet rule that declares:

.elementor-6148 .elementor-element.elementor-element-4878ae0 .wpcf7 .wpcf7-form-control:not(.wpcf7-submit):not(.wpcf7-checkbox):not(.wpcf7-radio) {
    background-color: #FFFFFF;
    font-family: var( --e-global-typography-text-font-family ), Sans-serif;
    font-size: var( --e-global-typography-text-font-size );
    font-weight: var( --e-global-typography-text-font-weight );
    text-transform: var( --e-global-typography-text-text-transform );
    font-style: var( --e-global-typography-text-font-style );
    line-height: var( --e-global-typography-text-line-height );
    border-radius: 10px 10px 10px 10px;
    padding: 0px 0px 0px 0px;
    margin: 0px 0px 0px 0px;
}

This is roughly the same as a rule declaring:

.wpcf7 .wpcf7-form-control:not(.wpcf7-submit):not(.wpcf7-checkbox):not(.wpcf7-radio) {
    background-color: #FFFFFF;
    border-radius: 10px 10px 10px 10px;
    padding: 0px 0px 0px 0px;
    margin: 0px 0px 0px 0px;
}

This rule provides clear background and rounded corners for your text fields. It avoids styling control groups whose selector relates to submit buttons, checkboxes or radio fields. It would, therefore, affect the style of other kinds of control groups such as a .wpcf7-textarea or .wpcf7-select. It is, right now, affecting your .wpcf7-acceptance group.

If you know where to edit said rule to exclude acceptance:

.wpcf7 .wpcf7-form-control:not(.wpcf7-submit):not(.wpcf7-checkbox):not(.wpcf7-radio):not(.wpcf7-acceptance)

that would be the shortest route. Otherwise, you can always target the acceptance group explicitly right in your contact form

.wpcf7 .wpcf7-form-control-wrap .wpcf7-form-control.wpcf7-acceptance {
    background-color:inherit !important;
}

If you do the latter, you’d have to do it in every form.

Having that part sorted out, you can restore the white text for the consent description.

This tag:

[checkbox* Consent-6 use_label_element " "]

generates an empty checkbox:

<input type="checkbox" name="Consent-6[]" value="">

The checked state of a checkbox defines if it’s going to be sent. The value is what’s actually sent. RFC1378 doesn’t have an encoding for an empty string.

Just use the acceptance input type

[acceptance Consent-6 ] <span style="..."> I accept etc </span> [/acceptance]

• This reply was modified 2 years, 6 months ago by Felipe Figueroa.
• This reply was modified 2 years, 6 months ago by Felipe Figueroa.

The latest version allowed me to select all the ones up to where I srolled and scrolled X 20, then deselect the ones that aren’t post related but statics I still use.

It’s nice

Nice, I was wondering if that feature had been removed (bc it’s depicted on a screenshot of an earlier (?) version).

It would be nice to have it since I’m looking forward to optimize a woocommerce site that has a huge amount of orphaned images from old product catalogs.

I’ve modified the plugin to work that way. I’ll submit my mod to the author.

Meanwhile, you can enable internal importing by locating the line

if ($s != substr($uri, 0, strlen($s))

(it’s part of the function externimg_get_img_tags)

and replace it with

$internaluploads = wp_upload_dir();
if (stripos($uri,$internaluploads[‘baseurl’])===false || $s != substr($uri, 0, strlen($s))

Thing is: our APP machines mount the blog folders from a read only NFS volume, in which the /up folder is NFS mounted to a writable volume.

I could mount w3tc folder on that writable volume too, but I’d won’t be able to update configuration files nor create any of the php scripts that must be copied to /wp-content dir. I wouldn’t mount the whole /wp-content dir in the writable volume either, because it’s purpose is prevent an unauthorized modification of the files.

I’ve rewriten most settings to run on /up but I’m not sure if it’s actually working. I’ve got front, db and obj caching and the html reads:

<!– Performance optimized by W3 Total Cache. Learn more: https://www.w3-edge.com/wordpress-plugins/

Object Caching 0/0 objects using memcached

Now I’m not sure if it’s actually not working or just not appending the stats to the html. Most hits are coming through 127.0.0.1 instead of visitor’s IP so I’m pretty sure something is happening.

try
/(.*)lonliness(.*)
to
/$1loneliness$2

I worked my path through the constants and the file generation that take place when activationg the plugin. I moved all the files to the NFS mounted folder, for it’s the only one with 755 permissions.

The problem is that these minify files aren’t executable nor rewrittable, because the static machine has no PHP and uses nginx as webserver. I ended up disabling the minify option which was one of the main features I wanted to see.

I’ll keep working on the issue. Perhaps object-cache.php, db.php and advanced-cache.php don’t need to get duped onto the WP-CONTENT folder (in my case, the constant is WP-BZ-DIR which is /up (the NFS mounted one).

Ok, let’s disregard that 777 and say 755. In our production environment, everyting but /up is 644.

BTW, I didn’t erase anything. It was just DB caché returning an empty result.

I’m using nginx as a webserver, varnish as a client side proxy, memcached as a server side cache mechanism and now W3TC to take advantage of it all.. but now I’m afraid I’ll have to drop varnish, which I wouldn’t like to.

Hmmm I can’t seem to get it to work. I’ve tried changing define.php to define the following:

define(‘WP_CONTENT_DIR_NAME’, get_option(‘upload_path’));

but all I get is a blank screen.

I can get the constant defined before, right in w3-total-cache.php, but it doesn’t stick, the constant remains empty during plugin’s runtime.

Aye, and I should mount the wp-content/w3tc folder on with NFS pointing to the static server.

Either that, or I should tamper with the plugin code to use the same folder as the images