Development Version download link not working

[GoogleCodeExporter]

Hi,

that is basically it. The link to the development download does not seem to 
work. Just to let you know.
S

Original issue reported on code.google.com by sas...@thespacelab.co.uk on 24 Aug 2011 at 10:48

[GoogleCodeExporter]

Hmmm, all links seem to point to the stable version. Or is the readme file not 
being updated? That's where I usually look to see what version I am 
downloading....
S

Original comment by sas...@thespacelab.co.uk on 24 Aug 2011 at 10:51

[GoogleCodeExporter]

Thanks for the heads up -- I have had problems with that link... looks like 
something got hosed when I updated my server a couple days ago.

Yeah, the way WP handles its repo is *ahem* incredibly stupid.  It is the 
*readme.txt* that triggers what tag in the SVN tree to package and deploy on 
the WP site, so I can't breathe on it until it's really REALLY time to push a 
new release, otherwise it triggers a "New Version" all-points-bulletin.  And if 
it references a tag that doesn't exist in your SVN repo, the WP zip file is 
packaged from the SVN HEAD (!!!).  Naturally, no email inquiries about this to 
the WP team are answered, so it's a pretty poor implementation as far as I'm 
concerned.  I plan on housing my own downloads on wpcctm.com once I take that 
site live to help remedy this confusion.

Have a look at the includes/CCTM.php file for the REAL version.  There's a 
version and a version meta that I use to track what I'm doing with a branch.  
Starting with 0.9.4, all that info will be printed into a text area for easy 
copy-and-pasting when someone files a bug report.

See the attached file for the most current version -- I'm looking into the 
download link thing.

Original comment by fireproofsocks on 24 Aug 2011 at 11:47

• Changed state: InReview

Attachments:

• custom-content-type-manager.zip

[GoogleCodeExporter]

I've updated the server settings -- this should be good to go now.  Remember: 
check the info in the includes/CCTM.php for the most granular description of 
the version.

Original comment by fireproofsocks on 28 Aug 2011 at 6:31

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Broken again.  Dammit!

Original comment by fireproofsocks on 2 Sep 2011 at 4:20

• Changed state: ReOpened
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Donwload file links to require_once( realpath('../../../').'/wp-config.php' );
This doesn't work if you have separate wp-content from core Wordpress files;

The plugin should check the realpath first and generate warning if is wrong. I 
attached a small improvement to check directories system.

Mm... why call this file directly? you need a loader from main file plugin.

---
Another issue: if you have restricted access to static files in your 
wp-content, obviously, any call to plugin files doesn't works.

Original comment by laguardi...@gmail.com on 28 Sep 2011 at 12:47

Attachments:

• download.2.php

[GoogleCodeExporter]

Thanks.  Any stand-alone controller (e.g. an AJAX controller) needs to load up 
the WordPress API, and the way to do that is by including the wp-config.php, so 
that's why some files include the wp-config.php file: because they are accessed 
via an independent http request.  WordPress' architecture has poor support for 
this kind of "connector".  

Likewise, WordPress offers poor support for restricting access to directories.  
Like you mentioned, if you want to protect your uploads directory (or to the 
plugins directory as a whole), you are likely to break things.  I don't think 
there's any need to use the __autoload() or its variants... there's nothing 
complex enough in the classes to require it.  I changed how this works in 
version 0.9.4 (coming out very soon), but there's still the fundamental problem 
of how to handle independent http requests.

So how do you handle other plugins on your site that are expecting the 
wp-content from the core WP files?  E.g. if you use the Media manager to upload 
images, how does WP handle that?  As far as I know, that path is hard-coded 
into the WP application, so if you move it, lots of things break.  I could of 
course check to make sure the file or directory exists and throw a warning, but 
that wouldn't fix the fact that a lot of WP functionality would break, no?

Use of the DIRECTORY_SEPARATOR constant is not necessary unless the user is 
supplying path info: PHP understands the more standard forward-slash (yes, even 
on Windows).  The only time the DIRECTORY_SEPARATOR constant needs to be used 
is if you let users select a path on the filesystem via a form -- only then 
would you need to check the submitted string against the DIRECTORY_SEPARATOR 
constant.  

This should probably be put into another issue: this issue is relating to the 
link @ http://wpcctm.com/cctm-dev.zip not any of the code.

Original comment by ever...@fireproofsocks.com on 28 Sep 2011 at 2:31

[GoogleCodeExporter]

I looked into this a bit... I think it's better to tie into the wp-load.php 
file for independent AJAX requests since it handles the locating of the 
wp-config.php file.  It also suppresses some of the warnings that show up due 
to WP's reliance on magic_quotes.

Original comment by fireproofsocks on 28 Sep 2011 at 5:59

• Changed state: Fixed

[GoogleCodeExporter]

Issue 135 has been merged into this issue.

Original comment by fireproofsocks on 5 Oct 2011 at 8:56