Forum Replies Created

Viewing 15 replies - 1 through 15 (of 69 total)
  • Thread Starter billseymour

    (@billseymour)

    Thanks for the suggestions Mike. I will try the new Gmail acct idea.

    I realize I forgot to mention this: I am using Google Apps as the email handler for the domain where WP and FSCF are installed (so all emails in/out are redirected to the Gmail acct). I created a valid email account in my domain and was using this as the “from” address – and this worked for at least a year (since the DMARC requirements).

    It occurred to me that things may be getting tangled up because of the referral of email to/from the Google Apps account. Perhaps the services receiving the contact form email are seeing “from” (a domain email) not matching up with the Google Apps referral account.

    (Just FYI, not a criticism but just info for you, Contact Form 7 in tests thus far is not having a problem with this setup)

    I will explore further, and provide feedback on my results. Thanks again. Bill

    @greybird-

    The problem is/was Yahoo’s policy change – this plugin actually was better prepared for that change than almost all of the other plugins.

    Every contact form must deal with the Yahoo (and possibly other email providers) DMARC policy – for my part, you won’t find a more responsive plugin than this one.

    Just found this – very helpful. Thanks.

    This is very troubling to me, because I only happened to run across this today, not realizing that this DMARC thing was going on.

    Is there any way that Mike can ‘push’ some sort of notification to Plugin users, in the event a problem like this crops up? This would be most welcome.

    (update edit) I tried Solution 2, and it works just fine. Since I had already been using a valid return-path email (tied to the domain), simply checking the ENABLE-only box was all that was required.

    Thanks very much for both explaining, Mike, and for having laid out a good plugin even before this DMARC stuff came up.

    Thread Starter billseymour

    (@billseymour)

    Danny-

    Thanks for the response. I will try out your suggestions.

    Re future update: I do think that some (not all) markup would be appropriate for inclusion. Certainly a line break would be helpful. The ability to add a link would also be of value, but I don’t know if that might raise the kind of security issues that require html-stripping in the first place.

    If this helps: I added a new scheme, but needed to modify the admin-color-schemes.php file. In that file, I did two things, both relating to my new scheme (in its own folder: myscheme).

    1. Add myscheme to the private $colors line:

    private $colors = array(
      'vinyard', 'primary', '80s-kid', 'aubergine',
      'cruise', 'flat',  'lawn', 'seashore', 'myscheme'
      );

    2. Add the information for the display of the scheme in WPAdmin:
    (I copied this from another scheme, and changed the colors to match my scheme)

    wp_admin_css_color(
      'myscheme', __( 'My Scheme', 'admin_schemes' ),
      plugins_url( "myscheme/colors$suffix.css", __FILE__ ),
      array( '#e0e0e0', '#404040', '#ff0000', '#606e99' ),
      array( 'base' => '#e0e0e0', 'focus' => '#fff', 'current' => '#fff' )
    );

    Lastly: remember that if you are just modifying the plugin, that any update will wipe out your work. So save your work.

    Thread Starter billseymour

    (@billseymour)

    Addendum: As long as I am making the suggestion, let me add to my wishlist(!): Ability to change text for all the major dialogue boxes, such as the Register message (‘Complete the form…’), Login (‘Enter your…’), etc.

    Default text would be the text now in the plugin.

    I think this would be a very helpful addition that would enhance the plugin. Thanks.

    Thread Starter billseymour

    (@billseymour)

    @david – That is a good idea, as well – it puts the list content out of sight, which would help. On my ‘wishlist’, I would still hope for a separate file, to completely remove offensive (but necessary, of course) material from the WP Admin area.

    Thanks for your quick reply, looking forward to using the Plugin.

    billseymour

    (@billseymour)

    Adding my appreciation for the plugin – it does what it is supposed to do, and no extra clutter.

    A few thoughts on the UI (in Settings>General)

    1. I, along with other posters, think a separate page would be useful. My feeling is that it would be easier for a user to locate the plugin settings. It wouldn’t need any more info than what is currently in the Settings>General area. You could locate it in either Settings, Plugins, or possibly Tools.

    2. When selecting ‘No updates’, the ‘Advanced’ option ‘grays out’. This is confusing (at first, I thought I could not perform settings). Suggest that this NOT be grayed out at any time.

    3. ‘Advanced’ again: suggest you leave ‘Advanced’ Visible at all times. It is not a large section, and always displaying it reminds the user of those options.

    Great work – I can’t imagine running any client ‘production’ sites without disabling automatic updating.

    Thread Starter billseymour

    (@billseymour)

    @Mike-

    OK, thanks for the explanation. Styling works fine doing it on the FS Styles area provided – the important thing is the ability to style it at all, which we are able to do.

    I hadn’t thought about that limitation – when I was styling the Placeholder text directly in my stylesheet, I (like you) had to style each browser/vendor separately.

    Thanks – all works great.

    Go to tab ‘Scheduling’.
    Uncheck: Add a scheduling button to your form

    Personally, it took under 15 minutes to do on a bunch of sites that I manage.

    But I agree with you, it might be best if the Scheduling button default was set to ‘unchecked’. Then there is no disruption to existing sites.

    Thread Starter billseymour

    (@billseymour)

    @Mike-

    Working with v4.0.13, re the styling option for Placeholder text:

    Styling directly on the form (color:red; etc) works just fine.

    However, I find that adding a Class (class=”bfscf-placeholder-text”)for placeholder text does not work.

    Since you support this approach (ie, our entering a new Class that we can style on our own) generally, I’d request that this capability be added for styling the Placeholder Text.

    Excellent work – both the Opacity (earlier Q), and Placeholder for IE8, work fine. Thanks.

    Thread Starter billseymour

    (@billseymour)

    @mike – Terrific. I saw the jamesallardice solution, too, which also looked simple and robust. The fixes sound great. Thanks.

    Thread Starter billseymour

    (@billseymour)

    @Mike- Sure, happy to do so.

    I did ‘belt and suspenders’ in my Css, setting opacity:1 for all the vendor prefixes (probably unnecessary), and using the single-colon for pre-FF19. I also found it useful to put the color in this area, too:

    ::-webkit-input-placeholder { opacity: 1; color: #333333; } /* gray80 */
    :-moz-placeholder           { opacity: 1; color: #333333; } /* Firefox 18- (one color)*/
    ::-moz-placeholder          { opacity: 1; color: #333333; } /* Firefox 19+ (double colons) */
    :-ms-input-placeholder      { opacity: 1; color: #333333; }

    Site link using this Css:
    https://www.creativeretro.com/contact-me

    Hope that is of some help.

    Thread Starter billseymour

    (@billseymour)

    @Mike-
    OK, good to know – I am using FSContact successfully right now, with the jQ fix for ie8/9 mentioned above. Thanks for your continued efforts.

Viewing 15 replies - 1 through 15 (of 69 total)