Module: PageListBetterLabels

[adamspruijt]

So with all the love I have for ProcessWire page labels have always been a little less awesome than I hoped. Say like in the Skyscrapers profile you want to show the height of the tower along side the tower name, the output will end up something like:

Cool Tower Name, 780

To me this just isn't good enough and doesn't always offer a lot of value to the end-user/client, so I made "PageListBetterLabels". Which gives you the power to output something like this:

That there is done with this (as the setting for "List of fields to display in the admin page list" setting under advanced):

images title height --ft -tall floors -floors Opened- In- the- year- year

How it works

• anything that starts or ends with a dash does not get processed as a page field
• anything with the dash(s) at the beginning gets appended to the field before it
• anything with the dash(s) at the end gets prepended to the field after it (I hope this makes sense)
• one dash means leave a space, two means don't

I used Soma's PageListImageLabel module as a starting point for supporting Image labels in this module, so a big thanks goes out to him and his wonderful work (I simplified the options in my implementation, to get things up and running). I mostly added this feature as I assumed the two would not work together, I may be wrong though.

I will add this to the modules directory, right now I need to pick up my Wife from work.

DOWNLOAD

[arjen]

I mostly added this as I assumed the two would not work together, I may be wrong though.

I like that there is almost no overlaps/duplication in functionality regarding modules.This seems to extend/combine two modules: FieldtypeConcat and PageListImageLabel. Although the three also have different functions, I think it's good to keep a sort of distance between the modules. I hope you understand what I mean.

That said: GREAT WORK. Looking really nice and I can see a lot of use for me. So, thanks for creating this!

[nikola]

Great plugin!

There seems to be a problem with Thumbnails module when using in conjunction with this plugin, it throws:

There is no thumb called:

Normal image field type works fine.

[Soma]

Great adam, thanks for the plugin. There's seems to be a lot of tree/label plugins lately that could be maybe merged together, not sure that would work or make sense.

I'm not too sure about the various string configuration as being to complicated. Also I think the the Module name is strange: "..Better.." is that really needed?

[adamspruijt]

Great adam, thanks for the plugin. There's seems to be a lot of tree/label plugins lately that could be maybe merged together, not sure that would work or make sense.

I'm not too sure about the various string configuration as being to complicated. Also I think the the Module name is strange: "..Better.." is that really needed?

I simplified the options as a matter of personal preference, not because I thought you had too many, I can see the pros/cons of either approach, also the name "Better" is only in reference to the original implementation, though maybe a word like "Configurable" or "Advanced" would be a better choice.

Great plugin!

There seems to be a problem with Thumbnails module when using in conjunction with this plugin, it throws:

There is no thumb called:

Normal image field type works fine.

Thanks nikola, I will take a look at this, I don't use the thumbnail module on all my projects so I will test it with one ASAP and fix.

[adamspruijt]

Great plugin!

There seems to be a problem with Thumbnails module when using in conjunction with this plugin, it throws:

There is no thumb called:

Normal image field type works fine.

Hey nikola, from what I tested this only happens when the subfield for the "CropImage" field has not been defined and seems to be consistent with the behaviour of Soma's PageListImageLabels where I snagged the code. I added a condition to only attempt to get the thumbnail if a subfield has been provided, so now if none is provided the Module will fall back to using the source image file for the CropImage fieldtype.

ALSO: Updated the Module to have joining support.

Example if you want something like:

260 x 420

you would use

"fieldname -x- fieldname" (or "fieldname --x-- fieldname" if you dont want the spaces)

I hope that makes sense

[diogo]

i think the idea is great but the implementation is not very intuitive. did you try to make the other way around? i mean, what is inside something is processed, and what is outside doesn't. brackets would be good candidates, just like in php.

[adamspruijt]

i think the idea is great but the implementation is not very intuitive. did you try to make the other way around? i mean, what is inside something is processed, and what is outside doesn't. brackets would be good candidates, just like in php.

For sure, that was how I had originally planned this Module, something like: 

fieldname fieldname {Label} fieldname {Label}

problem is that all type of brackets get sanitized, I suppose that there could be a way around this but I feel the implication of playing with the input sanitization could be much more complex than the solution I've gone with.

[diogo]

I was even thinking of

{fieldname} {fieldname} Label {fieldname} Label

but I can imagine that it makes it more difficult...

Anyway, If the brackets are sanitized, couldn't you do the str_replace() using { and } instead?

[adamspruijt]

I was even thinking of

{fieldname} {fieldname} Label {fieldname} Label

but I can imagine that it makes it more difficult...

Anyway, If the brackets are sanitized, couldn't you do the str_replace() using { and } instead?

The only special characters that are not sanitized are dashes and underscores.

Not only that but, that would look like a horrible mess wouldn't it? Also there needs to be a method to determine which separator get skipped, so that the system can determine whether to append or prepend the "label". Inevitably using brackets would only have the effect of seeming more like "natural language", but the technique would still be rather complex.

Either way this isn't a client facing feature, so I decided working within the constraints made more sense than overriding too much of the default behaviour of processwire.

Also:

UPDATE 1.0.4 - image subfields are no longer processed into thumbnails, so you can properly output the image height, width, filename, filesize etc at text.

[Soma]

I also did ran against this when creating my modules. I'm not really sure why it is there but this maybe a good time to ask Ryan Is it really needed or can it be changed so we have more options.

One way is to completly replace the label rendering method $event->replace = true; and then use your own.

[ryan]

I also did ran against this when creating my modules. I'm not really sure why it is there but this maybe a good time to ask Ryan   Is it really needed or can it be changed so we have more options.

We can open this up so it doesn't filter out brackets. But it would only be in 2.3+, so this module should probably stick with the current method for the moment. 

[owzim]

Awesome module.

That's what I wanted the other day, looked if there is a module for that, and yep there is =)

One thing though:

A date field is output as unix timestamp and not in the format which is set in the field settings.

[jacmaes]

@owzim I noticed that too, and a fix would be much appreciated.

[owzim]

@owzim I noticed that too, and a fix would be much appreciated.

A quick an dirty fix would be to comment out line 39 in the PageListBetterLabels.module, but this would activate formatting for all other fields as well, which is not ideal.

// $page->of(false);

I have not yet found out how to do it only for that specific date field type in that module, because I am not yet familiar enough with the API.

[adamspruijt]

@owzim  the default method for rendering PageList labels doesn't turn of OuputFormatting so I'm not certain why I did, it might have been for something I was planning to add? So I pushed the update with your suggestion, thanks for pointing this one out guys! Cheers!

EDIT: Looking again, I might be wrong about the default not turning off formatting... but it doesn't seem to cause an issue. I will continue to play with it....

[adamspruijt]

Ok so, output formatting need to be false in order for the image thumbnails to output correctly, but needs to be on for dates. So I turned it off and format the dates not be manually retrieving their "date format" setting. Thanks for pointing out the issue guys.

Update pushed to Github and updated on the Modules pages.