White space begins iCal listing

bm1 · 2014-03-25 14:24:04 UTC

I'm trying to generate iCal subscriptions - an asset lister for calendar events has a bare-bones design that delivers a text/calendar MIME type (as in http://matrixusers.com/tutorials/output-content-to-a-file)

However, the downloaded source has white space in front of the initial text of the listing, which causes Google calendars to reject the file:

                BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//iCal title//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:20140309
DTEND:20140314
SUMMARY: Protein Transport Across Cell Membranes
LOCATION:Galveston, TX, United States
END:VEVENT

Rather similar to the discussion about blank space in front of a <DOCTYPE> tag (http://forums.squizsuite.net/index.php?showtopic=9759), but in this case my design has no <SHOW_IF> or other complex content:

<MySource_PRINT id_name="__global__" var="content_type" content_type="text/calendar" /><MySource_AREA id_name="body" design_area="body" />

Any thoughts/suggestions?

Thanks in advance

Brian

tomchadwin · 2014-03-25 15:04:15 UTC

Hi Brian

Since my DOCTYPE issue has apparently already been solved, you'd better let people know your Matrix version, in case this has been fixed too.

Tom

bm1 · 2014-03-25 16:15:41 UTC

Hi Brian

Since my DOCTYPE issue has apparently already been solved, you'd better let people know your Matrix version, in case this has been fixed too.

Tom

Oh, sure - I'm on 4.18.4, the current release.

Cheers

Brian

nnhubbard · 2014-03-25 16:28:17 UTC

Oh, sure - I'm on 4.18.4, the current release.

Cheers

Brian

Hmm, we are on 4.18.2 and have a identical iCal Design asset that works correctly with no whitespace.

Did you make sure to NOT have a hard return after the body design area?

bm1 · 2014-03-25 17:46:45 UTC

Hmm, we are on 4.18.2 and have a identical iCal Design asset that works correctly with no whitespace.

Did you make sure to NOT have a hard return after the body design area?

As far as I can tell - I assiduously deleted anything that might have been whitespace at the end of the quoted design. I've also generated a parse file with no final linefeed and imported that into a new Design - same result.

On looking a little more closely, that whitespace is actually two TAB characters. I've checked that all whitespace in my parse file is single space characters.

Might it have anything to do with my web server (Apache 2.2.3 on CentOS)? Nothing obvious in its .conf file. My primary website sits behind a Squid reverse proxy, but applying the same design to another site that serves content directly also shows the same behaviour.

tomchadwin · 2014-03-25 18:19:17 UTC

Sure its not relevant to this case, but my DOCTYPE issue was two tabs as well, no line breaks.

nnhubbard · 2014-03-25 18:49:17 UTC

The only thing that I can think of is that our iCal Parse File has been around for years and never changed, so maybe we created it years ago when there was no bug, and it has never been re-parsed since.

Bart · 2014-03-27 06:40:53 UTC

You don't have a paint layout applied to this asset at all do you? If so, check that its content is not printing any additional spaces or tabs.

Also make sure that the Page Contents asset of the asset listing doesn't have any spaces.

bm1 · 2014-03-27 09:28:10 UTC

You don't have a paint layout applied to this asset at all do you? If so, check that its content is not printing any additional spaces or tabs.

Also make sure that the Page Contents asset of the asset listing doesn't have any spaces.

No Paint Layout, and no leading whitespace in the Page Contents.

I do find Tom's remark suggestive, at the least:

Sure its not relevant to this case, but my DOCTYPE issue was two tabs as well, no line breaks.

I also notice that if I cook my parse file so that it says

<MySource_PRINT id_name="__global__" var="content_type" content_type="text/calendar" />X<MySource_AREA design_area="body" id_name="body" />

(note that spurious "X" xharacter just before the BODY design area), then the result I get begins:

0000000   X  \n  \t  \t   B   E   G   I   N   :   V   C   A   L   E   N

i.e. a newline after the "X" (though there's none in the parse file) and then again those two tabs. Doesn't this suggest that they're being introduced in the rendering of the BODY design area?

Thanks

Brian

Bart · 2014-03-31 10:00:32 UTC

Weird, what happens if you just print the body as a test? So in your parse file, just put

<MySource_AREA design_area="body" id_name="body" />

And see if there are any spaces or tabs generated. Maybe the content_type print design area is causing the tab spacing for some reason....

bm1 · 2014-04-01 16:05:55 UTC

Weird, what happens if you just print the body as a test? So in your parse file, just put
<MySource_AREA design_area="body" id_name="body" />
And see if there are any spaces or tabs generated. Maybe the content_type print design area is causing the tab spacing for some reason....

Same story - leading two tabs. Which, I think, I was expecting - it sounds like the same thing that's happening to Tom with his <DOCTYPE> troubles

Bart · 2014-04-02 12:47:37 UTC

Not sure why this would be happening, can't replicate on my end. The last thing would be to try and crate a brand new parse file, just add the body tag, don't add a paint layout, and apply it to a standard page and test.

What database software and version are you running on this system?

bm1 · 2014-04-08 10:55:58 UTC

Not sure why this would be happening, can't replicate on my end. The last thing would be to try and crate a brand new parse file, just add the body tag, don't add a paint layout, and apply it to a standard page and test.

What database software and version are you running on this system?

Sorry for the delay in replying - been away for a few days. As expected (almost), I get two tabs and a newline before the <DOCTYPE> tag.

Database: PostgreSQL 8.1.23

PHP version: 5.1.6

Thanks

Brian

Bart · 2014-04-10 23:45:39 UTC

I'm testing on 5.4 and version 9 of PostgreSQL, that's the only reason I can think of for the difference in behaviour :(

dschoen · 2014-05-07 23:05:51 UTC

The DB/PHP version shouldn't really be relevant to this type of problem due to the way it compiles.

@Brian Can you try a completely fresh site asset (on an alternate domain name, doesn't have to really exist) with only this design applied, public permission granted, everything live and then use curl/xxd to render the contents, e.g I get:

$ curl -s --header "Host: domain-name-here" http:/localhost:port/ | xxd 
0000000: 7465 7374                                test

You'll need to execute the curl on the server running Matrix and connect to the port apache (not Squid) is running on, the custom header is supplied to let you connect to whatever domain you create.

Basically I'm just trying to isolate it from everything as there's a chance you're still inheriting a paint layout from somewhere or something else we're missing.

Bart · 2014-05-08 01:15:12 UTC

Sounds like this might have been fixed in the latest release: https://squizmap.squiz.net/matrix/5291

Went into 4.18.6 and 5.0.1.0 releases.

bm1 · 2014-05-21 12:22:52 UTC

The DB/PHP version shouldn't really be relevant to this type of problem due to the way it compiles.

@Brian Can you try a completely fresh site asset (on an alternate domain name, doesn't have to really exist) with only this design applied, public permission granted, everything live and then use curl/xxd to render the contents, e.g I get:
$ curl -s --header "Host: domain-name-here" http:/localhost:port/ | xxd 
0000000: 7465 7374                                test
You'll need to execute the curl on the server running Matrix and connect to the port apache (not Squid) is running on, the custom header is supplied to let you connect to whatever domain you create.

Basically I'm just trying to isolate it from everything as there's a chance you're still inheriting a paint layout from somewhere or something else we're missing.

Sorry for the delay in replying to this - I had noticed the reference to an apparently relevant bug fix in 4.18.6 but had experienced some difficulties in upgrading. Finally got this done today.

After the upgrade, I did perform your suggested test, and was initially disappointed to get the same result as before (two leading tabs). However, on reopening the existing barebones design parse file, ensuring (yet again) that there was no extraneous whitespace, and then saving, I now find that the problem has gone away. Looks like that upgrade has cured this.

Many thanks to you and Bart for your interest in pursuing this.

Cheers

Brian

Bart · 2014-05-22 00:33:32 UTC

Good to hear it working for you Brian.