One thought is to display just the “browsers tested in” without version (IE & maybe Safari would still carry a version) this will represent the fact that it was tested in the version of those browsers current at the publishing time.
If version numbers are mostly left out then would that encourage authors to just test with the latest? We ought to be testing with every browser, version, OS and device size/orientation that people realistically use. Why not have checkboxes for the browsers and space by each for minimum version tested with. That way the author can reassure the buyer about compatibility.
99% of the time if it works with an older version it will work with the latest version, even if that version is 5 years newer, so I think it’s fairly safe to say something like “IE 8+” rather than “IE 8 – 9” for the sake of not having to update the version manually. There is that 1% case in which something will break on a newer version but if the author is doing their job they’ll have it fixed in no time anyway.
I’ll add one more in case there ends up being a demand:
I’ve worked on a couple church themes and for publishing sermons I use a multimedia CPT with fields allowing for Audio, Video and PDF . The taxonomies cover Category, Tag and Speaker. By using generic names (Multimedia instead of Sermon and Speaker instead of Pastor, for example), non-church websites have used the theme for presentations and teaching of various types.
Here are some other CPT ’s I’ve used and have seen in use frequently:
- Staff – position field (aka Job Title)
- Locations – address, hours, phone number(s), map data
For Events, custom fields I’ve used are Start Date, End Date, Time, Venue, Address and Map details.
psvent saidId think testimonials would be a separate CPT as there generally used in two different areas in sites
What about “client_testimonial”?
Definitely a necessary CPT . Maybe that’s what was meant. Originally I thought psvent had meant as a portfolio field but of course they said nothing of the sort.
UPDATE : For testimonial fields I have used just one and that is “Below Name” which is useful either for their location, business name, etc.
Thanks for clearing that up. A country of countries? And if Scotland is a country then where’s its ISO code? http://www.spoonfork.org/isocodes.html
Frankly my friends, it’s time to declare independence. I mean come on, what on earth does Canada need with the queen? And Australia still has the union jack in the corner of their flag!
Look, if you find yourself in a situation like this:
Then it might be time for some of this:
My two cents.
I wouldn’t want to cover all the fields that might be needed. I’m looking for fields that’d pass the 80/20 rule here.
Let’s see if a Video URL field would fall into the 80/20 rule. I’m not sure how most others add video items to their portfolio CPT ’s but I setup a single URL field for YouTube, Vimeo, etc.
greenshady saidOften used post types can be ‘standartized’, but the fields which go with those types – not. You cannot cover all the fields that MIGHT be needed for a custom theme. What then? ...
Why would you not include meta fields? I’m thinking “date” and “URL” are definitely fields that are needed for portfolios. I honestly haven’t done too much work in this space though.
True there is a wide array of custom fields that could be used with a portfolio CPT so why not include a large set of them, then provide an easy way for the theme to enable or disable the use of certain fields as needed? That way maybe 90% of portfolio themes will find the fields they need. The other 10% could then propose/contribute additional custom fields as needed. Yeah?
Underwater furniture museum. Cool.
Must be in Dubai.