Just send the effected file(s) or relative .patch to
[EMAIL PROTECTED] We'll reveiw anything you have and
move from there.
Thanks,
--Tony
Drago Goricanec wrote:
Actually, the protocol and the base are two different issues. I added the base
so that I wouldn't have to rewrite image URLs that are referenced by the story
(they're stored in the database with the protocol). Also, I wanted links to my
local site to match the protocol that was currently in use. They could all be
dynamically rewritten. Perhaps rather than storing the full URL, there could be
a [site_url] prefix that was stored in the link or article and rewritten when
the pages are generated. It would also make it easier to move the site to
another URL.
The protocol stuff was as clean as adding this line to my config.php:
$_CONF['site_url'] = ($_SERVER['SERVER_PORT'] == 443 ? 'https:' : 'http:') .
"//www.example.com/";
What is the method of submitting patches to the development team?
Drago
Quoting Tony Bibbs <[EMAIL PROTECTED]>:
I personally wouldn't like this because I know some proxy servers that
pass web traffic to web servers behind it end up making the relative
pathing a problem. Geeklog needs to make clear (and clean) support of
SSL for all admin functions. The base is there we just need to change
the code to allow for https for admin stuff. It maybe as simple as
adding a $_CONF['admin_protocol'] variable that can be either http or
https. Then we could dynamically generate the https for the admin side.
We should also make a similar change to the public login page.
Oh, hope the proxy server thing makes sense. We have a configuration
here at work like that and it reaks havoc if you don't use absolute
paths (nor just for our PHP apps but our Java and ASP/.NET apps as well.
--Tony
Drago Goricanec wrote:
I modified geeklog code to detect whether http or https was used to
connect, and
then write all URLs using the resulting protocol. The reason is that I
didn't
want to leave either my password, or my weblog information on a computer
or
network that I didn't trust (when administering the site), but I didn't
want
all users to be forced to use https.
Current code uses $_CONF['site_url'] for all URL references. If 'http:' is
hardcoded here, then even if the connection is over 'https', all references
to
images and links within the site remain 'http'.
I changed all URL references to my geeklog site to be relative to
{site_url}
(i.e., {site_url} doesn't appear in any of the templates). I changed the
layout
header to emit <base href="{site_url}/">. {site_url} still exists, but it
is
dynamically created based on the protocol used to connect (http or https)
with
a path to the weblog. Trailing '/' is omitted. All other URLs, such as
{site_admin_url} are relative to {site_url}. Even images in stories are
stored
with a relative URL.
I also added a secure/normal login link to switch between http and https
just
below the login form.
Would others be interested in this change? I can provide a patch against
the
latest source. What is the process of submitting such patches?
Drago
_______________________________________________
geeklog-users mailing list
[EMAIL PROTECTED]
http://lists.geeklog.net/listinfo/geeklog-users
_______________________________________________
geeklog-users mailing list
[EMAIL PROTECTED]
http://lists.geeklog.net/listinfo/geeklog-users
_______________________________________________
geeklog-users mailing list
[EMAIL PROTECTED]
http://lists.geeklog.net/listinfo/geeklog-users
