Support data URIs

+  /**
+   * Test nested list rendering.
+   */
+  function testDataUri() {
+    $expected = '<img typeof="foaf:Image" 

I suggest "Test data URI in image tag." ;-)

 /**
+ * Unit tests for theme_image().
+ */
+class ThemeImageUnitTest extends DrupalWebTestCase {
+  public static function getInfo() {

Using the testing profile would be nice. Testing theme_image() does not depend on block, node, or rdf, to name a few.

data-uris.patch queued for re-testing.

#11: data-uris.patch queued for re-testing.

#7: data-uris.patch queued for re-testing.

Marking #1851472: Add support for data:// encoded URIs in file_create_url (native theme_image support) as a duplicate of this issue.

I think for now we should likely not add data: as an allowed protocol in drupal_strip_dangerous_protocols() unless we have good reason to. I believe supporting data from file.inc is good for now.

Going to pick this up to re-roll for latest 8.x. Fixing metadata.

Updated and re-rolled for current 8.x. Let's see what fails.

Try again.

Can you add type hints to the docblocks that are being changed in this issue? Thanks.

data-uris.patch queued for re-testing.

improve grammar

The Responsive Image module already uses a data uri (for mapping to an empty image), but since it uses image styles it doesn't need file_create_url directly:

  if ($style_name == RESPONSIVE_IMAGE_EMPTY_IMAGE) {
    // The smallest data URI for a 1px square transparent GIF image.
    return 'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7';
  }
  return entity_load('image_style', $style_name)->buildUrl($path);

BUT, since we now use data URI's in Core, it should really be supported...

Some small things, sorry.

1. +++ b/core/includes/file.inc
   @@ -323,10 +327,12 @@ function file_stream_wrapper_valid_scheme($scheme) {
   +  // If nothing was replaced, the uri doesn't have a valid scheme.
   

   s/uri/URI/

2. +++ b/core/includes/file.inc
   @@ -439,11 +445,11 @@ function file_stream_wrapper_get_instance_by_scheme($scheme) {
   + *   The URI to a file for which we need an external URL, the path to a
   + *   shipped file or a data URI.
   

   "path to a shipped file" is the special case here: that looks like core/misc/druplicon.png

   Everything else, including data URIs are encompassed in the first case.

   Therefore, this change is unnecessary, and confusing.

3. +++ b/core/includes/file.inc
   @@ -476,9 +482,9 @@ function file_create_url($uri) {
   +    // implement getExternalUrl() for the HTTP and data wrappers.
   

   s/wrappers/schemes/?

New patch. Addresses remarks from #34.

Thanks!

+++ b/core/includes/file.inc
@@ -312,10 +316,10 @@ function file_stream_wrapper_valid_scheme($scheme) {
+ *   A stream, referenced as "scheme://target" or "data:target".

data: is just another scheme, the flaw is actually that Drupal assumed :// before. I think this is sufficiently clear though.

Committed 5e938c1 and pushed to 8.0.x. Thanks!

Backport to D7

Some remarks:

- The theming function for image expects 'path' not 'uri', right?
- I had to add 'typeof="foaf:Image"' to the expected result in testImage() and strip the newline at the end, is that correct?

Had some problems with the patchformat. Next try, probably not the last one

Sorry for spamming, newbie in patching and drupal issue queue. Didn't notice that bot has changed status.

Is there something new? After applying the patch (#41) and patching image.module (as described here) the error is still there:

Maybe it is possible to upload the patched/working files?

#41 applies cleanly to Drupal 7. Can we get this committed to D7? It has been applied to D8 already. This is an ongoing issue for Storage API module which could greatly benefit from data URIs in core.

@zwerg, What error is still there?

@Perignon data URIs are still not supported and Storage API continues showing this message.

@zwerg, That would be an issue to bring up within the Storage API issue queue. It doesn't affect the patch here. Even though the patch was started by JBrown.

patch #41 works for me

How do we get this committed, please?

Rerolled for 7.84.

Hmmm ... wait for the re-test, that exception is nothing to do with the changes.. Yeah, it's fine now - some internal failure with testbot, now all good.

The last patch still works.