I ran into the following issue when using self-hosted video posts on Kalium:
I chose to use self-hosted videos partly to avoid third-party dependencies - but mainly to comply with GDPR regulations. I do not want to use any cookies on my page (that I have no use for anyways), thus making it unnecessary to bother my visitors for cookie consent.
Unfortunately, even when using self-hosted video, Youtube APIs are referenced in the <head> segment of the page:
The API calls result in cookies being set by Youtube (cf. screenshot attached) - which would require me to request visitor's consent after all. For cookies that I neither want nor have use for - and that have no business being there in the first place, since I do in no way use or reference Youtube content or services.
The issue occurs on my blog post - but it is just the same on your demo page, so unfortunately it seems unrelated to my personal server or Wordpress setup, I'm afraid.
My hope is that this is a bug or mere oversight resulting in Youtube code being inserted into the page even when using only self-hosted video - and that it may be easily fixed once your DEV-team becomes aware of it.
Please let me know if you can help - or forward the information to the right people. Feel free to reach out for further information, if required. Thanks!
thank you for the feedback and advice. I will not use any Youtube hosted content on my site, so I will try to follow your suggestion.
Can you tell me where to enter or execute the code you provided? Is it possible to disable it globally for the whole site? Sorry - I have a rather limited knowledge of HTML/CSS/SASS - but WP is new to me and PHP alien territory. ;) Thanks!
Just updated successfully to 3.0 - thanks for the great work, by the way!
Something I just noticed about the new sticky header:
Before (2.9.4.), I used custom page style CSS to modify logo color for "over the content" header position: white text on dark featured images (initial) turned to black text on minimised sticky header with white background (on scroll).
Both states could be easily differentiated via presence/absence of ".sticky-above" class.
In 3.0, the class ".site-header--sticky-active-style" is introduced once the transition to minimised sticky header with background is completed - so the color change from white > black is no problem.
Unfortunately, said class is not removed if the page is scrolled up again into initial position. Consequently, the text remains black and is not legible on dark featured images.
Ideally, both states should be distinguishable again - and a class that is added upon transition completion should be removed if the transition is reversed back to initial state.
Let me know what you think. Also, if I should rather open a new ticket for this. Thanks!
Sorry for the delay of reply as we were buzzed with support tickets after 3.0 because of significant changes made on the theme.
For the code I gave you, you can put it in functions.php of the theme (kalium-child/functions.php or kalium/functions.php).
As for sticky header, you are right, that is something that will help users determine the state of the header and apply their own styling based on current scroll state.
I have modified the StickyHeader library code and added support for these classes:
As soon as header hits sticky mode:
site-header--sticky-active
After header hits sticky mode and style is fully applied:
site-header--sticky-fully-active
So this might help you I hope.
To apply this on your site here are the files for you to replace in the theme before we release update 3.0.1 which will contain them by default:
1. Download this file and replace it in this directory (of the theme): /wp-content/themes/kalium/includes/functions/
2. Download this file and replace it in this directory (of the theme): /wp-content/themes/kalium/includes/functions/
3. Download this file, extract and replace the JS file (.js) in this directory: /wp-content/themes/kalium/assets/js/
If you don't see the change immediately, please hard-refresh your browser (CTRL/CMD+R) because it takes longer to load the changes, as they are saved in browser cache. Another option is to open new private/incognito window and try if it works.
I am sorry if this seems complicated for you, but I thought if you need to apply the fix quickly this will do the work. If you find this difficult I will do it for you simply provide you WP credentials.
thanks for your reply and the detailed instructions!
First the good news: deactivating the Youtube APIs worked like a charm and cookies are no longer an issue. Thanks a lot! :)
Concerning the header: I manually updated the files as suggested, and the new class is added:
.site-header--sticky-fully-active
Unfortunately, again this class is not removed (at least for me - did I maybe do something wrong?) if the page is scrolled back up and the header returns to its initial state and position.
Maybe the screen capture video attached illustrates the issue better. What should happen (and worked fine in 2.9.4 via presence/absence class ".sticky-above") is: white logo text on dark background image > dark text on white sticky header > return to white text on dark background image - so a class that acts as a switch to indicate "sticky ON" vs. "sticky OFF" would be great.
thanks for your reply. I had another detailed look at the issue and noticed some unusual behaviour.
I compared the classes set for the <header> element at initial state vs. sticky state for 3 different browsers (all on macOS 10.13.6) - with 2 variations for Safari: logged into WP vs. logged out.
Have a look at the results - the lines show in this order:
Please note that the "site-header--sticky-fully-active" class you mentioned is - for me, at least - only set in the condition where I am logged in to WP. In that case, it is also correctly removed once I scroll back to initial state. I noticed that in your screen capture video, you are also logged in to WP - could you please test your behaviour in logged out state (or private tab) and verify whether this issue is of a general nature or only affects my installation?
I double checked: I updated all my files with the new ones you provided and tested with caching disabled and/or cleared.
I have tried how sticky header works across different browsers and the same results I get on each of them, here is a recorded screen explained in details the behavior:
The active class is added as soon as the header hits "fixed" mode and if the header starts from 0px in viewport then if scroll has position of 1+ or more scrolled pixels it will add the active class.
Hi!
I ran into the following issue when using self-hosted video posts on Kalium:
I chose to use self-hosted videos partly to avoid third-party dependencies - but mainly to comply with GDPR regulations. I do not want to use any cookies on my page (that I have no use for anyways), thus making it unnecessary to bother my visitors for cookie consent.
Unfortunately, even when using self-hosted video, Youtube APIs are referenced in the <head> segment of the page:
The API calls result in cookies being set by Youtube (cf. screenshot attached) - which would require me to request visitor's consent after all. For cookies that I neither want nor have use for - and that have no business being there in the first place, since I do in no way use or reference Youtube content or services.
The issue occurs on my blog post - but it is just the same on your demo page, so unfortunately it seems unrelated to my personal server or Wordpress setup, I'm afraid.
My hope is that this is a bug or mere oversight resulting in Youtube code being inserted into the page even when using only self-hosted video - and that it may be easily fixed once your DEV-team becomes aware of it.
Please let me know if you can help - or forward the information to the right people. Feel free to reach out for further information, if required. Thanks!
Kind regards, Daniel
Hi Daniel,
By default our VideoJS implementation requires videojs-youtube plugin and that might include the Youtube API script in our theme.
So I suggest you to disable with this code (if you don't plan to use Youtube videos in your site):
add_action( 'init', function() { kalium_dequeue( 'videojs-youtube-js' ); } );Please note that the function "kalium_dequeue" is part of Kalium 3.0 and you should update kalium to latest version available.Hi Arlind,
thank you for the feedback and advice. I will not use any Youtube hosted content on my site, so I will try to follow your suggestion.
Can you tell me where to enter or execute the code you provided? Is it possible to disable it globally for the whole site? Sorry - I have a rather limited knowledge of HTML/CSS/SASS - but WP is new to me and PHP alien territory. ;) Thanks!
Just updated successfully to 3.0 - thanks for the great work, by the way!
Kind regards,
Daniel
Hi again!
Something I just noticed about the new sticky header:
Before (2.9.4.), I used custom page style CSS to modify logo color for "over the content" header position: white text on dark featured images (initial) turned to black text on minimised sticky header with white background (on scroll).
Both states could be easily differentiated via presence/absence of ".sticky-above" class.
In 3.0, the class ".site-header--sticky-active-style" is introduced once the transition to minimised sticky header with background is completed - so the color change from white > black is no problem.
Unfortunately, said class is not removed if the page is scrolled up again into initial position. Consequently, the text remains black and is not legible on dark featured images.
Ideally, both states should be distinguishable again - and a class that is added upon transition completion should be removed if the transition is reversed back to initial state.
Let me know what you think. Also, if I should rather open a new ticket for this. Thanks!
Kind regards,
Daniel
Hi Daniel,
Sorry for the delay of reply as we were buzzed with support tickets after 3.0 because of significant changes made on the theme.
For the code I gave you, you can put it in functions.php of the theme (kalium-child/functions.php or kalium/functions.php).
As for sticky header, you are right, that is something that will help users determine the state of the header and apply their own styling based on current scroll state.
I have modified the StickyHeader library code and added support for these classes:
As soon as header hits sticky mode:
After header hits sticky mode and style is fully applied:
So this might help you I hope.
To apply this on your site here are the files for you to replace in the theme before we release update 3.0.1 which will contain them by default:
1. Download this file and replace it in this directory (of the theme): /wp-content/themes/kalium/includes/functions/
2. Download this file and replace it in this directory (of the theme): /wp-content/themes/kalium/includes/functions/
3. Download this file, extract and replace the JS file (.js) in this directory: /wp-content/themes/kalium/assets/js/
If you don't see the change immediately, please hard-refresh your browser (CTRL/CMD+R) because it takes longer to load the changes, as they are saved in browser cache. Another option is to open new private/incognito window and try if it works.
I am sorry if this seems complicated for you, but I thought if you need to apply the fix quickly this will do the work. If you find this difficult I will do it for you simply provide you WP credentials.
Hi Arlind,
thanks for your reply and the detailed instructions!
First the good news: deactivating the Youtube APIs worked like a charm and cookies are no longer an issue. Thanks a lot! :)
Concerning the header: I manually updated the files as suggested, and the new class is added:
Unfortunately, again this class is not removed (at least for me - did I maybe do something wrong?) if the page is scrolled back up and the header returns to its initial state and position.
Maybe the screen capture video attached illustrates the issue better. What should happen (and worked fine in 2.9.4 via presence/absence class ".sticky-above") is: white logo text on dark background image > dark text on white sticky header > return to white text on dark background image - so a class that acts as a switch to indicate "sticky ON" vs. "sticky OFF" would be great.
Kind regards, Daniel
Hi Daniel,
I am glad the first issue is solved.
As for your other problem, can I login to your site (as administrator) and test the problem so I can try few solutions to see if it works.
I have tested in my local copy of Kalium and it successfully adds/removes "site-header--sticky-fully-active" class:
https://d.pr/v/T42xOd
Just concentrate on Inspect Element debug tool and see how the "site-header--sticky-fully-active" is toggled.
Hi Arlind,
thanks for your reply. I had another detailed look at the issue and noticed some unusual behaviour.
I compared the classes set for the <header> element at initial state vs. sticky state for 3 different browsers (all on macOS 10.13.6) - with 2 variations for Safari: logged into WP vs. logged out.
Have a look at the results - the lines show in this order:
1. Chrome (81.0.4044.13)
2. Safari (13.1) logged into WP
3. Safari (13.1) private tab
4. Firefox (76.0.1)
INITIAL STATE:
STICKY STATE:
Please note that the "site-header--sticky-fully-active" class you mentioned is - for me, at least - only set in the condition where I am logged in to WP. In that case, it is also correctly removed once I scroll back to initial state. I noticed that in your screen capture video, you are also logged in to WP - could you please test your behaviour in logged out state (or private tab) and verify whether this issue is of a general nature or only affects my installation?
I double checked: I updated all my files with the new ones you provided and tested with caching disabled and/or cleared.
Kind regards, Daniel
Hi Daniel,
I have tried how sticky header works across different browsers and the same results I get on each of them, here is a recorded screen explained in details the behavior:
https://d.pr/v/tjg9sN
The active class is added as soon as the header hits "fixed" mode and if the header starts from 0px in viewport then if scroll has position of 1+ or more scrolled pixels it will add the active class.
P.S. If you use Custom Header:
(view large image)
It will behave better, you can setup same header structure as you are currently using.