Forum Replies Created

Viewing 15 replies - 1 through 15 (of 21 total)
  • You’re not obligated to free support, especially when it’s not the author’s problem.

    The CSS which causes the “optical error” isn’t from Contact Form 7, but from your theme’s CSS. It adds 30px of margin below every input.

    Spamming and asking for an email is not the right thing to do, as that is borderline harassment.

    You mention “AutoSSL” so I’m assuming you’re using WHM/cPanel on your dedicated server. This is more of a question for them (cPanel support) at this point, but I can try and walk you through some troubleshooting real quickly…

    A. Check your Firewall rules within WHM. I don’t know what particular firewall option you’re using, but your ISP should know. Ask them to see if there’s anything in there that would be blocking connections to WordPress.
    B. Check any weird DNS settings. I don’t see why this would be a problem but doesn’t hurt to see if your DNS resolver has some really weird configuration.
    C. Update your server’s kernel and/or WHM version — a really outdated version of OpenSSL (which is not a part of WordPress at all, but rather a part of your server itself) can cause some issues like this. When you update your kernel in WHM, it should update all the packages with it, including OpenSSL. You can test if this is the problem by doing the same command that Steven provided earlier, but replace https with http. It should connect this time, but respond with a 301 response if it is a problem with your server’s OpenSSL/TLS version.

    Domain management isn’t done within WordPress itself, as WordPress is for managing your site’s content and appearance.

    You’ll need to find where the domain is registered, and modify the DNS there. WordPress.org doesn’t register domains nor host nameservers.

    Ideally, you shouldn’t need to, but it may be worth a try to see if it solves it. Most feedreaders (Bloglovin included) if given the base URL try and find the RSS feed from that URL. It may not be able to find the feed for some reason, so perhaps a direct feed link can solve it.

    I’m able to view and use your RSS just fine, by adding /feed to the end of your site’s URL. Is there a particular feed reader you use and are having problems with?

    Are you viewing the admin page via https or http? I wonder if there could be some mixed content that is being blocked by your browser (the CSS, for example).

    If you currently have an SSL certificate for this particular domain, try adding the following to your wp-config.php:

    
    define('FORCE_SSL_LOGIN', true);
    define('FORCE_SSL_ADMIN', true);
    

    If that isn’t the issue, there could be some script concatenation issues or something else entirely. Try the following next (the second will display some debugging information on script loading):

    
    define( 'CONCATENATE_SCRIPTS', false );
    define( 'SCRIPT_DEBUG', true );
    
    • This reply was modified 1 year, 3 months ago by Laken Hafner.

    It sounds like you may have mis-configured filesystem permissions. If permissions are configured correctly, the user wouldn’t even have to enter their FTP credentials.

    This page may help you out: https://codex.wordpress.org/Changing_File_Permissions

    I can imagine how difficult it is to use WordFence right now with a screen-reader, just by looking at the source, it doesn’t even look possible. 🙁

    I didn’t do a full audit like I normally do when looking for accessibility problems, all I did was quick glance at a single checkbox’s source. There are probably a substantial amount of problems, unfortunately, and will take quite a bit of time to fix.

    This is why it’s so important to think of accessibility problems when building stuff. Did nobody even try to use a keyboard when building the new update? Some of it isn’t even accessibility – it’s valid HTML issues. I understand that people tend to just ignore the W3C guidelines, but they exist for a reason. It’s what any sort of web browsing tool uses to base how it functions. The way you do things may work fine visually, but to a program that parses webpages, invalid HTML doesn’t always work fine. This goes beyond just assistive technologies too.

    I decided to take a look to see what the problem was, and it is pretty bad…

    The “checkboxes” are <li> elements, and when checked, it adds an icon inside the <li> element. That icon has aria, but the absolute most unhelpful aria, aria-hidden. If it wasn’t hidden, and at least had a label of checked, that would be a huge improvement, but still barely usable for screen-reader users.

    The lack of label elements is really bad too, every input needs a label. If it’s not an actual input element, you need to add an aria-label.

    In addition, all the controls need to be able to be modified using the keyboard. This isn’t the case now. The keyboard part doesn’t just affect people who use screen-readers, but also people who use no assistive technology at all. I know quite a few people who use almost exclusively the keyboard in the WordPress admin, just to do things faster.

    @wfsupport – is there any way for external contributors to contribute upstream? I would really like to see this fixed. WordFence is one of the most popular WordPress plugins, and it’s concerning that it’s not even close to being at WCAG 2.0 A-level, when all of WordPress is at WCAG 2.0 AA-level.

    No problem, glad I could help 🙂

    I haven’t had the best luck trying to fix site URLs with functions.php or my wp-config.php file either, so I always resort to the database. Modifying the database can be pretty scary the first few times, but at least with PHPMyAdmin, it’s really simple to create and import backups. So as long as you download your database before messing with it, it usually turns out ok 🙂

    What gets really scary is when you start needing to craft custom SQL queries to bulk replace stuff.. that can go bad really quickly 😉

    It appears that you’ve changed your WordPress site’s URL to example.com

    You probably copy/pasted an example or something similar that used example.com as a placeholder. Site URLs are defined in either functions.php or in your database’s wp_options table

    • This reply was modified 1 year, 7 months ago by Laken Hafner.

    Hi jeanneleez. I know this can be frustrating, especially when your livelihood depends on your site, like you mentioned.

    Try to follow the steps found here: https://codex.wordpress.org/Common_WordPress_Errors#The_White_Screen_of_Death

    If you log into FTP and rename the plugins folder, it will deactivate every plugin. This might solve the problem, and if not, that page has some more steps you can try.

    • This reply was modified 1 year, 7 months ago by Laken Hafner.

    The readme file isn’t meant for the visitor of your site, but rather for the developers of your site. Readme files should explain what the plugin/theme does, any weird quirks with installation, and where to go for support/documentation. This isn’t very relevant to the user, but to the developer (who has filesystem access via SSH/SFTP/FTP), it’s very helpful.

    My hunch is also that a theme file was modified. It seems to be just after the header, so be sure to check page.php, archive.php, etc. for ad codes.

    WordPress hackers are quite tricky. The obviously malicious files (the ones that your host found, and you removed) are able to be removed without removing the infection. The hackers plant various “backdoors” on your site, usually in multiple places, which allow them to reinfect your site. Restoring from backup is probably your best solution. If possible, I’d even try and go a bit further back than Feb 1st, because a lot of hackers like to let the site with backdoors added “sit” for a period of time, before doing an obvious detectable hack.

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