WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 16 months ago

#11394 closed feature request (wontfix)

Image shortcode

Reported by: caesarsgrunt Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Media Keywords:
Focuses: Cc:

Description

Add a shortcode for images, rather than inserting static html code into posts/pages.

This complements the media stuff being done in 3.0 and has many benefits, including

  • allowing images to be trashed
  • allowing plugins and themes to modify the code used to show images
  • removing broken img tags from posts when the image is deleted

As discussed on dev chat 10-12-2009.

Proposed syntax :
Shortcode name : image
Required attributes :

  • id - the id of the image

Optional attributes :

  • align - left|center|right - default to none (inline)
  • size - thumb|medium|full - default to thumb
  • title - HTML title/alt attribute - default to value in db
  • width - HTML width attribute - default to width of image
  • height - HTML height attribute - default to height of image

Other attributes are probably also needed, but I can't think of any more at present.

Captions would be handled by the existing caption shortcode.

Other media which is embedded straight in the post would need its own shortcodes (eg [video]), but at the moment other media seems always to only be linked to anyway.
A single [media] shortcode wouldn't be a good solution since every type of media has different attributes and needs to be handled differently.

This solution is backwards-compatible, in that existing image would continue to work, but it might be nice to update existing images to use the shortcode as part of the upgrade process.

Change History (55)

comment:1 pavelevap5 years ago

  • Cc pavelevap@… added

comment:2 follow-up: scribu5 years ago

  • Cc scribu@… added

I would add to the required attributes url for external images. So an image must have either an id or an url attribute.

comment:3 in reply to: ↑ 2 ; follow-up: caesarsgrunt5 years ago

  • Type changed from feature request to task (blessed)

Replying to scribu:

I would add to the required attributes url for external images. So an image must have either an id or an url attribute.

Yes; of course. I should have thought of that. But I'd make it src like the html img tag - otherwise it could be confused with a url which should be linked to. And incidentally, we'd need that too - Id suggest calling it link.

I think "blessed" means it was agreed on in the dev chat, no? So I'll set it to that.

comment:4 in reply to: ↑ 3 caesarsgrunt5 years ago

Replying to caesarsgrunt:

Id suggest calling it link.

Or maybe href would make more sense.

comment:5 follow-up: Denis-de-Bernardy5 years ago

This will generate lots of extra DB queries. Needlessly so.

comment:6 in reply to: ↑ 5 caesarsgrunt5 years ago

Replying to Denis-de-Bernardy:

This will generate lots of extra DB queries.

Some, yes.

Needlessly so.

Not sure about that. I think this is pretty important; there are a lot of problems caused by the current system.

comment:7 pavelevap5 years ago

Image shortcode would be very helpfull for some situations, DB queries can be limited by caching posts, I guess.

comment:8 follow-up: hakre5 years ago

Cache is not a core feature but would it really create that many DB queries? I mean all comes with a price... .

comment:9 in reply to: ↑ 8 caesarsgrunt5 years ago

Replying to hakre:

Cache is not a core feature but would it really create that many DB queries? I mean all comes with a price... .

Would be nice if it was a core feature, IMO...

No, it's not a huge number of extra queries - one per image, in fact.
Alternatively, we could start by scanning the whole post to make a list of images, and then load the data for all of them at once with a single query.

Either way, I think it's a small price to pay for having image shortcodes.

comment:10 follow-up: hakre5 years ago

  • Keywords reporter-feedback added
  • Milestone changed from 3.0 to Future Release
  • Version set to 2.9

I guess this is not only about DB queries but also about querying the file system for image dimensions and so on.

Since this is a shorttag or shortcode, a prototype can be easily created in a plugin. A plugin will help to discuss this feature better as well because it would show how many load it will generated factually. Otherwise everybody might have an own idea on how this looks like and will make own assumptions about the load.

comment:11 scribu5 years ago

+1 on putting it in plugin first.

It would be nice if said plugin would have a feature to replace <img> tags with shortcodes when possible. Similar to the Regenerate Thumbnails plugin.

comment:12 nacin5 years ago

  • Keywords dev-feedback added; reporter-feedback removed
  • Milestone changed from Future Release to 3.0

This appeared to gain traction among the core devs as a 3.0 solution to trash for media. Moving back for now.

comment:13 hakre5 years ago

Not the one the original reported was talking about, but the bbcode plugin does create an image shortcode. Maybe that code is of use as well.

comment:14 pavelevap5 years ago

I found also this plugin: http://wordpress.org/extend/plugins/wpgalleryimage-shortcode/ But it is not very user friendly. Shortcode should be generated automatically by selecting in media library and also shown in visual editor as picture and not shortcode...

comment:15 follow-up: scribu5 years ago

Integrating the shorcode with the visual editor is a must.

Might be a bit trickier to do from a plugin, but then again I never touched TinyMCE code, so I wouldn't really know.

comment:16 in reply to: ↑ 10 ; follow-up: caesarsgrunt4 years ago

Replying to hakre:

I guess this is not only about DB queries but also about querying the file system for image dimensions and so on.

No need to do that, since ic could easily be done at the time of upload and stored in the DB. In fact, isn´t this already done?

Since this is a shorttag or shortcode, a prototype can be easily created in a plugin. A plugin will help to discuss this feature better as well because it would show how many load it will generated factually. Otherwise everybody might have an own idea on how this looks like and will make own assumptions about the load.

-1 to the plugin idea. It would be much harder than just implementing it in core to start with.

comment:17 in reply to: ↑ 16 scribu4 years ago

  • Keywords needs-patch added

Replying to caesarsgrunt:

Replying to hakre:

I guess this is not only about DB queries but also about querying the file system for image dimensions and so on.

No need to do that, since ic could easily be done at the time of upload and stored in the DB. In fact, isn´t this already done?

Indeed. The file system is never "queried" after the thumbnails have been created.

Since this is a shorttag or shortcode, a prototype can be easily created in a plugin. A plugin will help to discuss this feature better as well because it would show how many load it will generated factually. Otherwise everybody might have an own idea on how this looks like and will make own assumptions about the load.

-1 to the plugin idea. It would be much harder than just implementing it in core to start with.

Then I guess we need a basic working patch to base further discussion on.

comment:18 nacin4 years ago

  • Milestone changed from 3.0 to 3.1
  • Type changed from task (blessed) to feature request

Moving back out to 3.1.

comment:19 in reply to: ↑ 15 mikeschinkel4 years ago

  • Cc mikeschinkel@… added

Replying to scribu:

Integrating the shorcode with the visual editor is a must.

+1

comment:20 follow-up: Otto424 years ago

Instead of using an image specific shortcode, I'd prefer shortcodes for specific URLs that could be put into posts. Example:

<img src="[homeurl]/wp-content/uploads/whatever.jpg" />

We could have contenturl, pluginurl, homeurl, siteurl, etc. Each of these is a relatively simple single line function for a shortcode. It would serve to make the content less dependent on the absolute URL, but not too dependent on the shortcodes (since a simple search/replace of [homeurl] with the actual URL could fix up the content in the database).

Plus, it's simple enough to be applicable to more than just the image/upload handling functions.

comment:21 peterchester4 years ago

  • Cc peterchester added

Let me start by saying I'm 100% into this whole idea! I love it!

I like Otto42's suggestion. That allows from optimal flexibility in the image tag.

If we did do a complete image shortcode, i would like to propose that we offer support for things like "rel" or maybe an attribute for thickbox.

comment:22 in reply to: ↑ 20 ; follow-up: mikeschinkel4 years ago

Replying to Otto42:

I'd prefer shortcodes for specific URLs that could be put into posts. Example:

<img src="[homeurl]/wp-content/uploads/whatever.jpg" />

We could have contenturl, pluginurl, homeurl, siteurl, etc. Each of these is a relatively simple single line function for a shortcode. It would serve to make the content less dependent on the absolute URL, but not too dependent on the shortcodes (since a simple search/replace of [homeurl] with the actual URL could fix up the content in the database).

A big +1.

Can I suggest we instead use an underscore as content_url, plugin_url, home_url, site_url, etc. for readability but more importantly for consistency with function names of the same use, i.e. #9008

comment:23 in reply to: ↑ 22 Otto424 years ago

Replying to mikeschinkel:

Can I suggest we instead use an underscore as content_url, plugin_url, home_url, site_url, etc. for readability but more importantly for consistency with function names of the same use, i.e. #9008

Shortcodes are meant to be typed by users, generally. Having underscores in them makes that confusing/difficult for some users. Dashes, perhaps.

comment:24 follow-up: ipstenu4 years ago

How would this affect people who change their uploads path?

Wouldn't it be better to pull [uploadurl] from wherever the miscellaneous stores it? That way, if you changed the location, it would magically update.

I don't know how this would work with Multi-Site, though, since as of 3.0, you can't change that setting easily.

comment:25 in reply to: ↑ 24 Otto424 years ago

Replying to ipstenu:

How would this affect people who change their uploads path?

Wouldn't it be better to pull [uploadurl] from wherever the miscellaneous stores it? That way, if you changed the location, it would magically update.

No, bad idea. Changing the upload location in the settings page doesn't actually move the files around, it just makes new files go to the new place.

comment:26 caesarsgrunt4 years ago

I'm afraid Otto's suggestion basically defeats the object of this suggestion in the first place, since the only thing it allows to change dynamically is the siteurl. Looking back to the original ticket, advantages which wouldn't be supported with Otto's system include:

  • allowing images to be trashed
  • allowing plugins and themes to modify the code used to show images
  • removing broken img tags from posts when the image is deleted

In fact; all the advantages I listed. So, what's the point?

comment:27 caesarsgrunt4 years ago

Also, note that the original suggestion would include all functionality offered by Otto's suggestion as well as the functionality originally intended.

comment:28 follow-up: caesarsgrunt4 years ago

If you're opposed to an image specific shortcode, I'd agree that it might be a good idea instead to have a generic media one, since most of the attributes will be similar for all media.

comment:29 in reply to: ↑ 28 Otto424 years ago

Replying to caesarsgrunt:

If you're opposed to an image specific shortcode, I'd agree that it might be a good idea instead to have a generic media one, since most of the attributes will be similar for all media.

Not opposed to it, as such, I just wanted to make it more generic and useful for more than just media.

I don't like shortcodes in general, because IMO they pollute the content with site and/or system specific bits. The content can be displayed on the website, or in a feed, or pulled out and merged into other bits... I'd just like it to remain relatively pure and capable of being displayed in different ways. Shortcodes lock the content into an implementation-specific system.

But they do good things too, so while I think they're evil, I can see that they're a necessary evil.

With an media specific shortcode, you're locking the content to that database and implementation specifically. If you move the content to another system, it ceases to work. Images don't show. Links get broken or are not there. Etc, etc..

In other words, my problem with the original suggestion is that I think [image] is a worse thing to have in the database than <img src...>, because HTML has a defined meaning outside of the database and WordPress and is well understood across multiple types of systems, but shortcodes only work in WordPress, with this specific code, with this specific theme/plugin, etc.

This may be a problem with no perfect solution, I grant you, but I'd like to make any content produced by the core still have some form of meaning and to display at least semi-properly even when the shortcodes are not processed.

comment:30 mhbarr4 years ago

  • Cc mhbarr added

One advantage to Otto's option is that it would only use cache'd data from the options table. No extra DB access if I'm reading things correctly.

My primary concern in all of this is to achieve more independence from hard coded URL's. Either solution is just fine w/ our environment, and we'll be happy with *a* solution, vs the present state.

comment:31 caesarsgrunt4 years ago

@mhbar: Problem is, Otto's option doesn't solve any of the original problems! It just solves the minor problem of changing the siteurl (which would also be solved by the shortcode). ;-)

@Otto: I agree that the shortcode has certain (minor IMO) disadvantages, but most of the problems you mention can be immediately solved by making the export function parse the shortcode (maybe it does already even?)

In this case, I think that as you say the media shortcode is a "necessary evil", since it solves far more problems than it creates.

Can you think of another solution that would solve the original problems? Obviously it's possible to parse every post upon deleting an image, and remove the code. That would solve one of the problems, but it would be a horrible and resource-intensive way to go about it. The shortcode would be much better than that.

Maybe we should have a poll or something? This is clearly an extremely important decision, since it affects the entire media handling of WordPress, and a couple of us discussing the benefits/problems of each system won't necessarily get something which makes the most people happy...

comment:32 Otto424 years ago

Okay, the difference here is that I don't see any of those as real "problems".

There is fundamentally no real difference between [image align=right url=whatever] and <img style="align:right;" src="whatever" />. They are both amenable to machine creation and parsing. They both mean the same thing. Except that the HTML way works without further processing power being applied to it.

If you want to scan through posts and recognize faulty images to deal with trashed ones, then you can do so without a shortcode. Merely stick a class="attachment-123" on every image. Have a filter on the content look for images with that attachment class, and then remove the images which have been trashed. It's practically the same code, except you're using a regexp instead of a shortcode (which get found by regexps anyway).

You're wanting to change the way images are held in posts, and then build image tags. I'd rather you simply attacked the problem directly instead of coming at it sideways. There's better ways to solve all the "problems" you mention without breaking the current content model.

comment:33 follow-up: caesarsgrunt4 years ago

So you suggest duplicating the shortcode parser to parse HTML tags instead of shortcodes, so that we can remove the html tag on the fly if the image doesn't exist? It's an idea, but probably a lot more work than a new shortcode and it strikes me as a rather messy solution. Does anyone else have an opinion on this? Is anyone willing to try implementing it? (I don't have time right now.)

comment:34 in reply to: ↑ 33 Otto424 years ago

Replying to caesarsgrunt:

So you suggest duplicating the shortcode parser to parse HTML tags instead of shortcodes, so that we can remove the html tag on the fly if the image doesn't exist? It's an idea, but probably a lot more work than a new shortcode and it strikes me as a rather messy solution. Does anyone else have an opinion on this? Is anyone willing to try implementing it? (I don't have time right now.)

Actually, it's a lot LESS work, because you won't have to modify the media system to create shortcodes as well.

Also, we have a pretty darned good HTML parser built right into the system. Look closely at kses. Finding the img codes in the content is trivial, parsing them into attributes is relatively easy with kses, and then taking action to then remove the img tag on the fly is relatively easy as well. The hard part is looking in the database to find trashed images.

comment:35 sbressler4 years ago

  • Cc sbressler added

I frankly don't know whether a [media] or [image] shortcode is necessary or useful in WP. I always thought it was kind of strange that [caption] is a shortcode that surrounds an <img> tag if there is one. No one has brought this up: with this solution, would the caption shortcode surround the image shortcode, duplicating the alignment, width, and height attributes?

I created a Media Credit plugin last month that I'm still actively developing and I figured I'd mention here. I am by no means trying to promote my plugin here, but just want to discuss my experiences from creating this plugin. In terms of shortcodes, this plugin takes a similar approach as is discussed here, but stricly for attributing media to a specific user.

In addition to allowing media to be credited to a blog user or any freeform text upon upload (autocomplete for blog users), the [media-credit] shortcode inserted into posts is parsed into displaying media credit below images (above captions) with a link to a particular user's author.php page if the media is credited to a blog user.

I indeed had to duplicate the three attributes from the caption shortcode as mentioned above so that I could determine the width of the media credit to display under an image.

I would love to hear some more thoughts from more of you, particularly core contributors, as to what you think about such an image shortcode.

comment:36 follow-up: caesarsgrunt4 years ago

There are already attributes duplicated between the [caption] shortcode and the <img> tag. If we kept the [caption] shortcode separate, then these would still have to be duplicated. On the other hand, if we were to give the [image] shortcode a caption attribute, then we needn't wrap it in the [caption] shortcode and the attributes wouldn't need to be duplicated.

In my mind the current system is very messy, and an [image] or [media] shortcode would allow us to tidy it up immensely.

comment:37 in reply to: ↑ 36 ; follow-ups: Otto424 years ago

Replying to caesarsgrunt:

There are already attributes duplicated between the [caption] shortcode and the <img> tag. If we kept the [caption] shortcode separate, then these would still have to be duplicated. On the other hand, if we were to give the [image] shortcode a caption attribute, then we needn't wrap it in the [caption] shortcode and the attributes wouldn't need to be duplicated.

In my mind the current system is very messy, and an [image] or [media] shortcode would allow us to tidy it up immensely.

Ugh, absolutely not. Caption is separate from the image for a reason, and it should stay that way.

Look, the image is just the image. But the caption is the box surrounding the image. They are separate in style and display and everything else. The caption shortcode surrounds the image because that's the way it works on the page itself.

If I was to simply delete all shortcodes, then I would still want my img html to be in there. Remember, post content is not confined to being displayed on the website. It's also in feeds, it can be seen in Google Reader, it could be pulled into other things... Shortcodes violate this principle of one-content-multiple-displays, but they tend to do so in a minor and manageable way. If we expand shortcodes to actually *being* content, then we change that dynamic.

I'm -1 to this ticket now, if we're talking about making the media handled by a shortcode. I want my content to be at least mostly free of being generated by the WordPress core code. I'd rather not have to process it through WordPress just to make it capable of being displayed elsewhere.

comment:38 in reply to: ↑ 37 ; follow-up: mikeschinkel4 years ago

  • Cc mikeschinkel@… removed

Replying to caesarsgrunt:

In my mind the current system is very messy, and an [image] or [media] shortcode would allow us to tidy it up immensely.

+1

Replying to Otto42:

Replying to caesarsgrunt:
Ugh, absolutely not. Caption is separate from the image for a reason, and it should stay that way.

Look, the image is just the image. But the caption is the box surrounding the image. They are separate in style and display and everything else. The caption shortcode surrounds the image because that's the way it works on the page itself.

Shortcodes need not equate one-to-one to underlying implementation. A user doesn't think of them as two things; they think of them as a picture that has a caption. Using the same logic we would argue against a single [calendar] shortcode preferring instead [calendar] surrounding [week]s that surrounds [day]s. Requiring image and caption to be separate is similarly favoring pedancy over usability and content mantainability.

I'm not saying that there shouldn't be an option to use a caption separately but forcing them to be separate simply adds a burden on the user while providing almost no value to anyone that I can see.

If I was to simply delete all shortcodes, then I would still want my img html to be in there. Remember, post content is not confined to being displayed on the website. It's also in feeds, it can be seen in Google Reader, it could be pulled into other things... Shortcodes violate this principle of one-content-multiple-displays, but they tend to do so in a minor and manageable way. If we expand shortcodes to actually *being* content, then we change that dynamic.

Forcing separate shortcode for image and caption doesn't address your stated concern. Any image shortcode triggers your concern; with caption as an attribute or caption as a separate shortcode.

While I agree with the value of HTML being HTML and not HTML+Shortcodes the reality is that the WordPress community is heading in the direction of using more and more shortcodes (just look at how many plugins provide them.) Rather that fight it I'd suggest improving the support for shortcodes to make generation of raw HTML easier and to make it easier to add TinyMCE support for shortcodes similar to how images are currently handled in the editor.

I'm -1 to this ticket now, if we're talking about making the media handled by a shortcode. I want my content to be at least mostly free of being generated by the WordPress core code. I'd rather not have to process it through WordPress just to make it capable of being displayed elsewhere.

Rather than fight shortcodes, another option (and I mean "option" as in the user of the site gets to turn this off) would be to have WordPress store two copies of a post, one with shortcodes and one that has raw HTML. It could even be designed where it only stores the copy if a particular post used a shortcode.

comment:39 in reply to: ↑ 37 ; follow-up: caesarsgrunt4 years ago

Replying to Otto42:

Ugh, absolutely not. Caption is separate from the image for a reason, and it should stay that way.

Just to be clear : I wasn't suggesting that the caption and the image necessarily be merged, I was just answering sbressler's question by pointing out that (a) there are already duplicated attributes; this wouldn't be something new introduced by an image shortcode, and (b) the only way of avoiding duplicate attributes altogether is to merge the caption and image tags. I didn't suggest that this actually be done.

Look, the image is just the image. But the caption is the box surrounding the image. They are separate in style and display and everything else. The caption shortcode surrounds the image because that's the way it works on the page itself.

Even if you merged the two shortcodes, the HTML output would be the same as it is currently.

If I was to simply delete all shortcodes, then I would still want my img html to be in there. Remember, post content is not confined to being displayed on the website. It's also in feeds, it can be seen in Google Reader, it could be pulled into other things... Shortcodes violate this principle of one-content-multiple-displays, but they tend to do so in a minor and manageable way. If we expand shortcodes to actually *being* content, then we change that dynamic.

Is the content of the post, as in the database, shown straight in feeds without being parsed at all? If it's parsed anyway then being shown in feeds isn't different from being shown on the site - but I don't actually know whether it is or not. (Out of interest, if it's not, what happens about embedded videos, galleries, etc?)

Why would you simply delete all shortcodes? Obviously, if you delete them, then what they represent won't be there anymore. Do you want your image tags to still be there if you delete all HTML too? If you remove all forms of formatting so you just have plain text? Where do you draw the line?
Besides, there is already a [gallery] shortcode. If you delete it; the images it represents won't be shown anymore. Why's that OK, when a shortcode for individual images isn't?

I'm -1 to this ticket now, if we're talking about making the media handled by a shortcode. I want my content to be at least mostly free of being generated by the WordPress core code. I'd rather not have to process it through WordPress just to make it capable of being displayed elsewhere.

Maybe we should have an option to disable the shortcode - enable it for normal users who are more concerned about ease of use and the enhanced feature set which it helps to enable, and allow advanced users who are more concerned about direct data portability without using an exporter to disable the shortcode. What do you think of that concept?

comment:40 in reply to: ↑ 38 ; follow-up: caesarsgrunt4 years ago

Replying to mikeschinkel:
I agree with everything mikeschinkel said, except that I'm not sure that saving two copies of the post is the best solution - rather, I would suggest adding an option to disable the generation of the shortcode and make WP use HTML tags instead.
Of course, it would still be able to interpret the shortcode, but inserting an image would put HTML tags into the post instead of a shortcode.

comment:41 in reply to: ↑ 40 ; follow-up: mikeschinkel4 years ago

Replying to caesarsgrunt:

Replying to mikeschinkel:
I agree with everything mikeschinkel said, except that I'm not sure that saving two copies of the post is the best solution - rather, I would suggest adding an option to disable the generation of the shortcode and make WP use HTML tags instead.
Of course, it would still be able to interpret the shortcode, but inserting an image would put HTML tags into the post instead of a shortcode.

I'm actually not sure that saving two copies is a good idea either, there are pros & cons to any solution. Saving two copies solves the display performance problem and Otto's "I want everything to stay as HTML" desire but does cause other issues.

As for an option to disable shortcodes, I don't think that is really a viable option considering how many things can be done with shortcodes from plugins. Disabling them stunts far too much available functionality.

comment:42 in reply to: ↑ 41 ; follow-up: caesarsgrunt4 years ago

Replying to mikeschinkel:

As for an option to disable shortcodes, I don't think that is really a viable option considering how many things can be done with shortcodes from plugins. Disabling them stunts far too much available functionality.

I just meant an option (a wp-config.php constant) to disable this particular shortcode, so that for people like Otto who don't like it, they can keep the current behaviour.

comment:43 in reply to: ↑ 39 ; follow-up: Otto424 years ago

Replying to caesarsgrunt:

Is the content of the post, as in the database, shown straight in feeds without being parsed at all? If it's parsed anyway then being shown in feeds isn't different from being shown on the site - but I don't actually know whether it is or not. (Out of interest, if it's not, what happens about embedded videos, galleries, etc?)

It is parsed, but it doesn't necessarily need to be.

Why would you simply delete all shortcodes? Obviously, if you delete them, then what they represent won't be there anymore. Do you want your image tags to still be there if you delete all HTML too? If you remove all forms of formatting so you just have plain text? Where do you draw the line?

I draw the line at having something that is only meaningful in the context of WordPress itself in my post content.

In other words, <img src=...> has meaning in an actual standard. Shortcodes are part of no standard anywhere.

Besides, there is already a [gallery] shortcode. If you delete it; the images it represents won't be shown anymore. Why's that OK, when a shortcode for individual images isn't?

I never said that it was okay. I dislike the use of [gallery]. I don't use it myself.

I don't like shortcodes in general. They are non-standard, they require my content to be parsed through WordPress, and they blur the distinction between content and code too far, IMO. I'm okay with them, in general, as they usually don't carry particularly meaningful content. And when they do, it's in a plugin.

But I don't want the core code doing that. I hate the idea of making my content dependent upon the code in WordPress itself, taking it out of my hands and putting it into the developers hands. It's a damned poor way of doing things.

I don't want to upgrade and have the actual content on my site change just because some code got committed into a new update.

Maybe we should have an option to disable the shortcode - enable it for normal users who are more concerned about ease of use and the enhanced feature set which it helps to enable, and allow advanced users who are more concerned about direct data portability without using an exporter to disable the shortcode. What do you think of that concept?

I'd rather it be opt-in only, not opt-out.

comment:44 in reply to: ↑ 42 mikeschinkel4 years ago

Replying to caesarsgrunt:

Replying to mikeschinkel:

As for an option to disable shortcodes, I don't think that is really a viable option considering how many things can be done with shortcodes from plugins. Disabling them stunts far too much available functionality.

I just meant an option (a wp-config.php constant) to disable this particular shortcode, so that for people like Otto who don't like it, they can keep the current behaviour.

Reading Otto's latest comments "I don't like shortcodes" it comes down to a philosophy of what WP should be doing. I actually am agnostic about shortcodes, but I think we should either do them right or not at all. I think giving options to turn them off simple avoids doing them right.

So it comes down to this: the people who control the direction of WordPress should decide if shortcodes are core to WP or not. If they are core then go full force to make them fully usable in WP and let Otto just suck it up. If they are not going to be core then mark them as deprecated, transition to get rid of them and provide an alternate solution to meet the same need.

But this straddling the fence, providing tacit acknowledgement of them while fighting them in the same breath is simply not helpful. At least IMHO. ;-)

comment:45 follow-up: Otto424 years ago

What really bugs me is that you don't need to make a shortcode to accomplish any of the stated goals in the original ticket. It's overkill.

Look at the goals:

  • allowing images to be trashed
  • allowing plugins and themes to modify the code used to show images
  • removing broken img tags from posts when the image is deleted

All of these can be done with some clever use of classes and preg_matching. And it would be simpler and faster than using shortcodes to do it, in fact, because you wouldn't need to modify the existing code much at all.

Look, I'll give you an example. This code will find all img tags in a post and parse them, then spit out their src and class.

global $post;
if ( preg_match_all('/<img (.+?)>/', $post->post_content, $matches) ) {

foreach ($matches[1] as $match) {

foreach ( wp_kses_hair($match, array('http')) as $attr)

echo $imgsrc?;
echo $imgclass?;

}

}

}

Pretty simple, really. If the class contained something like, attachment-123, then finding the 123 and checking to see if the image was deleted would be rather straightforward, wouldn't it?

comment:46 in reply to: ↑ 43 ; follow-up: caesarsgrunt4 years ago

Replying to Otto42:

Thanks for the explanations; I now understand your point of view on the matter, I think. And I do agree that your concerns are valid to a certain extent, but I think they are mitigated to a huge extent by the fact the WP is open source, so you'll never end up with your content locked in by the use on non-standard shortodes, since anyone will be able create an exporter straight to HTML or another standard. Also, I'd like to point out that the current system actually makes it harder to move your content to a different platform - since your image paths are hardcoded and so you have to keep the WP directory structure. It even makes it hard to change your domain, since the full domain is currently used instead of relative paths.

I'd rather it be opt-in only, not opt-out.

The problem with that is that most users are likely to want the added functionality, whereas it is most likely to be power users who prefer the data to be stored using standard HTML rather than shortcodes. And power users have no difficulty in disabling a feature like this using wp-config.php, whereas a normal user would probably find it very difficult.

comment:47 Otto424 years ago

Whoops. Pasting error. Here's the fixed code example for above:

	global $post;
	if ( preg_match_all('/<img (.+?)>/', $post->post_content, $matches) ) {
	        foreach ($matches[1] as $match) {
	                foreach ( wp_kses_hair($match, array('http')) as $attr)
	                	$img[$attr['name']] = $attr['value'];
	                echo $img['src'];
	                echo $img['class'];
	                }
	        }
 	}

comment:48 follow-up: nacin4 years ago

This seems more like a conversation better served as a wp-hackers thread, not a Trac ticket (and I don't mean that in a disparaging way). It's just a better venue to discuss these opinions. Trac should be for code, not discussions on the theory/idea.

Let's leave this one open until 3.1 scope discussions are held, and if there's no traction for an image shortcode when media/upload is presumably on the table, we can wontfix this.

comment:49 in reply to: ↑ 46 Otto424 years ago

Replying to caesarsgrunt:

Also, I'd like to point out that the current system actually makes it harder to move your content to a different platform - since your image paths are hardcoded and so you have to keep the WP directory structure. It even makes it hard to change your domain, since the full domain is currently used instead of relative paths.

No, both of those make it *easier*, not harder.

It's easier to use a existing tools (such as a straightforward search and replace tool or a database access tool) than have to wrie platform-specific PHP code to produce what you're trying to make.

The problem with that is that most users are likely to want the added functionality

We're not talking about the functionality, because shortcodes are not required to create that functionality.

I'm all for the functionality. I'm against your suggested implementation.

comment:50 in reply to: ↑ 45 ; follow-up: caesarsgrunt4 years ago

Replying to Otto42:

What really bugs me is that you don't need to make a shortcode to accomplish any of the stated goals in the original ticket. It's overkill.

Look at the goals:

  • allowing images to be trashed
  • allowing plugins and themes to modify the code used to show images
  • removing broken img tags from posts when the image is deleted

All of these can be done with some clever use of classes and preg_matching. And it would be simpler and faster than using shortcodes to do it, in fact, because you wouldn't need to modify the existing code much at all.

Not changing the existing code much != easier and faster. You can change the existing code to something as fast or faster, or your "small" change can be slower than a more in-depth rewrite of a portion of the code.

I think your solution is probably slightly slower actually, because it means the post has to parsed another time, in addition to the existing shortcode parser.

Look, I'll give you an example. This code will find all img tags in a post and parse them, then spit out their src and class.


...

Pretty simple, really. If the class contained something like, attachment-123, then finding the 123 and checking to see if the image was deleted would be rather straightforward, wouldn't it?

Yes, but you've just broken your data portability concept. Because now, when you use the post straight from the database, you'll end up with broken images in it, which you wouldn't have looking at it in WordPress.

Besides, it's a rather ugly hack. If you're going to treat the HTML as a shortcode, better to just have a shortcode.

comment:51 in reply to: ↑ 50 ; follow-up: Otto424 years ago

Replying to caesarsgrunt:

Besides, it's a rather ugly hack. If you're going to treat the HTML as a shortcode, better to just have a shortcode.

I disagree that the use of <>'s is in any way prettier or uglier than the use of [], which is the only substantial difference between either implementation. At least my way lets the content fit with an existing standard known as HTML.

However, nacin is correct, and this discussion is not suitable for this venue.

comment:52 in reply to: ↑ 51 caesarsgrunt4 years ago

Replying to Otto42:

Replying to caesarsgrunt:

Besides, it's a rather ugly hack. If you're going to treat the HTML as a shortcode, better to just have a shortcode.

I disagree that the use of <>'s is in any way prettier or uglier than the use of [], which is the only substantial difference between either implementation. At least my way lets the content fit with an existing standard known as HTML.

I was referring to the method of handling it, not to the type of bracket used to represent it.

However, nacin is correct, and this discussion is not suitable for this venue.

Okay; let's go to wp-hackers then. I'll have to subscribe first; I'm not subscribed yet because of the volume of emails in the list...

comment:53 in reply to: ↑ 48 mikeschinkel4 years ago

Replying to nacin:

This seems more like a conversation better served as a wp-hackers thread, not a Trac ticket (and I don't mean that in a disparaging way). It's just a better venue to discuss these opinions. Trac should be for code, not discussions on the theory/idea.

Let's leave this one open until 3.1 scope discussions are held, and if there's no traction for an image shortcode when media/upload is presumably on the table, we can wontfix this.

Point taken.

Replying to Otto42:

Look, I'll give you an example. This code will find all img tags in a post and parse them, then spit out their src and class.

global $post;
if ( preg_match_all('/<img (.+?)>/', $post->post_content, $matches) ) {

foreach ($matches[1] as $match) {

foreach ( wp_kses_hair($match, array('http')) as $attr)

echo $imgsrc?;
echo $imgclass?;

}

}

}

I know this is off-topic (forgive me please) but I've both studied and looked for documentation for KSES but to no avail. I think there is great functionality that many WP developers could use but the lack of docs or blog posts on the subject tell me almost nobody understands how to use it other than you and a few others.

Any chance you'd go to the effort to do a KSES tutorial on your blog? Thanks in advance...

comment:54 nacin4 years ago

  • Milestone changed from Awaiting Triage to Future Release

comment:55 markoheijnen16 months ago

  • Keywords needs-patch dev-feedback removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing this ticket as wont-fix. No traction in two years and it doesn't make sense. I agree with Otto that a regex should do the trick and for now it seems best that a plugin shows how to do this best.

Note: See TracTickets for help on using tickets.