An almost complete rewrite of the older Extract URL Plus plugin.

This plugin is designed to take a URL (alone, or mixed in with other text, such as the automatic link the upload form might create) and dissect it into it’s seperate components.

For an example URL (this contains all components!):

These components are named, as variables:

full_url ( [the given url] )
scheme (http)
user (user)
pass (pass)
host (www.example.com)
port (8080)
public_path (/articles)
file_path (/articles/index.php)
server_path (/var/www/html/articles/index.php)
file_name (index.php)
extension (php)
description (PHP File)
file_size (1.14KB)
query_string (id=10&q=Hello+World)
fragment (example_anchor)

The usage is pretty much identical as to the older version, so either:

Example A:

(remove space between % and variable name!)

Example B:

Both examples returning:

index.php (1.14KB)

There is an additional parameter in this version:

url_only=”” - Defaults to “no”, meaning the plugin will revert to using a regular expression to find the URL in text. This of course is more CPU intensive than if you are supplying JUST a URL, where you could set this paramater to “yes”.

Enjoy!

What was the reason for the rewrite?  Just to allow more url components?

I will give this a go, let you know how i get on.

Thanks

It was throwing “No URL Found” errors when used with Huot’s File module, at least for me. Thanks for the rewrite!

@Joobs:

There were many reasons for the rewrite. One was to bring it inline with the developer guidlines, though I’ve yet to submit it for addition to the official repository. The others:

- Allow for a regex OR non-regex parsing of the URL.
- Add caching to improve performance on multiple calls for the same URL.
- Clean up and improve the reliability of the regex.
- Improve the naming of variables.
- Improve the file descriptions to allow for a generic response.
- Add more matched variables (such as user/pass/query_string/fragment). Note that if a URL had any of these components, the old plugin would likey return “No URL Found”—(Don’t you just hate that error already ;])
- Filesize should work without having to muck around with the plugin code.
- You can now use all the variables within conditionals (if used like example B)
- Replaces lone & with & amp; (minus the space) for the full_url variable
- Various security features

The list goes on

@Ryan:
Has 2 alleviated the gruesome No URL Found error?

Um, I actually found another way around my problem (big bad deadlines…) but I’ll make sure to try this out when I get a chance.

Hiya mdesign,

Just wondering what you did to get around the problem you were having. I’m at the moment using an SAEF with the File extension and am having problems using the original Extract URL and this one due to the files having spaces in their names. Just wondering how you managed to get the name with this happening?

Best wishes,

Mark

I’m getting alternating “Notice: Undefined offset: 7” and “Notice: Undefined offset: 8” errors when I try to use this with phpthumb. I can get the older extract_url plugin to work, but it only extracts the full url, and I need to be able to extract just the file name or the file path.

{photo} is a custom field I’m using for links to the product photos

Fixed, and updated download.

Hey Dan, I’m hoping your update will address this situation.

I’m trying to implement phpThumb and your plugin (tested unsuccessfully with prior version) to handle image sizing in conjunction with the wiki module.

The wiki file upload process seems to encode image uploads and then uses that code to reference the image rather then the “file_name” and “extension” 

Would the use of “% file_name” alone:

be sufficient to pull the long string representing the file?

OR

would I need to use the “query_string” to pull that code?

Thanks

Shame that you dropped some variables that where handy :’(

% subdomain - (e.g., “www”)
% domain - (e.g., “example”)
% tld - (e.g., “com”)

Lets say http://www.yahoo.com/news/bla

I only want ‘yahoo.com’
Now i have to use the old plugin

Hello, and thank you for this time-saving plugin. The filesize_precision parameter does not work for me; the output is set to the default 2, regardless of what value I ascribe. Here’s the code sample (I’d also been using the exp:extract_url plugin):

(I inserted a space above between the percent symbol and the variables “description” and “file_size” so that the text would not be reformatted by the Forum type engine.)

Everything works but the filesize_precision parameter—not a deal-breaker but it would be nice to format the file size number more appropriately.

(Note: I realize I can rewrite the output using only the exp:zm_extract_url_plus plugin without the previous exp:extract_url plugin, using the alternative syntax given in the plugin documentation, but I want to take care of one stage at a time.)

Thanks in advance for your help.

Hmm, looking at the code I see no obvious failure point. What happens if you try 0 and larger number, say 5?

I did try setting the parameter to “0” but the output remained at the default two (2) decimal places. Also, I had placed more of the actual code in, but because it was an anchor tag, it got stripped. What is posted above conveys the gist of it. Finally, I have checked the surrounding syntax meticulously and validated the entire page via two services just to be sure there were no markup errors.

I will try increasing the parameter value to see if it affects the output, then post my results. Thanks for the suggestion.

EDIT
I changed the parameter value to 4 and the output was the same, 2 decimal places. I also looked in the plugin source code to make sure that the parameter referenced was indeed filesize_precision and not, say, file_size_precision (since there is a variable called % file_size [no space in between % symbol and variable name]).

Thanks again in advance for any help or insight.

EDIT
After the “fix” below, I attempted filesize_precision=“0” and was returned the default 2 decimal places, so it appears that the minimum is filesize_precision=“1”.

OK, I found the solution. For anyone interested, the analysis follows:

1. The custom_field in the weblog is a link (meaning, an anchor tag). To get at the URL value, I used the exp:extract_url plugin. The idea was to process this extracted URL using the 2nd plugin.

2. Obviously, I didn’t use the alternative syntax, because a prior “raw” URL value was not available. And using exp:extract_url within the 2nd plugin’s url parameter, as expected, generated errors. (You never know—it’s like a Hail Mary in football ... just throw it out and hope it works ...)

3. Using the plugin’s show parameter to output the entire anchor link was not possible because I require a conditional to apply a CSS class (class=“pdf”). The anchor tag, therefore, had to be broken up.

4. I used exp:extract_url to get the raw URL. I could have also just used full_url from exp:zm_extract_url_plus, but that involved more typing and more room for typos.

5. I used *two* instances of the exp:zm_extract_url_plus tag, one to get the file extension and one to get the file description and file size.

6. It turned out that, for whatever reason, I had to specify filesize_precision=“1” for both instances of exp:zm_extract_url_plus, even though I didn’t need it for the first instance. If I did this, the setting was respected in the 2nd instance of the plugin.

Sorry to be longwinded—only in the hopes of this helping someone else. Here’s the complete structure of the code (with a space inserted between % and the variable to skirt the Forum’s type engine):

I must be particularly thick but I can’t get this plugin to work :’(

And that’s what the output of zm_extract_url_plus give me:

The most perplexing part is that some of it works since the extension is parsed correctly… Any ideas of what I might be doing wrong?

Thanks!

The example given in the documentation doesn’t match the choice of variables delineated beneath it (may be an editing oversight?).

The variable you should use, according to the documentation, is “% file_name” not “% filename” AND “% file_size” not “% filesize” (*without* the space between the % symbol and the variable name—which has to be inserted to skirt the Forum typography engine).

Hope this helps.

minimal design - 22 February 2008 09:34 AM

I must be particularly thick but I can’t get this plugin to work :’(

{exp:weblog:entries weblog="documentation" orderby="date"}
    <h4>{title}</h4>
    <p>
        {exp:zm_extract_url_plus show="%filename.%extension (%filesize)"}
        <a href="http://my_dev_sites:8888/client/job/uploads/docs/Some_Manual.pdf">My file</a>
        {/exp:zm_extract_url_plus}                    
    </p>                    
    {description}
{/exp:weblog:entries}

And that’s what the output of zm_extract_url_plus give me:

<p>
    %filename.pdf (%filesize)                    
</p>

The most perplexing part is that some of it works since the extension is parsed correctly… Any ideas of what I might be doing wrong?

Thanks!

Thanks for the heads up. I used the example in the plugin usage page in the CP. Looks like dev doesn’t like documentation

Well, anyway, some work like file_name, but file_path or file_size don’t, which are ones I need… at this point it’s faster for me to go w/ PHP…

Thanks again!

Correct. The variable names in the examples (plugin usage pages) are wrong. And as for proper documentation? Oh it exists, just waiting for the damned designer to make up his mind

It would be nice if it were possible to wrap with the tags of this plugin such global variables as {site_url} and {homepage}, and global template variables.

Now wrapping {site_url} or {homepage} or global template variables with Extract URL Plus 2 tags do not change their output. It seems that this is an issue of template parsing order, isn’t it?