@rogierlankhorst
I just downloaded the branch you linked above and it seems the issue is PARTLY fixed in that way that any settings I change in the admin are still reverted after saving. So no matter which toggle I switch or width I enter, after Save, it’s back to defaults.
However, those changes ARE visible in the frontend. BUT, and now it gets even more confusing… as each block of settings has its own Save button, the reverted changes in another block are also saved.
TIP: have 1 SAVE button for the whole settings page.
Example: in Categories block, I disable all 3 descriptions, hit Save, page reloads, descriptions are enabled again in admin but invisible in frontend. If I now toggle the Deny button in the Banner Settings and hit Save. The Deny button will indeed be invisible in the frontend BUT the 3 descriptions will be visible again.
This is now the 4th or 5th site I updated to the 6.x version and ALL have issues. If this were the paying version of the plugin, I’d be VERY annoyed.
@puregraphx thanks for reporting the issue in the current beta. The text/checkbox fields reverted to the default if set to false, as a false settings was detected as ‘not filled out’
I have updated the current github beta with the fix, as well as the ‘no condition on column upgrade’ branch.
Thanks for your feedback on the save button: we’ll re-asses this in the 7.0 update, as we’ll be looking at back-end UX in that version. We’ll certainly take your remark into account.
Hi @rogierlankhorst
I just updated one of our client sites to 6.0.1. the issue with the Save button is still there. So changing a settings in Settings Block 1 + Save indeed saves the settings, but then resets to default which means that saving settings in another Settings Block will save the default settings from block 1 + the new settings from the other block. It’s a lose-lose situation as you cannot save All settings in 1 go.
Deleted the plugin with the option to remove all settings and tables. Did a WP Optimize afterwards, reinstalled the plugin. I am still not able to change and save settings in different blocks. I can’t imagine you are going to leave this issue till v 7.0
Hi @puregraphx,
I can’t reproduce the issue you’re describing. The save button is currently saving the entire page, so there’s no difference between the save buttons on the page.
In the debug log, are you still seeing php errors about the row size in the table?
Is the issue related to one specific setting?
I’ve updated the branch which doesn’t include the conditions on upgrading old table columns to the latest version.
https://github.com/Really-Simple-Plugins/complianz-gdpr/tree/No-condition-on-column-conversion-to-text
The current live version checks for the existence of the column ‘popup_background_color’. If it exists, it upgrades the old columns to text. In the conditional branch this check is removed, forcing the upgrade to run always. As I don’t want new, empty sites to get the old columns, this needs to be conditional in the live versions.
Possibly your sites do not include this column because certain versions were skipped. If you can post the columns your cmplz_cookiebanner table lists, I can adjust the check in the live plugin to those columns as well.
I restored a backup to the pre 6.x version, these are the columns I currently have in the DB. I will update to a 6.x later this evening and check columns again and the debug log.
ID int(11) Auto Increment
banner_version int(11)
default int(11)
archived int(11)
title text
position text
theme text
checkbox_style text
revoke text
header text
dismiss text
save_preferences text
view_preferences text
accept_all text
category_functional text
category_all text
category_stats text
category_prefs text
accept text
message_optin text
readmore_optin text
use_categories text
tagmanager_categories text
use_categories_optinstats varchar(255)
hide_revoke int(11)
disable_cookiebanner int(11)
banner_width int(11)
soft_cookiewall int(11)
dismiss_on_scroll int(11)
dismiss_on_timeout int(11)
dismiss_timeout text
accept_informational text
message_optout text
readmore_optout text
readmore_optout_dnsmpi text
readmore_privacy text
readmore_impressum text
use_custom_cookie_css text
custom_css text
statistics text
colorpalette_background text
colorpalette_text text
colorpalette_toggles text
colorpalette_border_radius text
border_width text
colorpalette_button_accept text
colorpalette_button_deny text
colorpalette_button_settings text
buttons_border_radius text
animation text
use_box_shadow int(11)
hide_preview int(11)
@puregraphx indeed the popup_background_color does not exist in your table. So the upgrade does not fire.
I have added an additional condition, which looks at ‘use_categories_optinstats’, which you do have.
It is merged in the current master here:
https://github.com/Really-Simple-Plugins/complianz-gdpr/
Hi @rogierlankhorst
I’ve downloaded the zip from GitHub (6.1.0.1) this seems to have fixed the issue.
I don’t know if anything changed about the columns, but just to be sure I’ll list them below.
Dankjewel,
Warme groeten,
Column Type Comment
ID int(11) Auto Increment
banner_version int(11)
default int(11)
archived int(11)
title text
position text
theme text
checkbox_style text
revoke text
header text
dismiss text
save_preferences text
view_preferences text
accept_all text
category_functional text
category_all text
category_stats text
category_prefs text
accept text
message_optin text
readmore_optin text
use_categories text
tagmanager_categories text
use_categories_optinstats text
hide_revoke int(11)
disable_cookiebanner int(11)
banner_width int(11)
soft_cookiewall int(11)
dismiss_on_scroll int(11)
dismiss_on_timeout int(11)
dismiss_timeout text
accept_informational text
message_optout text
readmore_optout text
readmore_optout_dnsmpi text
readmore_privacy text
readmore_impressum text
use_custom_cookie_css text
custom_css text
statistics text
colorpalette_background text
colorpalette_text text
colorpalette_toggles text
colorpalette_border_radius text
border_width text
colorpalette_button_accept text
colorpalette_button_deny text
colorpalette_button_settings text
buttons_border_radius text
animation text
use_box_shadow int(11)
hide_preview int(11)
popup_background_color text
popup_text_color text
slider_background_color text
button_background_color text
slider_background_color_inactive text
slider_bullet_color text
button_text_color text
accept_all_background_color text
accept_all_border_color text
accept_all_text_color text
functional_background_color text
functional_text_color text
functional_border_color text
border_color text
use_logo text
logo_attachment_id text
close_button text
functional_text text
statistics_text text
statistics_text_anonymous text
preferences_text text
marketing_text text
font_size text
header_footer_shadow int(11)
disable_width_correction int(11)
legal_documents int(11)
Oh, posted too soon.
I can’t set anything else than the default width of the cookie banner. Whatever I set, after the save it’s back to 564px.
In addition to that, even if 400px would be saved properly, the layout of the banner is not 400px, only the Categories block is, title and buttons are still 564px.
https://prnt.sc/26w42kx
The width of the banner also automatically changes when editing the title size
.cmplz-cookiebanner .cmplz-title {font-family:"Montserrat", Sans-serif;font-weight:700;font-size:20px}
After this css, the width jumps to +/- 700px
-
This reply was modified 11 months, 3 weeks ago by
puregraphx.
@puregraphx glad to hear the database issue has been resolved!
What I see in the screenshot, is that the width of the two buttons together, is larger then the 400px. The categories block is 400px, but the two buttons push the banner apart. As a result, Complianz recalculates, and sets the banner width to the width that will fit the two buttons.
You can disable this width auto adjustment in the advanced settings: enable “custom css”, then “disable width auto adjustment”.
To get the banner to 400px without the categories block being smaller, I would recommend to use some custom css to make the button width smaller. For example, lowering the padding, or using shorter texts.
Let me know if that helps!
Isn’t the purpose of responsive design to make the buttons stack on top of each other instead of side by side when there isn’t enough space? I don’t understand why the 2 (or even 3) buttons need to stay side by side no matter what.
Surely making something responsive doesn’t mean you force a certain hierarchy in the buttons. It’s just normal behaviour that when there is not enough space, elements wrap and one button will be on top.
