plugin: Subsegment

So, what’s the advantage of using such a sub-segment instead of regular segments? I really am curious, were you running into limitations with the permitted number, 9? What particular itch were you scratching here, so to speak?

Perhaps you should call the parameter “separator” or something, instead of simply “string”? Also, I probably wouldn’t want to use * or ~ or #, but is there a reason to disallow “|” or “:” as separators?

Hiya,

Sounds like an interesting little plugin but I’m having a hard time thinking of a use for it at the moment. Why would you want to take a segment and then get part of it? Is there some way of using segments that I am missing somewhere. Don’t suppose you could post a quick real-world example just to get my thick skinned head around this could you?

Thanks for creating it though, I’m sure that when I totally understand the uses for it I will be using it!! 😉

Best wishes,

Mark

Hi Ingmar and Mark,

Thanks for comments and suggestions.

Really, naming parameter “separator” makes much better sense than naming it “string”.

Concerning chars included in separator strings: it seemed to me that some validation is needed and some chars should be considered as illegal. Which chars should be illegal, I was not sure and included in the list of illegal chars those which I never saw used in url segments and would not use by myself. Maybe somebody could propose some consistent list of such chars?

Now I have uploaded version 1.01 of Subsegment plugin in which “string” parameter is changed into “separator” and both “:” and “|” chars are removed from illegal chars list.

I have anticipated that the idea for such plugin may seem strange in the situation when EE supports even 9 url segment variables. Well, let’s consider this real world situation.

There are on the website several similar publishing projects. Each project uses the same set of templates and weblogs. Each page beyond page-specific data displays some data about project. Titles and url_titles are for most entries are standard, such as “article_1”, “articles_5_7” etc.; entries which belong to different projects may have the same title. Since url_titles should be unique and human-friendly, there is a need for some consistent policy in giving url_titles; to ensure uniqueness of url_titles by appending random chars is not acceptable. It seems that quite natural in this situation is to append project name to each url_title, so that instead “articles_5_7” we would have something like “project_name-articles_5_7”. And since each page should display some data about the project, it seems quite natural that information which project it should be should be parsed from url_title.

Yes, some characters are illegal in URLs, but you still might come across them and seaparate segments by that character. The colon could be useful for working with a wiki, eg, and the vertical bar is used by some APIs I know of, like the Google Charts API.

I have updated the plugin Subsegment. You can download version 1.1 using the link on top of the page.

The changes are as follows.

Now you can use optionally either single {exp:subsegment} tag or variable {subsegment} within {exp:subsegment}{/exp:subsegment} tag pair. In both cases the output will be the same.

The use of variable {subsegment} within {exp:subsegment}{/exp:subsegment} tag pair is more powerful because you can use it’s output as parameter of other tag. For such use you must add parse=”inward” parameter to {exp:subsegment} tag.

For example, code as this will work

{exp:subsegment segment="3" separator="-" index="1" parse="inward"}
{exp:weblog:entries weblog="my_weblog" url_title="{subsegment}"}
Some code
{/exp:weblog:entries}
{/exp:subsegment}

As allways, any suggestions appreciated.

I have updated the plugin Subsegment. You can download version 1.2 using the link on top of the page.

In this version a new parameter - ‘on_failure’ - was added. This parameter is optional and accepts as its value either ‘segment’ or any string which consists from characters legal for use in ExpressionEngine’s tag parameter values. It allows you to specify what {exp:subsegment} tag will output in case needed subsegment was not found.

If subsegment does not exist the tag by default returns nothing. In case ‘on_failure’ parameter is defined and ‘segment’ is its value, then the tag will output segment, if segment exists. If ‘on_failure’ parameter has some other string as its value, then that string will be outputted.

Why there is a need for such parameter?

Consider the code as this:

{exp:subsegment segment="2" separator="-" index="0" parse="inward"}
{exp:weblog:entries weblog="my_weblog" url_title="{subsegment}" dynamic="off"}
<h1>{title}</h1>
{body}
{/exp:weblog:entries}
{/exp:subsegment}

If needed subsegment does not exist, then the value of ‘url_title’ parameter of {exp:weblog:entries} tag will be empty string, and {exp:weblog:entries} will output all entries from ‘my_weblog’ weblog. This may not be what you want. Most probably in case needed subsegment does not exist you will want that {exp:weblog:entries} tag would not output anything. This can be achieved by specifying some string as a value of ‘on_failure’ parameter. This value will become the value of ‘url_title’ parameter and {exp:weblog:entries} tag will not output anything.

1.2.1 - bug fix release.

Serious bug fixed: on_failure parameter causes result to be displayed as output of entire {exp:subsegment} tag instead of as output of {subsegment} variable.

Everyone who uses or plays with this plugin is recommended to upgrade.

1.3 - new version.

The changes are as follows.

“Index” parameter was made optional.

New variables {subsegment_0} - {subsegment_8} were introduced.

Now {exp:subsegment}{/exp:subsegment} tag pair can output several subsegments. For example, if segment_3 is /project_5-article_7-section_6/ then the code

{exp:subsegment segment="3" separator="-"}
{subsegment_1}, {subsegment_2} 
{/exp:subsegment}

will output the string “article_7, section_6”.

1.3.1 - bug fix release.

A minor bug was fixed - string specified as a value of “on_failure” parameter not being displayed in case needed segment not found.

Hi,

I have released a version 1.4 of Subsegment plugin.

In this release parameter “invalid_input” was added. This parameter accepts two values: “alert” and “silence”. Default value is “silence”. If the value is “alert”, then in cases when some parameter’s value is invalid plugin exits and PHP alert is being shown; if the value is “silence”, then in cases when some parameter’s value is invalid the plugin finishes its work without any alert being shown. Set this parameter to “alert” for development, and to “silence” - for deployment.

Since the plugin does not do comprehensive validation of parameters’ values, you cannot be absolutely sure that in cases no alert was thrown the input was really valid.

You may ask, why parameter “invalid_input” was needed there already “on_failure” parameter being available. The answer is, these parameters have different purposes. Using parameter “invalid_input” you can specify what plugin should do in case it considers some parameter’s value being invalid; using parameter “on_failure” you can specify what plugin should do in case it considers all parameters’ values being valid, but has found nothing to output.

Man I really want to use this plugin, but it doesn’t seem to work within ‘{if}’ tags…

Man I really want to use this plugin, but it doesn’t seem to work within ‘{if}’ tags…

Can you post an example of your code?

Or better still use the prep_conditionals function.

Prep Conditionals Documentation

Best wishes,

Mark

Yep you’re right it will work but not always recommended due to certain security implications depending on what you are doing exactly.

Might be alright in this case though.

Best wishes,

Mark