Potential error in stylesheet themes/standard/style.css
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
1 Attachments
#2977 Potential error in stylesheet themes/standard/style.css
I just merged to the latest - PhpGedView 4.3.1 SVN 7361
It was seemless as best as could tell - aside from one item I spotted (and I don't know which version it came in at as I was about 20 updates behind when I started the update today).
Starting on an individual | Options for individual | Lists | Individuals.
All looked good until - show statistics charts,
Each of the 3 charts has the message:
Potential error in stylesheet themes/standard/style.css
Garry,
yes, I confirm too. In all themes. But in chrome debugger I have the
following warning:
"Indicate whether to send a cookie in a cross-site request by specifying
its SameSite attribute"
Because a cookie’s SameSite attribute was not set or is invalid, it
defaults to SameSite=Lax, which prevents the cookie from being sent in a
cross-site request.
This behavior protects user data from accidentally leaking to third
parties and cross-site request forgery.
Resolve this issue by updating the attributes of the cookie:
Specify SameSite=None and Secure if the cookie should be sent in
cross-site requests. This enables third-party use.
Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent
in cross-site requests.
Maybe it is not CSS but cookies issue?
T.B.
Confirmed. Happens on my site too, using Cloudy theme.
The error message comes from Google, and is not very helpful. Not too sure what's making Google complain.
I'll correct the very minor "observations" reported by various CSS validation programs. Let's see what happens.
Tomasz:
The strange thing is, when you fire up the Statistics plots from the main menu of any page (you don't have to be logged in), you don't see this error message on any of the many charts produced by the Google API.
It's ONLY the histogram charts on the Individual and Family list pages.
I think we're trying to resolve a bug in the Google histogram chart program.
I checked the CSS of each theme, using the https://jigsaw.w3.org/css-validator/ CSS validator. The Cloudy theme's CSS file produces some inconsequential warnings; the others are all clean, according to the validator.
Any ideas about either hiding the warning or making Google aware of this apparent error?
When you inspect the source of the page that shows the error message, there doesn't appear to be a div for the error message -- it's just embedded in the image produced by Google.
It seems as though Google has "improved" the Charts system by deprecating the old Charts APIs that PhGedView is using. Now, we have to use the "Visualization" APIs.
The new method of creating graphical charts is not at all compatible with the old. The new method may be more flexible, with many more features, but it's going to be a LOT of work and head-scratching to implement the new way of creating charts in PhpGedView.
I don't look forward to doing this. Don't hold your breath, folks.
Ha, I've caught it. It is not google api issue but the CSS parser. Namely the class
includes/classes/class_cssparser.php
and the ParseCode(...) function in it.
But I don't understand why does it trigger the error. At the end of the function $css var is not empty while it should be...
T.
Tomasz:
Thank you. I never expected that the error could originate from within PhpGedView itself. Arghh.
The error points to the $css variable being not-empty. This is of, course, true since that $css variable contains the name of the CSS file being examined, and not its contents.
I'll have to work through the logic, but I think the code is trying to reduce the CSS file so that only invalid entries are left. If, after reduction, we have stuff left over, we have an error.
Since I know that there shouldn't be any errors in the CSS file, the "error" can be ignored.
In the meantime, I will have to post a query to the cssparser developers.
Fixed in SVN 7362.
The problem was that the CSS parser expected to see the contents of the CSS file, and NOT the name/location of the file.
Also, all of the CSS files had errors. There were some lines in these CSS files that did not have a closing semi-colon on the last line before the closing right-parenthesis } . This made the CSS parser throw errors. Poor program logic here, but I won't bother the developer of the CSS parser with this.