boutiquelife

Hello again,

Happier to report that admin, recently and for a time previously, login email reports are again more regularly reporting admin logins and even within short and shorter periods of, logout then login back-in, time .

The bacon, it seems, is no longer in hiding .

We are aware of how much cache flushing we have manually executed lately and acknowledge that litespeed cache may indeed be in some way responsible for the, previously, delayed or non-existent admin login email reports . If the situation recurs then we will not badger you again but manage the cache fully and have patience before making any new or additional thread update to you .

Thank you .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

Hello again,

Well nope . . no new attacks today . . while todays WF attack report does show the previous days attacks which matches yesterday’s WF attack report content .

Otherwise nothing new or else to report .

Gonna go figure .

And thank you for your assist .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

Hello,

Thank you for your last .

Update . .

We confirm the WF settings for AFW and ‘Rate Limiting’ described by you are and were already configured, thank you .

A most recent change to a specific Wordfence file is documented and reported by the, daily, back-up service in-use at our domain, and for June 3 .

/wp-content/wflogs/attack-data.php

Browsing recent back-up reports shows that file to being less commonly changed (i.e. we are without any record of any previous change going back a ways And we are able to make a deeper dive, on your request, to confirm any change dates for the file attack-data.php over the period, e.g., since May 17) .

That back-up service change notification (June 3) is, immediately, followed by the latest daily WF attack report (June 3) showing fresh, repeated, attacks from a usual and previously detailed, to us, bad actor origination (Ukraine / UA) .

The immediately previous, June 2, and earlier until May 17 ~ as mentioned in the above posts ~ daily WF attack report shows no attack(s) . Yet earlier, daily WF attack reports, than May 17 consistently delivered several many attacks each and every day .

We will report again if new and additional attack data, again, appear(s) on the incoming daily WF attack reports . . seemingly indicating a return to usual behaviour, for whatever reason(s) .

Thank you .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

Hello,

Thank you for your inquiring assist .

Our apology for the delayed response .

We have, just, executed your instructions .

We report that you are correct and that we indeed have the proper info in the proper panels of the daily activity report sent to our usual receiving email address .

And that new info is also showing in the (administrator back-end) plugin Wordfence Firewall option, and dashboard widget, information panels too .

So we, confidently, deduce that Wordfence is continuing to operate normally and within established parameters .

And so we are wondering where the larger share is of the attack blocking data currently unreported .

Thank you for your successful guidance to date .

We, patiently, await your further advice .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

Thank you for your response .

We have aligned DEV and LIVE plugins (activated) to be sure we are consistent in our comparisons . . yet DEV trolls along with perfection even after that Woo 3.3 upgrade . And we have, again, ourselves this third-time, run the battery of obvious eliminations including disabling ALL plugins except Woo (and then Woo too) and changing to Storefront theme . . But without any improvement . We observe that, e.g., Woo products tabulated display is perfect (in DEV and LIVE) .

Our time-table means that we shall allow for the non-pernicious, persistent, visual display-only anomaly . . until we do stumble upon any, redeeming, remedy or solution . . which we will, surely, share with you .

We should mention that whatever we may have done is exclusive to LIVE, somehow someway, yet undiscoverable, for now . And we clarify that DEV is the copy of LIVE and that lIVE is the originally built domain then copied to DEV (sub-domain / add-on domain) and thus forever separated as individual maintainable operating installs .

Thank you for the link to Woo custom services .

While this ‘experience, slowly does my head in . . we do continue ‘sacking’ our minds and racking our brains for anything and everything potentially causing the described operating visual abnormality, so far, missed by us .

We will keep everyone participating and responsible (concerned) in the loop as we wade through the thick of it . . expecting clearer, calmer, waters into our Woo operating future .

So shall we see .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart :-}

Hello John,

Thank you for your response .

We have, again, addressed the issue described, most recently, with the able assist from our web-site hosting provider . And they report a console ‘error’ which shows an additional coding instruction (‘hidden’) inserted in the relevant line of html that is the exact cause of the misalignment . Removing that additional coding instruction (‘hidden’) returns the tabulated display back to normal . Imagery attached for Chrome and Firefox web-browsers . Still we are, for now, entirely unclear why this happens . We recall that our experience began immediately after the Woo 3.3 upgrade . Yet we acknowledge that our DEV install is five-by-five using the exact same hosting infrastructure as the LIVE install and blah . Because our hosting provider completed the same process as we and arrived at the conclusion that cache or caching is not the problem and are happy enough to continue with any assists we may ask . Yet even they are asking if we have used any code (in the back-end) that might be ‘patient zero’ .

So, yes, we do have an ‘error’ in the ‘console’ .
Maybe this helps some or at least you are able to offer some, more permanent, workaround .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely
Stuart .

PS. Here’s the link, again, to the fresh imagery which is included with the previously provided imagery for convenience (https://drive.google.com/drive/folders/1fHZ9GMleACC7CTBU6ASjhQzHq4hvgr_M?usp=sharing ) .

. . daily (as always set by us) email activity report incoming as usual, again, thanking you . . since version 7.1.1 . . while admin log-in alert is timely for the initial admin-log in too, thank you . . But after admin logout and log-in again the email alerts from DEV and LIVE are MIA . . and since we are paying closer attention to the process, we may have forgotten whether that is normal operating procedure to not send another admin log-in alert so soon after the last . . But we have a doubt . . and imagine that every log-in should instigate a log-in email confirmation to the configured receiving email account (Gmail.com) which is not suddenly throwing the emails under another email account tab and admin log-in alerts are not to be found in spam . . sooo . . things have improved, thank you, and any missing admin re-log-in email alert may not be cause for concern or it may be cause for concern since consistency (of email log-in alert receipt) is how we are thinking you choose to roll . . double-checking the settings in Wordfence options shows that we are indeed expecting an email ‘heads-up’ every-time an admin and non-admin user log-in and without any restrictions . . and getting none from DEV and from lIVE installs (which is darkly encouraging symmetry) . . nothing then since the initial DEV and LIVE installs log-ins, today . . who is hiding the bacon ? . .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

Thank you . . But no and nope . . all plugins disabled (except WooCommerce), cache purged, storefont theme active . . and (back-end) misaligning orders table and data persists . . Attempted several iterations of all plugins deactivated and existing shopkeeper theme active then storefront theme active then permanently deleting all orders and creating new (front-end) order while storefront theme active and blah blah blah . . because this ain’t the solution we’re looking for . . and, recall, that DEV install is five-by-five with same plugins and theme and hosting infrastructure . . and all plugins are 100% up-to-date (WooCommerce 3.3.4) . . if you are looking closer then you are aware the difference between the DEV and LIVE orders table display is stark (linkage previously offered among the above comms) because the LIVE table is missing the lhs square checkbox beside “Order” on the column titles row and missing altogether as a row when all WP screen display options are unchecked and you can see the additional horizontal spacing added when only the orders display option is checked (same in DEV except DEV shows the horizontal thin grey-divider-line streaking all the way across to the table end But not so on the LIVE install where it extends only as more table display columns are checked and ends before under Actions and well before the vertical table edge ~ thus are we soaked in misalignment) . . and how does changing a theme unfix that and how does front-end ordering/reordering fix that and how does purging the database of all orders (not yet LIVE still final testing) fix that . . Surely this begins (and ends?) with the Order column since choosing only orders to show in the WP pull-down for that admin screen is revealing enough that things are yackadackadack . . You have the bridge and the comms . .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely
Stuart .

P.S. we also disabled all Chrome web-browser extensions . . no change . . as expected because the DEV install Woo orders table display is okey-dokey .

Hmmm . . yup, we too are most recently (since March 5 to be exact) experiencing a lack of email delivery from Wordfence (7.1.0) for, specifically, the Wordfence (domain) activity report, which still delivers, immediately, if tested . . And, we too, have two separate installs of WordPress (4.9.4) upon the exact same hosting infra-structure provider and with almost exact same plugins and site-wide configurations, since one, install, is Dev (add-on sub-domain) and the other, install, is Production . . Ain’t got no, visible or observable, explanation for the sudden email MIA . . true, all other Wordfence emails are sending and receiving according to normal established operating parameters . . Well almost true, the Production install admin login alert email is tardy and that is also new behaviour, but arrival is continually consistent, for now (but is noticeably slower than the DEV equivalent admin login alert email) . . The offending install is the Production install while the Dev install is five-by-five (and so we, also, miss the, as yet unattended, reminders to upgrade any relevant plugins) . . Yes, the hosting service provider includes litespeed cache (litespeedtech.com) and we double-down with cloudflare (cloudflare.com), no WP cloudflare plugin on the Production install since largely unnecessary and the cPanel cloudflare option is available, for both installs) in the event of drama as well as the cloudflare dashboard (for both installs) at coudflare.com, but cloudflare plugin install on the DEV install (because DEV), meaning any change to the cloudfare settings affects both installs because cloudflare sees and shows the installs under a single account interface, because both, separate installs, belong to the same hosting account (probably overshare by moi, right there) . . We are aware that Wordfence is “self-aware” since when installing the DEV WP install, after the Production install which was long operating five-by-five, we discovered Wordfence visually intercepting (preventing) some back-end manual changes to the fresh WP install, yet no linkage, between installs, exists, and no install of Wordfence, then, existed in the fresh WP install . . that was a LoL . . We also deliberately changed, previously, the cookie_user for the litespeed cache to keep all caching separate between WP installs . . go figure . . anyways, that does mean we have two installs of Wordfence, one each for DEV and Production and up until March 5, everything was five-by-five, for both installs, and then ~ this . . the described change is, seemingly, unaffected by cache plugin software updates since no changes have been, or are able to be, made by us but are, only, able to be made by the hosting service provider who does upgrade the litespeed cache plugin software from time to time, and chooses to remain some iterations behind the bleeding edge, since, likely, all hosted accounts are similarly benefitted from any litespeed cache upgrade . . meaning the DEV install should likely be similarly affected, yet is not . . sigh . . ’cause i’m a feelin’ a deactivate all plugin moment is comin’ on . . and i’m a reluctant participant in the deactivate all plugins routine . . so here’s the diagnostics data (https://drive.google.com/open?id=1B2o0TCMutTQXvG4_lH4r5yPyXtC4rHet) . . DEV and Production . . error logs report nothing for March 2018 . .

Hopefully, we are chiming-in on the correct thread . .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

Fixed :-} Thank You.
Yoast SEO 7.0.2.

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely,
Stuart .

#metoo . . WooCommerce Product Category SEO by Yoast is absent (MIA) since Yoast SEO 7 and 7.0.1 . . otherwise fine upgrade . . appreciate the plainer language plugin menu navigation . . more understandable . . WordPress 4.9.4 / WooCommerce 3.3.3 / Yoast SEO 7.0.1 / ShopKeeper theme 2.4.7 (Child in-use) . . anything else ? . . Imagery linked showing the mentioned difference between Yoast 6.3.1 and Yoast 7 (https://drive.google.com/open?id=1q_PDhqmaS6phfcSKwn7y3jdvnM3kOBfO) . . Also got SEO stuck in the shell which needs an update but, for now, no admin access way to amend . . What are we, simply, missing here ? . . Or are we confused and in need of clarity ? . . Anyone ? . .

Mean-time and for now,
Much appreciated . . much obliged . .
Yours sincerely
Stuart .

PS. Previously reported (1 day ago) directly to Yoast at yoast.com by way of, seemingly, relevant and related Yoast published post with negative feedback and linked imagery (post just update March 6 2018 and still no useful solution). And since Yoast SEO 7.0.1 ain’t no fix we gonna prosecute this here wrinkle in our perfect SEO right here wit cha .

PPS. Yup and yes, we can also confirm that any WooCommerce product category update is impossible in admin because the update button is MIA too . Yikes .
(switch off Yoast Meta SEO for Product Category, and save, to again have admin update / delete button access But without any SEO box below)

PPS. Yup and yes, we can further confirm that any WordPress category update is impossible in admin because the update button is MIA as well . Yikes !
(switch off Yoast Meta SEO for Category, and save, to again have admin update / delete button access But without any SEO box below)

And in these here admin screens mentioned above are the standard WordPress “Screen Options” pull-down tab (top right) which do not respond to any clicky click click . Yikes !!
(switching off Yoast Meta SEO for Product Category and Category, and saving, will, also, again allow “Screen Options” pull-down menu But of little use when looking for SEO option since we gone done switched SEO off to get pull-down functionality again – catching my 22?)

Bumpity bump bump . . if you please . .