If empty field show alternate

[renobird]

Hello all,

If I'm using the {$image->description} to populate the alt attribute, is there a simple method to show {$image->name} if the description field is empty?

Example:

<? $image = $profile->images->first();
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->description}' />";
?>

[netcarver]

Tom,

try this (untested)...

<? $image = $profile->images->first();
$alt = ($image->description) ? $image->description : $image->name;
    echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$alt}' />";
?>

[Pete]

Try this:

<? $image = $profile->images->first();
	echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='" . ($image->description ? $image->description : $image->name) . "' />";
?>

Hehe, posted at the same time more or less netcarver

[renobird]

Steve,

Perfect! And that makes complete sense. I was thinking there might be some fancy way with the API.

Thanks for the quick reply. I'm sorting out PW methods for all the things I do in TXP with tags like chh_if_data.

[netcarver]

Yeah, I'm working on some reusable bits here too -- think zem_contact_reborn for PW.

[Pete]

Yup - I didn't need the !empty() bit in mine it turns out so I'll nip back and edit that post to avoid confusion.

[netcarver]

Yup - I didn't need the !empty() bit in mine it turns out so I'll nip back and edit that post to avoid confusion.

Hi Pete,

I think yours was a more explicit way of doing it though.

BTW, how's sunny Chester? You're not far from my parents there.

[renobird]

Thanks Pete!

I was initially trying something with !empty(), but it was getting too verbose — I forgot about ternary operators.

My PHP skills are pretty rough.

[renobird]

think zem_contact_reborn for PW.

Wow! You planning on releasing that as a module? *fingers crossed*

[netcarver]

Tom,

Re: release as a module -- I don't know yet. I only started playing with PW a few days ago so I'm learning my way around it too. I doubt I can come up with something as flexible as that right now. What I do have a simple contact form class working right now from my glue.php include. However, it uses classes from another fantastic PHP project called flourish, so an install of this solution is not a one-stop shop. It's reusable for me 'cause I'm used to flourish but might not be reusable to everyone.

BTW, I highly recommend looking at flourish, i.m.o it is a PHP project par-excellence & the documentation is fantastic.

[Pete]

Tom - I only found out about ternary operators last year I think (I must have been under a rock until then). They have their uses but sometimes I end up over-complicating things with them by trying to nest them and do weird stuff you would usually see in an Excel formula - whichever produces the more readable code is usually the best way, though in this case it's pretty legible either way.

I keep forgetting that PW already handles empty fields well so the check is unnecessary.

Steve - Chester's not bad thanks. Certainly wasn't sunny last weekend, but looks like it will be this weekend - that must make it beer o'clock at some point on Saturday avo Whereabouts are you?

As for Flourish, before I lost a load of data in a hard drive failure (my poor SSD!) I actually had an integrated email fetcher type program sitting in the PW admin page. The idea was that for one project I was going to have it list the last 10 email titles and they opened up in a modal window when clicked. I had this working and even submitted comments to add a sort option to the mail functions with Flourishlib (rather bizarrely, if you access a mailbox and pull out 10 emails it pulls out the oldest 10 rather than the newest 10 - I can't think of any reason why you would want the oldest mail from an inbox Sadly that code hasn't been implemented but it's in the bug tracker system there if anyone needs it).

It is an excellent library indeed.

I am also using Google's PHP API on a project at the moment and was unsure of the best place for it so it doesn't just get tied to one module's folder.

I suspect we could do with some sort of convention for this - perhaps a site/lib folder? That way you could single-file modules in site/modules and multi-file modules in site/modules/your-big-module using one set of library files rather than packaging each module with the same libraries over and over).

I know that you can pretty much do whatever you want with ProcessWire, and that's part of the beauty of the system, but I think that as more modules are developed with 3rd party library dependencies it might be best if everyone agrees on where to put them, and maybe (just throwing this out there) have an empty site/lib folder in the master branch for PW on GitHub?

What do other module authors think? I understand an empty folder could cause confusion, but that can easily be fixed by sticking a readme file in it clearly explaining its purpose.

[Soma]

you can also do this:

$image = $profile->images->first();
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";

in PW you can also access values of fields using get(). Adding a | between multiple names will return the first populated behaving like an "or" operand.

echo $page->get("headline|title");

[renobird]

Soma,

Thank you! That's the kind of solution I was hoping the API would provide.

The headline|title is a great example too, I'll be using that for sure.

[netcarver]

you can also do this:

$image = $profile->images->first();
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";

in PW you can also access values of fields using get(). Adding a | between multiple names will return the first populated behaving like an "or" operand.

echo $page->get("headline|title");

Ooooooooo, nice!

[Adam Kiss]

you can also do this:

echo $page->get("headline|title");

Ooooooooo, nice!

+1

[Soma]

I suspect we could do with some sort of convention for this - perhaps a site/lib folder? That way you could single-file modules in site/modules and multi-file modules in site/modules/your-big-module using one set of library files rather than packaging each module with the same libraries over and over).

I know that you can pretty much do whatever you want with ProcessWire, and that's part of the beauty of the system, but I think that as more modules are developed with 3rd party library dependencies it might be best if everyone agrees on where to put them, and maybe (just throwing this out there) have an empty site/lib folder in the master branch for PW on GitHub?

What do other module authors think? I understand an empty folder could cause confusion, but that can easily be fixed by sticking a readme file in it clearly explaining its purpose.

I was also thinking about this the other day while developing modules.

I'm not sure about the best way but this sounds like a good way I already did in my projects (/site/libs/). Though I'm not sure what is if the one module uses the same lib as an other one, but needs an different version of it?

[Pete]

You're right there - that could cause issues, but what I don't like in other projects (and PW does this as well actually thinking about it) is when you have lots of different TinyMCE folders over time, each one with a different version number, so I'm not sure how that should be handled.

The problem is if you start having too many different versions then you may as well not bother and stick the library in the module folder.

I don't think that there will be too many modules requiring third-party libraries though - the two that I can think of at present are Flourish and the Google API, but I don't need the Google API for my YouTube module any more (going to use that open video thingy - can't remember what it was called bu it could grab from any video site) so it's just Flourish really. I think most good libraries will maintain some backward compatibiity anyway - just thinking about PHPMailer as well which I've been using for years and the dozen or so versions I've used all had the same function calls so there was no real issue.

I think it might be interesting to have some checks in modules - suggest a minimum version for a library and somehow be able to check the version (I think most good libraries will give you access to a version number via some form of function wouldn't they?). In that case we should probably come up with a few good functions for modules to check versions of the main libraries we would use as and when we write modules for them.

I know this might seem a bit overkill, but I really like the idea of having a module check for library dependencies and simply show a message if the user either doesn't have that library or if it isn't a high enough version. To me that is much more preferable to less technical users installing modules and facing a broken website and assuming the module doesn't work.

It is then up to module authors to keep their modules working with the latest versions, but in the case of Flourish and PHPMailer they're quite good at being backwards-compatible like I said.

[netcarver]

Steve - Chester's not bad thanks. Certainly wasn't sunny last weekend, but looks like it will be this weekend - that must make it beer o'clock at some point on Saturday avo Whereabouts are you?

Apologies for the slow reply, was up near you last two days and offline. I'm down in South Gloucestershire.

As for Flourish, before I lost a load of data in a hard drive failure (my poor SSD!) I actually had an integrated email fetcher type program sitting in the PW admin page. The idea was that for one project I was going to have it list the last 10 email titles and they opened up in a modal window when clicked. I had this working and even submitted comments to add a sort option to the mail functions with Flourishlib (rather bizarrely, if you access a mailbox and pull out 10 emails it pulls out the oldest 10 rather than the newest 10 - I can't think of any reason why you would want the oldest mail from an inbox Sadly that code hasn't been implemented but it's in the bug tracker system there if anyone needs it).

It is an excellent library indeed.

Ah, so that was you.

I suspect we could do with some sort of convention for this - perhaps a site/lib folder? That way you could single-file modules in site/modules and multi-file modules in site/modules/your-big-module using one set of library files rather than packaging each module with the same libraries over and over).

I know that you can pretty much do whatever you want with ProcessWire, and that's part of the beauty of the system, but I think that as more modules are developed with 3rd party library dependencies it might be best if everyone agrees on where to put them, and maybe (just throwing this out there) have an empty site/lib folder in the master branch for PW on GitHub?

What do other module authors think? I understand an empty folder could cause confusion, but that can easily be fixed by sticking a readme file in it clearly explaining its purpose.

I guess there could be a convention for locating 3rd party libraries but, as mentioned, versioning would need to be handled and here's another variable to mi into the pot: I like to keep my code outside the site root where possible. I haven't tried this yet with a PW install but I presume it is possible to do. Whatever the scheme/convention (if) introduced, I'd like to see it be able to handle easy relocation outside of site roots and also handle multi-site installations.