Get path & get URL

[nicolasdanelon]

I know... Shaarli is not a framework like Laravel, is just a Delicious clone but the community is adding a plugin system.. and a lot of improvements.. and now we got a lot of unclean URLs in the home page..

    <link type="text/css" rel="stylesheet" href="tpl/../inc/awesomplete.css" />
    <title>Shaaring links - DEMO</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="format-detection" content="telephone=no" />
<meta name="viewport" content="width=device-width,initial-scale=1.0" />
<link rel="alternate" type="application/rss+xml" href="http://localhost/links/?do=rss" title="RSS Feed" />
<link rel="alternate" type="application/atom+xml" href="http://localhost/links/?do=atom" title="ATOM Feed" />
<link href="images/favicon.ico" rel="shortcut icon" type="image/x-icon" />
<link type="text/css" rel="stylesheet" href="tpl/./../inc/reset.css" />
<link type="text/css" rel="stylesheet" href="tpl/./../inc/shaarli.css" />

So this is a open ticket for everyone who can do it. One function, or method for the server path and one secure functions who returns the path to public resources. ie:

getPath() {} // returns /home/username/public_html/shaarli
getURL() {} // returns http://website.com/shaarli
getURL( 'inc' ) {} // returns http://website.com/shaarli/inc/

I think this will be very useful or plugin system and for every shaarli resources

[virtualtam]

+1 for static resource / asset management!

This will first require the plugin system to be merged and stabilized; as it's also related to rewriting the page templates, this may be discussed in #266 as well

[nicolasdanelon]

I don't think that plugin system is a requirement for this features. This
will help the plugin system, doing uploads, styling and adding scripts more
easy and efficient.

On Tue, 21 Jul 2015 18:34 VirtualTam [email protected] wrote:

+1 for static resource / asset management!

This will first require the plugin system to be merged and stabilized; as
it's also related to rewriting the page templates, this may be discussed in
#266 #266 as well

—
Reply to this email directly or view it on GitHub
#292 (comment).

[virtualtam]

What I meant is rather: we first need to finish work on the plugin system, then we'll have time to carry on new tasks ;-)

Yet, as it is quite uncorrelated (code-wise), a first PR with a class / set of functions to handle static assets would be very welcome :)

[nicolasdanelon]

ok :)

[ArthurHoaro]

Note that most path displayed in your example are actually defined in templates (see includes.html).

First thing that can be done is using everywhere the # to get cleaner paths. Difference here.

Is getPath (absolute path) necessary or used?

+1 for having a clean getURL.

[nicolasdanelon]

@ArthurHoaro first of all I wanna say WOW!! Awesome work in #275 thanks!

About getPath: Right now nobody is using the path.. but I saw a proposition for file upload. Maybe someday a lot of plugins will need this method, I think that __DIR__ (I don't link $_SERVER vars) can be useful ( with a simple test ) but right now I don't have time to do it.

About getURL: When I write php for Laravel application the method URL::("/") and the function asset('/favicon.ico') are very useful. Will be great for shaarli assets and plugins, I think

[ArthurHoaro]

I'll write a getURL function to manage links.

I won't write a getPath function, because:

• absolute path should never be displayed in templates (security issues)
• in plugins, there are a bunch of PHP feature which can be used to manipulate path: __DIR__, dirname(), realpath(), etc. I don't see any advantage of adding our own layer.

[nicolasdanelon]

I never speak about show the absolute path to public. The absolute path is for internal usage. __DIR__ rocks!

[ArthurHoaro]

I'm pushing the milestone since processing core code with Slim might open new perspectives regarding path and URIs.

[ArthurHoaro]

Update on this with v0.12.0: there are no function yet, however all sort of prefixes are available across templates depending of what link should be available:

• $base_path: to generates URL regardless of subdirectories install.
• $root_path: path to the root directory of Shaarli, to include any file
• $asset_path: path to the root directory of the template
• $index_url: URL to Shaarli instance

I think it covers the use cases mentioned in the issue. We could add functions to cover these cases, but I think we shouldn't for two reasons linked to how RainTPL works:

1. Function with parameters in RainTPL are less readable IMHO, so instead of {$base_path}/shaare/abc we would need {function="getPath('/shaare/abc', 'type_url')"} (or something similar)
2. We can't register extensions with RainTPL, so we would need to inject the container globally into a function in order to make it accessible, which is not very clean.

I suggest that we close this issue.