Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Feedback to: Textpattern CMS 4.5.3 released
The zip file contains physical copies of all symlinked files in the sites folder while the tar file just contains the tiny symlinks. This is the result of using each tool’s default options for resolving symlinks, and not a thoroughly evaluated sinister plan.
Under the coarse assumption that zip files appeal to Windows folks while tar are a popular *nix format the archive contents are a nice fit for the symlinking capabilities of each operating system.
I’m not quite sure whether this difference is a relevant fact. Educated opinions from each O/S camp are welcome.
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
If we are not using the multisite feature do we need to upload the “sites” symlink/directory?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
Robert, there is a major issue. The 4.5.3 release’s package is broken. It contains wrong files and sources. Look what new files textpattern-4.5.3.zip contains:
+./.gitignore
+./images/.gitignore
+./textpattern/.gitignore
+./textpattern/include/txp_lang.php
+./textpattern/lib/txplib_textfilter.php
+./textpattern/modernizr.js
+./textpattern/theme/classic/img
+./textpattern/theme/classic/img/arrow-up-down.gif
+./textpattern/theme/classic/img/arrow-up-down.svg
+./textpattern/theme/classic/img/expand-collapse.gif
+./textpattern/theme/classic/img/expand-collapse.svg
+./textpattern/theme/classic/img/spinner.gif
+./textpattern/theme/classic/img/spinner@2x.gif
+./textpattern/theme/classic/img/textpattern.png
+./textpattern/theme/classic/img/textpattern.svg
+./textpattern/theme/classic/img/view-html.png
+./textpattern/theme/classic/img/view-html.svg
+./textpattern/theme/classic/img/view-preview.png
+./textpattern/theme/classic/img/view-preview.svg
+./textpattern/theme/classic/img/view-text.png
+./textpattern/theme/classic/img/view-text.svg
+./textpattern/theme/hive/css/custom/hide_textfilter_group.css
+./textpattern/theme/hive/img/indicator.svg
+./textpattern/theme/hive/img/spinner@2x.gif
+./textpattern/theme/hive/img/textpattern-lrg.svg
+./textpattern/theme/hive/img/textpattern-sml.svg
+./textpattern/theme/hive/img/textpattern-xlrg.svg
+./textpattern/theme/hive/img/view-html.svg
+./textpattern/theme/hive/img/view-preview.svg
+./textpattern/theme/hive/img/view-text.svg
+./textpattern/theme/remora/img
+./textpattern/theme/remora/img/expand-collapse.gif
+./textpattern/theme/remora/img/expand-collapse.svg
+./textpattern/tmp/.gitignore
+./textpattern/update/_to_4.6.0.phpFor some reason the archives don’t contain 4.5.3, but some revision from dev branch. Might want to do re-release under 4.5.4.
Last edited by Gocom (2012-12-05 07:43:40)
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
wet wrote:
[…] and not a thoroughly evaluated sinister plan.
I’m definitely using this is in a conversation today.
The attention drawn to the format differences of .zip and .tar.gz are secondary — I am now more familiar with the way they both work after learning from this thread, the primary point being that some Hive images now have SVG versions and retina-style (I guess this is what @2x means). Some other new stuff crept in — again, I’m guessing the text filter is for alternatives to Textile (Markdown, I’m looking at you), though I thought this was destined for 4.6.
I don’t know protocol here, but if the release notes don’t tally with the actual file changes, is a new release in the offing with updated release notes for the actual changes or a repack per the original release notes?
Edit: ignore that last bit, I just checked the SVN changes.
Last edited by gaekwad (2012-12-05 09:29:14)
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
colak wrote:
If we are not using the multisite feature do we need to upload the “sites” symlink/directory?
No. Same for /rpc — if it’s disabled, it can left out of the upload.
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
Textpattern 4.5.4 fixes these packaging issues and supersedes 4.5.3.
Thanks to all who contributed to this hiccup relief.
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
wet wrote:
Textpattern 4.5.4 fixes these packaging issues and supersedes 4.5.3.
Thanks to all who contributed to this hiccup relief.
Thanks for the rapido-style repack, Robert.
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
wet wrote:
Under the coarse assumption that zip files appeal to Windows folks while tar are a popular *nix format the archive contents are a nice fit for the symlinking capabilities of each operating system.
True. Unfortunately, those who have their websites hosted on a *nix machine quite often use windows at home, unpack the .zip at home and use FTP to upload files to their website, thus losing the symlinks. Nothing the devs can do about that. It’s up to the users to educate themselves, stop using FTP, switch to using the tar.gz files and unpack them on the *nix server instead of on a windows machine.
Does there still have to be a “&” at the end of the URL for the tar.gz files?
It’s really annoying if you use wget and simply paste the URL as a parameter (without enclosing it in “”, which is sloppy, I know, but I suspect it happens to more people), because the “&” has special meaning on the *nix command line. I tried using wget with the file download url after I removed the &. Worked just fine.
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
ruud wrote:
Does there still have to be a “&” at the end of the URL for the tar.gz files?
Huh. I hadn’t noticed that before. Has it always been that way?
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
Since early 4.0.x releases, IIRC. Something to do with apache compressing it twice otherwise (something like that), but it seems to work without the & nowadays. Anyone remember in which specific situation this was needed?
Offline
Re: Feedback to: Textpattern CMS 4.5.3 released
ruud wrote:
Since early 4.0.x releases, IIRC. Something to do with apache compressing it twice otherwise (something like that), but it seems to work without the & nowadays. Anyone remember in which specific situation this was needed?
That is what the comment in the source would indicate, but Isn’t the comment in the source bit misleading? I’ve always thought that it’s not about double compression, but skipping compression due to the extension. E.g. the Content-Encoding header is set which makes the client to try and uncompress the download. Either the header is set because the extension, or the compression is skipped due to it while the Content-Encoding header is still sent.
But ultimately it’s just a workaround for someone else’s issue.
Last edited by Gocom (2012-12-06 21:17:09)
Offline