Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nao
931
Features / Re: Cookieless domains and other things...
« on April 10th, 2014, 12:13 AM »
Quote from Pandos on April 9th, 2014, 12:32 PM
Quote
Okay, let's go back to the basics...
I'm requesting a CSS file. Apache finds it, and sends it to me.
At no point, in this request, did Apache call PHP to do anything. Thus, php.ini is not used.
Sure?
Take a look at http://wedge.org/gz/css/Wilde/chrome34-member-955283.css.gz
And..?

What you're seeing is the cookie associated with wedge.org. Because it's on that domain, any GET/POST request (HTML, XML, Ajax, binary, image, whatever) sent to the server will contain matching cookies.
Which is why we have to use another domain or subdomain to ensure no cookies are generated from these.

I think the main issue with wedge.org's subdomains is that it used to be set to global cookies, so until one deletes all their cookies for wedge.org and re-logs in, they'll keep sending cookies back to anyothersubdomain.wedge.org, which isn't cool.

I'll do more tests tomorrow, if I can.

I guess my main concern with this topic is: is it okay if I use absolute URLs inside CSS files (url(http-something-absolute) instead of url(../relative))? I mean, it does add more bytes. But there's no way for Wedge to determine in advance whether relative paths would work, unless I change my feature from "custom page replacements" to "custom ASSETS URL", "custom JS URL", and "custom CSS URL". Which, how can I say it..? Would be like a throw-back to 2013 Wedge.
932
Features / Re: Cookieless domains and other things...
« on April 9th, 2014, 12:23 PM »
Quote from Pandos on April 9th, 2014, 11:20 AM
To disregard cookies there are several steps to perform.
1. configure your server to send no cookies:
php.ini: session.use_cookies = 0
Okay, let's go back to the basics...
I'm requesting a CSS file. Apache finds it, and sends it to me.
At no point, in this request, did Apache call PHP to do anything. Thus, php.ini is not used.
Quote from Pandos on April 9th, 2014, 11:20 AM
Moving CSS to the bottom?
Never heard of someone who actually does it :)
JS is a must, but CSS?
JS must be added before the closing body tag, so I'm doing that. The JS files, however, are loaded in the header as soon as you've loaded at least one page. (First page = load at bottom to make page load quickly, second page = load at top because it's already cached so it won't stall loading, and JS features will be available sooner to the user.)
CSS is normally NOT mandatory to render the page, so it's loaded async, and I'm not getting while Google has a problem with that. Anyway, I don't see a problem with loading the CSS at the end, it's just that link tags are usually... at the top. Dunno if it's even valid HTML.
Quote from Pandos on April 9th, 2014, 11:20 AM
What about combine CSS?
Too much. If you're visiting only one page and it's not a topic page, you end up having to load the editor CSS as well.
Although it'll only happen for members, so... Hmm... I don't know. Maybe it can be considered.
editor.css is not the only file that could be combined, of course... But generally, I'm trying to keep the main CSS file size to a minimum...!
Quote from Pandos on April 9th, 2014, 11:20 AM
What's next?
Force the use of CDN's to get a higher ranking?
Fully support for HTTP2.0?
Dunno about these.
933
Features / Re: New revs
« on April 9th, 2014, 12:12 PM »
[Commit revision ed0baed]
Author: Nao
Date: Wed, 09 Apr 2014 12:08:36 +0200
Stats: 1 file changed; +4 (insertions), -7 (deletions)
  • Fixed an SMF bug introduced by [Unknown] in his original implementation of the nobbc tag: they didn't work if they encompassed multiple lines. 10 years without anyone noticing..? I think that's well worth mentioning. (Subs-Post.php)
[Commit revision b3effe6]
Author: Nao
Date: Wed, 09 Apr 2014 12:12:42 +0200
Stats: 2 files changed; +10 (insertions), -7 (deletions)
  • Fixed long-lived bug where links posted inside nobbc tags were autolinked. This was due to two bugs: the SMF bug in the previous commit, and an Aeva bug where url tags were added before nobbc blocks were even protected. That preparsing code flow is such a mess, it might warrant a rewrite at some point. (Class-Editor.php, Post2.php)
934
Test board / Re: Test topic...
« on April 9th, 2014, 11:06 AM »
Test.

http://wedge.org/pub/feats/6803/new-revs-public-comments/255/ (90% after adding some strategic htaccess rules)
[url]http://www.simplemachines.org/community/index.php?topic=519351.0[/url] (68%) [url=http://www.wedge.org][url=http://www.wedge.org]www.wedge.org[/url][/url]
[url]http://www.elkarte.net/community/index.php?topic=1001.0[/url] (54%)

And another bug fixed... :eheh:
935
Features / Re: Cookieless domains and other things...
« on April 9th, 2014, 11:02 AM »
Quote from Pandos on April 9th, 2014, 10:45 AM
I see an overall of 90% for Wedge (Desktop)
Don't bother with the numbers, they can't be ported from platform to platform without reusing the same data...
Best I could do is to do an import of an SMF board, and compare two identical pages.

Here's what I'm basing my tests on (each random topic pages with a minimum amount of quotes and code tags):
http://wedge.org/pub/feats/6803/new-revs-public-comments/255/ (90% after adding some strategic htaccess rules)
http://www.simplemachines.org/community/index.php?topic=519351.0 (68%)
http://www.elkarte.net/community/index.php?topic=1001.0 (54%)
Quote from Pandos on April 9th, 2014, 10:45 AM
Since the compalin is about CSS....
If the CSS is smaller than 2048 bytes, we could try to inline them.
No it's not, of course for the main file (12KB compressed, 25KB compressed after embedding icons in it), and other files (such as the editor) still need to be included in all topic pages, and the best I can do is to actually move it to the bottom of the page, like they suggest.
Quote from Pandos on April 9th, 2014, 10:45 AM
Cookieless:
Therefor you must have access to the virtual host file to discard cookies for that domain. This should only work if you put your files on a different server IMHO.
The problem is that CLIENTS send a cookie with their request. Servers don't send anything, of course...
936
Features / Re: Cookieless domains and other things...
« on April 9th, 2014, 10:29 AM »
Anyone inspired..? :-/
937
Plugins / [Plugin] Re: Facebook for Wedge
« on April 8th, 2014, 11:40 PM »
Don't forget to click Admin > Purge cache (Effacer le cache), from time to time...
I'm not sure what's wrong, though. I don't think there's a toggle to check, apart from the actual plugin enabler.

PS : ehhh, j'ai reçu une relance de la BNF... Wouhou... -_-
938
Features / Re: New revs - Public comments
« on April 8th, 2014, 11:17 PM »
It'd be practical even for me.... :P

I have so many things to add before I can call it beta material.... :-/
UI for contact lists.
UI for auto-updates.
Web installer.
Soft-deletion of posts...
What else..? I don't remember. So many...

:edit: Also, a quick editor to determine which elements to put onto the homepage.
939
Archived fixes / [Installer] Re: Sub language folders are not recognized
« on April 8th, 2014, 09:33 PM »
Done totally in the dark... No time to test. Something along these lines..? Please test!
Around line 206 in install.php, of course.

Code: [Select]
while ($entry = $dir->read())
{
if (substr($entry, 0, 8) == 'Install.' && substr($entry, -4) == '.php')
{
$txt = array();
require_once($folder . '/index.' . substr($entry, 8));
if (!empty($txt['lang_name']))
$incontext['detected_languages'][$entry] = '<img src="core/languages/Flag.' . substr($entry, 8, strlen($entry) - 12) . '.png"> ' . $txt['lang_name'];
}
elseif (is_dir($folder . '/' . $entry) && file_exists($folder . '/' . $entry . '/Install.' . $entry . '.php'))
{
$txt = array();
require_once($folder . '/' . $entry . '/index.' . $entry . '.php');
if (!empty($txt['lang_name']))
$incontext['detected_languages'][$entry] = '<img src="core/languages/' . $entry . '/Flag.' . $entry . '.png"> ' . $txt['lang_name'];
}
}
$dir->close();
940
Plugins / [Plugin] Re: Facebook for Wedge
« on April 8th, 2014, 09:18 PM »
Didn't we we establish earlier that it was indeed possible..? By visiting the Facebook link on your profile menu.
941
Archived fixes / [Installer] Re: Sub language folders are not recognized
« on April 8th, 2014, 08:55 PM »
Hmm, I thought I'd fixed that last week... :-/

OTOH, worst it can do is install the thing in English, right...? :P
942
Features / Re: New revs
« on April 8th, 2014, 08:53 PM »
[Commit revision bf05128]
Author: Nao
Date: Tue, 08 Apr 2014 13:10:24 +0200
Stats: 1 file changed; +1 (insertion), -0 (deletion)
  • Pretty URL settings page was broken by a missing include. (ManageSettings.php)
[Commit revision 82b70d0]
Author: Nao
Date: Tue, 08 Apr 2014 20:53:28 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)
  • Pete bug: PNG header is "\x89PNG", not "\89PNG". This broke the max_image_width feature. (Subs.php)
943
Archived fixes / [Posting] Re: external images not resized
« on April 8th, 2014, 08:52 PM »
Fixed!

Was a Pete bug, and not the first of its kind. He says in the changelog that he tested on PNG, but I guess not! ;)
944
Archived fixes / [Posting] Re: external images not resized
« on April 8th, 2014, 08:40 PM »
Hmm... Testing.



png



Okay, it can be reproduced by setting the maximum width to 220. It was set to 1280 here, BTW. Will look into this.
945
Features / Cookieless domains and other things...
« on April 8th, 2014, 08:35 PM »
So, today I did a quick audit of my web pages, and noticed that PageSpeed Insights had AGAIN changed their algorithm... Okay.

As you may know, Wedge is the champion of web optimization, I spent enough time on making sure it was, and in earlier versions of PSI I was hover over 95% while the SMF-based competition was between 60 and 70%. All scores were lowered by a fair margin when analyzing an actual topic page, though.

Now it seems that with the new algorithm, and with page 1 of a random topic, SMF is at 53%/59% (Speed/User experience), ElkArte is at 68%/97%, and Wedge is at 78%/97%. Yes, BARELY better than ElkArte... Anyway.

Both Elk and Wedge have the same 'blocking' error: CSS blockers in the head, which end up delaying the page render phase. Okay, uh...
Seriously.
CSS files are supposed to be in the head. It's the standard thing.
Now what does Google suggest..? Moving them to AFTER the closing html page. Not kidding.

Okay, I'm not sure I want to do that. Why should I generate a FOUC just to please PageSpeed Insight..?
So I looked into doing something else to improve parallelism... Moving my assets to new domain names. Which would also eliminate the problem with cookieless domains. Which PageSpeed Insight does NOT care about, but the Chrome Dev tools "Audit" section does, so I'm doing that.

Okay, we're on topic now.

I started by doing some tests with the skin system's <replace> tag, but I don't want to have to update the custom.xml files on all of my skins every time I add or remove a subdomain, so I spent my afternoon working on a UI to implement page replacements. Just simple str_replace calls, that you can control from within the "Pretty URLs" admin page.

Cool, uh?

Well, it works.
But it has problems, which I want to discuss. (Putting numbers next to topics, so we can refer to them individually.)

1/ If I move all of my assets (+css+js) to a single subdomain, Google's Audit complains that there are too many resources loaded from that subdomain (!!). Solved by moving to assets, js and css subdomains.

2/ Looks like Wedge is still creating cookies on these subdomains, even though I modified the cookie admin option to no longer be 'global'. After removing that cookie (once for each subdomain), though, I have yet to reproduce.

3/ Relative URLs will no longer work, of course, inside CSS and JS files. Because you can't access the /assets/ folder from a css subdomain which is restricted to the /gz/css/ folder as its base, I was forced to remove relative URL optimizations, and regenerate my cache. Not cool. It definitely adds a few bytes to CSS files, although not THAT many...

4/ PageSpeed Insights is now... giving me more complaints about <head> links. Yayz. My score actually went (for the same page), down from 78 to 70%!!! Way to go!

What do you think?
Why do you think my score has decreased that much, even when it should have actually increased...?