don_alejandro

It’s line 80 of install.php: dbDelta( $sql_create_tables );

The UNIQUE KEY (id) part is in the CREATE TABLE sql specified in $sql_create_tables.

fwiw, the error message only shows up once, on the first page I load after updating from 2.5.0 to 2.5.1. When I look at the database table definition, it’s correct (I’ve had SpeakOut installed a few years and suspect the id field has always been defined as a UNIQUE KEY.

I think there may be a glitch with WordPress’s dbdelta function. I recall noticing a similar hiccup with dbdelta associated with defining a PRIMARY KEY a few years ago while working on a custom plugin – dedelta burped even when no changes were actually being made to the table structure.

I remember mucking about with syntax, ending up with
PRIMARY KEY (term_id)
and
PRIMARY KEY (link_id,term_id)

in the CREATE TABLE sql instead of using the quote-like things that seemed to be correct from the docs
PRIMARY KEY (link_id,`term_id’)

To be honest, I can’t recall for sure whether the syntax tweak fixed the dbdelta gitch or if I simply ignored the rare one-time after update error (since the database appeared to be updated correctly)…

Yes – I just added the if clause on my development server and it works okay.

Thanks – that looks like a good solution

CiviCRM a fairly massive constituency relationship management (CRM) system that runs on various content management systems, including WordPress.

https://civicrm.org/

Various downloads are here: https://civicrm.org/download

I think the thing that changed is that WordPress now issues an error message – previously there would have been no message even when an editor-style.css file fails to load completely for some reason.

The most likely case is that there is a minor error in your theme (or child theme if one is in use) which was not previously flagged, and which didn’t produce noticeable effects…

I just tracked down the cause of a persistent “Failed to load content css:” error, where the file it supposedly failed to load was the editor-style.css file from a child theme folder. But, I am running the same theme and child theme on 10 different websites, and only one of them was issuing an error message, so it’s not a theme problem, though the site with the problem was the only site on a particular host. But, I have a testing server on which I can run copies of all ten websites, and they all worked fine on my testing server except for the same site.

After reading https://www.ads-software.com/support/topic/read-this-first-wordpress-4-8-master-list/#post-9221234 I looked closely and discovered a typo in an @import() line of the editor-style.css file and fixed it. But the WordPress editor was still kept throwing the error, even when I totally eliminated the @import() line from the editor-style.css file. Naturally, I was doing what I thought were ‘hard refreshes’ when testing, but, if the editor-style.css file was present in my child theme, then the WordPress editor always issued the failure to load warning message, even if the editor-style.css file was totally blank. I even replaced all WordPress, theme, and child theme files on the bad site from a working site on my testing server, but still the warning persisted.

Curiously, I could see from looking at the editor window that the editor appeared to be using styles from the file for which I was receiving the failure to load warning, which I verified by using an element inspector. I tweaked some of the styles, and reloaded the editor window to determine whether the editor was stuck using a cached version of editor-style.css, which it apparently was – none of my style tweaks showed up, even after a hard refresh.

At this point I tried opening an edit window with Firefox instead of Chrome and did not get an error message. I went back to chrome, and confirmed that I was still seeing an error even after more hard refreshes.

Apparently a hard refresh (control refresh) doesn’t force Chrome to reload css files, so I used ‘more tools’ – ‘Clear browsing data’ from chome’s menu to clear ‘Cached image and files.’ After doing that I no longer see a warning message using Chrome.

The upshot is that if you have ever had a typo problem that caused the WordPress editor to issue a warning about failing to load a css file, the warning may be the result of a typo rather than the file actually failing to load from the server. Apparently Chrome aggressively caches css files, so just fixing typos will not correct the problem until you aggressively clear Chrome’s cache (or the cache of whatever web browser you are using…).

Thanks for the update, but I’ve had a consistent glitch in updating the lcp plugin.

I updated three live sites and three sites on my testing server, and each time the ‘update’ killed the plugin – WordPress deactivated due to an error or, if the plugin was deactivated when I applied the update, attempting to activate it after the update produced an error message something like ‘no plugin file’.

In all six cases I deleted the lcp plugin (and files), and reinstalled a fresh copy from the ‘add new’ plugin menu, which worked perfectly (and resolved the constructor deprecation warnings). Could the ‘update’ version be missing something?

My guess is that the WordPress 4.1 update (or one of the 4.nn updates) causes something to interact badly with GDE if the image_default_link_type is blank and WP_DEBUG is true (the 4.1 update seems to have changed several aspects of how images are handled).

The issue is probably not affecting any live sites (since WP_DEBUG would be false), and new sites running on testing servers won’t be affected because WP now sets default values. The only reason I noticed is that I was working on my testing server developing custom shortcodes for an older site.

I suppose you could pre-emptively check image_default_link_type and set it if it is blank, but I’m thinking this issue may be something that should ultimately be fixed in WordPress, especially if WP requires non-blank settings to work properly (i.e., the WordPress update could set defaults to the proper value if they are blank).

I may take the time to ferret out a list of options that are now set to specific values and write a query to set them if they are blank (who knows what other odd interactions might happen if WP expects non-blank values)…

The SQL error is happening once per day, the first time I view my site. perhaps triggered by my being the first non-robot visitor of the day, or the first logged-in visitor (admin).

The error is in line 692 of trackthatstat.php:

…,page_id=\””.$post_id.”\”browser=\””.$browser_os_info…

There should be a comma before browser= to separate the field in the SQL statement:

…,page_id=\””.$post_id.”\”,browser=\””.$browser_os_info…