Moodle
  1. Moodle
  2. MDL-22955

Add support for SVG images to the image system within Moodle 2

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.4
    • Component/s: Themes
    • Labels:
      None
    • Testing Instructions:
      Hide

      1. Run the unit tests, particularly lib/tests/outputlib_test.php

      2. Copy the following code into a test script in the root of your Moodle directory:

      <?php
      require_once('config.php');
      $PAGE->set_context(context_system::instance());
      $PAGE->set_url('/');
      echo $OUTPUT->pix_icon('i/test', 'You should never see this');
      

      3. Test this code in all of the supported browsers. In IE8 (or any earlier version) you should get a blue ball. In all other browsers you should get an orange ball.

      4. Test the order of image caching

      • Using IE8:
      • Turn off theme designer mode.
      • Purge the site caches
      • Visit the test script and make sure you see a blue ball.
      • Switch to Firefox or Chrome
      • Visit the test script and check you see an orange ball.
      • Switch back to IE8
      • Enable theme designer mode
      • Visit the test script and make sure you see a blue ball.
      • Switch to Firefox or Chrome
      • Visit the test script and check you see an orange ball.

      5. Test CSS

      • Edit theme/base/styles/admin.css
      • Add the following to the bottom: #sams-svg-test {background-image:url([[pix:core|i/test]]);}
      • Using Firefox or Chrome
      • Purge your caches
      • Using the dev toolkit (firebug or dev tools) find the admin CSS file contents. If you have theme designer mode on it will be a separate sheet, otherwise it will be a sheet called all.
      • Search the CSS for #sams-svg-test
      • Check that the URL either contains /_s/ if theme designer mode off or svg=0 if theme designer mode is on.
      Show
      1. Run the unit tests, particularly lib/tests/outputlib_test.php 2. Copy the following code into a test script in the root of your Moodle directory: <?php require_once('config.php'); $PAGE->set_context(context_system::instance()); $PAGE->set_url('/'); echo $OUTPUT->pix_icon('i/test', 'You should never see this '); 3. Test this code in all of the supported browsers. In IE8 (or any earlier version) you should get a blue ball. In all other browsers you should get an orange ball. 4. Test the order of image caching Using IE8: Turn off theme designer mode. Purge the site caches Visit the test script and make sure you see a blue ball. Switch to Firefox or Chrome Visit the test script and check you see an orange ball. Switch back to IE8 Enable theme designer mode Visit the test script and make sure you see a blue ball. Switch to Firefox or Chrome Visit the test script and check you see an orange ball. 5. Test CSS Edit theme/base/styles/admin.css Add the following to the bottom: #sams-svg-test {background-image:url([[pix:core|i/test]]);} Using Firefox or Chrome Purge your caches Using the dev toolkit (firebug or dev tools) find the admin CSS file contents. If you have theme designer mode on it will be a separate sheet, otherwise it will be a sheet called all. Search the CSS for #sams-svg-test Check that the URL either contains /_s/ if theme designer mode off or svg=0 if theme designer mode is on.
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE
    • Pull Master Branch:
      wip-MDL-22955-m24
    • Rank:
      6101

      Description

      Hi guys,

      The order of file extension Moodle searches when locating an image was discussed in the forum not so long ago and the question was raised about why SVG was not on the list.
      I've created this issue because I think it would be a great idea to add support for using SVG images, particularly so themer's can override core images with SVG's.

      I purpose to prepend SVG to the list of image formats that Moodle searches for unless the user is using IE < 9 (they've finally added SVG support in IE 9). This would of course make SVG the first format searched for which is probably fine given that it won't be used if the users browser doesn't support it.

      Before I produce a patch or anything I would like to get some feedback from people about this.

      Cheers
      sam

        Issue Links

          Activity

          Hide
          Sam Hemelryk added a comment -

          Added watches.... any input appreciated.

          Show
          Sam Hemelryk added a comment - Added watches.... any input appreciated.
          Hide
          Petr Škoda added a comment -

          watch out for security related issues, svg can be loaded with JS (or other code), so we have to make 100% sure it comes only from trusted sources

          Any requests to support SVG from students should be marked as invalid for now.

          Show
          Petr Škoda added a comment - watch out for security related issues, svg can be loaded with JS (or other code), so we have to make 100% sure it comes only from trusted sources Any requests to support SVG from students should be marked as invalid for now.
          Hide
          Mauno Korpelainen added a comment -

          I suppose it was me who raised the question... this would be a great feature but it may be too early to use it in moodle 2.0 - maybe 2.1?

          This cross-browser support has been the biggest problem of www since the days we got IE - and as long as moodle does not use totally different themes for IE6, IE7 and IE8 (as "old browsers" we are stuck. Moodle 2.0 might be stable before we get IE9

          All the latest versions of "modern browsers" (Firefox, Opera, Safari, Chrome) do support svg with img tag although img tag support was added to Firefox just recently so all old versions of Firefox don't show svg in img tag even if Firefox has had native support of svg since version 1.5.

          Tags like

          <object type="image/svg+xml" data="test.svg">
          <img src="test.gif" alt="test" />
          </object>

          would be cross-browser compatible if we had svg image for modern browsers and test.gif for those browsers that do not support svg with object tag ( =IE )

          See for example http://e.metaclarity.org/52/cross-browser-svg-issues/

          And before we get HTML5 and new doc type to moodle X.X we may also have some issues with correct mime & doc type...

          BUT : Once IE9 is available, moodle 2.0 is stable and HTML5 doc type is implemented to moodle road is open for svg for various reasons:

          Because SVG images do not have to store every pixel in the image, they generally produce smaller file sizes than similar bitmap images. Because SVG images are resolution-independent, the image can be resized or altered without degrading the image quality.

          SVG supports animation - see endless debates SVG versus Flash. You can animate individual objects within an SVG file as well as the vast majority of the properties and attributes that these objects possess, such as their color, size, orientation, opacity, and visibility.

          SVG supports scripting and programming languages, including JavaScript, Java, and Visual Basic. You can write scripts to control the playback of animation, provide interactive feedback like rollover effects and pop-up menus, and generate new SVG code on the fly. Scripting also allows you to control HTML elements and vice versa, so that clicking hyperlinks in an HTML document, for instance, causes changes in an accompanying SVG.

          SVG supports database integration. An SVG template can acquire variables from a database to populate dynamic pages. Plus, because SVG code is textbased, the database can contain straight SVG instead of links to external graphics files. SVG supports Cascading Style Sheets (CSS).

          SVG has a number of other advantages over other graphics standards. It uses a "color profile" to render colors more accurately, regardless of browser and monitor differences (even rendering accurately to devices such as PDAs and cell phones). Text-based SVG can be edited with text editor, it is open source, written in XML, an official W3C graphics standard, accessible for people with visual disabilities, searchable, dynamic and updateable, supports filters, transformations, clipping, and masking, supports transparency, can be used for print as well as Web graphics...

          Show
          Mauno Korpelainen added a comment - I suppose it was me who raised the question... this would be a great feature but it may be too early to use it in moodle 2.0 - maybe 2.1? This cross-browser support has been the biggest problem of www since the days we got IE - and as long as moodle does not use totally different themes for IE6, IE7 and IE8 (as "old browsers" we are stuck. Moodle 2.0 might be stable before we get IE9 All the latest versions of "modern browsers" (Firefox, Opera, Safari, Chrome) do support svg with img tag although img tag support was added to Firefox just recently so all old versions of Firefox don't show svg in img tag even if Firefox has had native support of svg since version 1.5. Tags like <object type="image/svg+xml" data="test.svg"> <img src="test.gif" alt="test" /> </object> would be cross-browser compatible if we had svg image for modern browsers and test.gif for those browsers that do not support svg with object tag ( =IE ) See for example http://e.metaclarity.org/52/cross-browser-svg-issues/ And before we get HTML5 and new doc type to moodle X.X we may also have some issues with correct mime & doc type... BUT : Once IE9 is available, moodle 2.0 is stable and HTML5 doc type is implemented to moodle road is open for svg for various reasons: Because SVG images do not have to store every pixel in the image, they generally produce smaller file sizes than similar bitmap images. Because SVG images are resolution-independent, the image can be resized or altered without degrading the image quality. SVG supports animation - see endless debates SVG versus Flash. You can animate individual objects within an SVG file as well as the vast majority of the properties and attributes that these objects possess, such as their color, size, orientation, opacity, and visibility. SVG supports scripting and programming languages, including JavaScript, Java, and Visual Basic. You can write scripts to control the playback of animation, provide interactive feedback like rollover effects and pop-up menus, and generate new SVG code on the fly. Scripting also allows you to control HTML elements and vice versa, so that clicking hyperlinks in an HTML document, for instance, causes changes in an accompanying SVG. SVG supports database integration. An SVG template can acquire variables from a database to populate dynamic pages. Plus, because SVG code is textbased, the database can contain straight SVG instead of links to external graphics files. SVG supports Cascading Style Sheets (CSS). SVG has a number of other advantages over other graphics standards. It uses a "color profile" to render colors more accurately, regardless of browser and monitor differences (even rendering accurately to devices such as PDAs and cell phones). Text-based SVG can be edited with text editor, it is open source, written in XML, an official W3C graphics standard, accessible for people with visual disabilities, searchable, dynamic and updateable, supports filters, transformations, clipping, and masking, supports transparency, can be used for print as well as Web graphics...
          Hide
          Mauno Korpelainen added a comment -

          Petr,

          originally svg was suggested to be used only in moodle 2.0 themes - http://moodle.org/mod/forum/discuss.php?d=151581#p664019 - so students should not have any access to those images of themes anyway.

          However from theme designers/users point of view this is a potential security risk if you use 3rd party themes with some svg images and don't know what's inside the images (scripts). It's a similar risk as using a 3rd party theme that has some peculiar javascripts or fake images with hidden scripts...

          The good point is that as text files all svg images can be opened, checked and edited - and finally it's a question of trust. Core code must be safe to use, themes in moodle database must be safe to use (checked by somebody) and people should be careful when they download 3rd party themes anyway...

          Show
          Mauno Korpelainen added a comment - Petr, originally svg was suggested to be used only in moodle 2.0 themes - http://moodle.org/mod/forum/discuss.php?d=151581#p664019 - so students should not have any access to those images of themes anyway. However from theme designers/users point of view this is a potential security risk if you use 3rd party themes with some svg images and don't know what's inside the images (scripts). It's a similar risk as using a 3rd party theme that has some peculiar javascripts or fake images with hidden scripts... The good point is that as text files all svg images can be opened, checked and edited - and finally it's a question of trust. Core code must be safe to use, themes in moodle database must be safe to use (checked by somebody) and people should be careful when they download 3rd party themes anyway...
          Hide
          Petr Škoda added a comment -

          yes Mauno, I think we both understand it, I was just pointing this out to make sure we do not add support for svg everywhere because there was such request many times before

          Show
          Petr Škoda added a comment - yes Mauno, I think we both understand it, I was just pointing this out to make sure we do not add support for svg everywhere because there was such request many times before
          Hide
          Mauno Korpelainen added a comment -

          Which leads to another question about HTML5 (meta issue) :

          If I simply replace in custom theme layout files

          echo $OUTPUT->doctype() ?>
          <html <?php echo $OUTPUT->htmlattributes() ?>>

          with HTML5 doctype

          ?>
          <!DOCTYPE HTML>
          <html>

          to test HTML5 themes with all HTML5 features including embedded svg line 582 of \lib\outputrenderers.php throws debugging error "The page layout file did not call $OUTPUT->doctype()" from public function header() and lines

          if (empty($this->contenttype))

          { debugging('The page layout file did not call $OUTPUT->doctype()'); $header = $this->doctype() . $header; }

          So is there some esy way to change doctype of themes to use

          <!DOCTYPE HTML>
          <html>

          and HTML5 directly so that echo $OUTPUT->doctype() ?> would give simple HTML5 doctype <!DOCTYPE HTML>

          Show
          Mauno Korpelainen added a comment - Which leads to another question about HTML5 (meta issue) : If I simply replace in custom theme layout files echo $OUTPUT->doctype() ?> <html <?php echo $OUTPUT->htmlattributes() ?>> with HTML5 doctype ?> <!DOCTYPE HTML> <html> to test HTML5 themes with all HTML5 features including embedded svg line 582 of \lib\outputrenderers.php throws debugging error "The page layout file did not call $OUTPUT->doctype()" from public function header() and lines if (empty($this->contenttype)) { debugging('The page layout file did not call $OUTPUT->doctype()'); $header = $this->doctype() . $header; } So is there some esy way to change doctype of themes to use <!DOCTYPE HTML> <html> and HTML5 directly so that echo $OUTPUT->doctype() ?> would give simple HTML5 doctype <!DOCTYPE HTML>
          Hide
          Sam Hemelryk added a comment -

          Pushed this back to 2.1 presently

          Show
          Sam Hemelryk added a comment - Pushed this back to 2.1 presently
          Hide
          Barbara Ramiro added a comment -

          Hi Sam! May i follow up on this as I need to test the icons. Cheers.

          Show
          Barbara Ramiro added a comment - Hi Sam! May i follow up on this as I need to test the icons. Cheers.
          Hide
          Sam Hemelryk added a comment -

          Ok I've pushed up a branch to introduce the ability to use SVG for icons within Moodle.

          As SVG icons arn't yet supported on all major browsers (IE8 is the real issue) this patch uses a basic bit of user agent matching in making a decision about what to serve.
          It includes a new setting that can be set within the config.php file (and is detailed in config-dist) that allows the admin to force the use of SVG one way or the other when available.

          I've also included unit tests for the logic that makes the decision to test overrides and the browser matching regex.

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Ok I've pushed up a branch to introduce the ability to use SVG for icons within Moodle. As SVG icons arn't yet supported on all major browsers (IE8 is the real issue) this patch uses a basic bit of user agent matching in making a decision about what to serve. It includes a new setting that can be set within the config.php file (and is detailed in config-dist) that allows the admin to force the use of SVG one way or the other when available. I've also included unit tests for the logic that makes the decision to test overrides and the browser matching regex. Many thanks Sam
          Hide
          Dan Poltawski added a comment -

          (Not really looked a tthis properly, but i'll dump some comments anyway):

          I read somewhere that only very recent android browsers support SVG (its a shame that we'll have to do browser sniffing rather than feature detection).

          A quick look at the code made me think that this patch could be problematic with caching. (Could we be causing a squid proxy server to cache a png instead of a svg if an IE user requests it first?)

          Show
          Dan Poltawski added a comment - (Not really looked a tthis properly, but i'll dump some comments anyway): I read somewhere that only very recent android browsers support SVG (its a shame that we'll have to do browser sniffing rather than feature detection). A quick look at the code made me think that this patch could be problematic with caching. (Could we be causing a squid proxy server to cache a png instead of a svg if an IE user requests it first?)
          Hide
          Sam Hemelryk added a comment -

          Hi Dan,

          Absolutely correct about the caching issue.
          I had spoken to Petr on Thursday night about it but forgot to comment here sorry. In discussing it we decided it had to result in a change to the URL.
          I've just updated the patch now to inject a param into the URL when SVG is not supported (both for slashargs and not).
          I've gone for the negative perception when using this param despite that not being the normal path because I see this as a temporary hack required only until IE8 and lower are dropped from our supported browsers list.

          In regards to browser support I think http://caniuse.com/#feat=svg-img sums it up pretty nicely.
          Andriod browser 2.3 and below don't support this method of SVG. Originally I hadn't really cared much about that, however on second though 2.3 is still very widely used. As such we now check for any version of Android < 3 and avoid SVG if so. Perhaps a little tough, but it will work and is a quick check.

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Hi Dan, Absolutely correct about the caching issue. I had spoken to Petr on Thursday night about it but forgot to comment here sorry. In discussing it we decided it had to result in a change to the URL. I've just updated the patch now to inject a param into the URL when SVG is not supported (both for slashargs and not). I've gone for the negative perception when using this param despite that not being the normal path because I see this as a temporary hack required only until IE8 and lower are dropped from our supported browsers list. In regards to browser support I think http://caniuse.com/#feat=svg-img sums it up pretty nicely. Andriod browser 2.3 and below don't support this method of SVG. Originally I hadn't really cared much about that, however on second though 2.3 is still very widely used. As such we now check for any version of Android < 3 and avoid SVG if so. Perhaps a little tough, but it will work and is a quick check. Many thanks Sam
          Hide
          Sam Hemelryk added a comment -

          Am putting this up for integration now as we need a solution shortly for Barbara. Feel free to discuss with me or reject if anything is spotted of course.

          Show
          Sam Hemelryk added a comment - Am putting this up for integration now as we need a solution shortly for Barbara. Feel free to discuss with me or reject if anything is spotted of course.
          Hide
          Dan Poltawski added a comment -

          Hi Sam,

          Correct me if i'm wrong, but I've just thought of another problem with this, which I don't think is covered:

          CSS files with [[pix]] urls. I think that will generate an output CSS file which is dependent on browser at the point of the css file generation.

          Show
          Dan Poltawski added a comment - Hi Sam, Correct me if i'm wrong, but I've just thought of another problem with this, which I don't think is covered: CSS files with [ [pix] ] urls. I think that will generate an output CSS file which is dependent on browser at the point of the css file generation.
          Hide
          Barbara Ramiro added a comment -

          Thanks for the patch Sam! Finally, I was able to test the icons and found some issues with the size, clarity and contrast. Cheers

          Show
          Barbara Ramiro added a comment - Thanks for the patch Sam! Finally, I was able to test the icons and found some issues with the size, clarity and contrast. Cheers
          Hide
          Sam Hemelryk added a comment -

          Hi Dan,

          Quite right about the serving of SVG through CSS. That is a problem.
          I've pushed up a branch with another two commits to address that and another problem I became aware of this morning when running through the tests.
          Details are:

          1df11d7.
          I've added a function to force the usesvg property to either true or false. I've then used that method within theme_config::post_process (the function responsible for processing those image URL's) to force the use of svg when available to off. This means that we never serve SVG images through CSS. The reason for this decision is that support of SVG in CSS across browsers is sketchy and at best quirky. This will I imagine lead to a situation of a further feature request in the future to support SVG in CSS, however I think that is a bridge best crossed later when we both know people want it, and support of it is more consistent.

          0d966ed.
          I found a bug in the way things happened if the user who first requested an image was using a browser that didn't support SVG. In this situation a PNG (or equiv) would be cached and all future requests for that image would result in the PNG being served regardless of the users browser supporting it or not. This was happening because any candidate image already exists for subsequent requests.
          The solution is to always ensure we cache an SVG copy when caching & serving an image for someone that does not support SVG.
          This will of course only happen once so while it does introduce more work it should not be significant.

          As both of these are significant changes I'm quite happy for you to send this back and look again next week if you like, although if you do choose to do that perhaps you would be kind enough to look and think about it still so that I can preempt anything before next week

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Hi Dan, Quite right about the serving of SVG through CSS. That is a problem. I've pushed up a branch with another two commits to address that and another problem I became aware of this morning when running through the tests. Details are: 1df11d7. I've added a function to force the usesvg property to either true or false. I've then used that method within theme_config::post_process (the function responsible for processing those image URL's) to force the use of svg when available to off. This means that we never serve SVG images through CSS. The reason for this decision is that support of SVG in CSS across browsers is sketchy and at best quirky. This will I imagine lead to a situation of a further feature request in the future to support SVG in CSS, however I think that is a bridge best crossed later when we both know people want it, and support of it is more consistent. 0d966ed. I found a bug in the way things happened if the user who first requested an image was using a browser that didn't support SVG. In this situation a PNG (or equiv) would be cached and all future requests for that image would result in the PNG being served regardless of the users browser supporting it or not. This was happening because any candidate image already exists for subsequent requests. The solution is to always ensure we cache an SVG copy when caching & serving an image for someone that does not support SVG. This will of course only happen once so while it does introduce more work it should not be significant. As both of these are significant changes I'm quite happy for you to send this back and look again next week if you like, although if you do choose to do that perhaps you would be kind enough to look and think about it still so that I can preempt anything before next week Many thanks Sam
          Hide
          Sam Hemelryk added a comment -

          Updated the test instructions to test for the two noted changes in the last commit

          Show
          Sam Hemelryk added a comment - Updated the test instructions to test for the two noted changes in the last commit
          Hide
          Dan Poltawski added a comment -

          I'm taking this out of this weeks integration, since it needs deeper thought. But I will think more about this.

          Show
          Dan Poltawski added a comment - I'm taking this out of this weeks integration, since it needs deeper thought. But I will think more about this.
          Hide
          Dan Poltawski added a comment -

          The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday.
          This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody.
          This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P
          Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao

          Show
          Dan Poltawski added a comment - The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday. This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody. This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao
          Hide
          Martin Dougiamas added a comment -

          Thanks for working on this guys. I hope you can come up with a solution that works on all browsers without reducing performance.

          Show
          Martin Dougiamas added a comment - Thanks for working on this guys. I hope you can come up with a solution that works on all browsers without reducing performance.
          Hide
          Dan Poltawski added a comment -

          I'm looking a this at the moment.

          One off topic comment about it is this is that the edges of that test svg circle look kinda horrible on my desktop screen (though looks perfect on my iPhone). Jagged edges

          Show
          Dan Poltawski added a comment - I'm looking a this at the moment. One off topic comment about it is this is that the edges of that test svg circle look kinda horrible on my desktop screen (though looks perfect on my iPhone). Jagged edges
          Hide
          Dan Poltawski added a comment -

          I've had a look a tthe code, thought about and done some testing and can't think of any more problems.

          Show
          Dan Poltawski added a comment - I've had a look a tthe code, thought about and done some testing and can't think of any more problems.
          Hide
          Sam Hemelryk added a comment -

          Hi Dan,

          Looks like an anti-aliasing issue there.
          I am aware that some browsers have quirks when displaying some images, and that for some images/components directives about rendering priority may need to be provided.
          What browser was it that you were seeing that in?

          Truth be told I was more interested in having the test image than how it looked so I didn't worry about trying to test it or optimise it for browsers.
          Hopefully its not an issue, or if so then perhaps we're best to get Barbara to knock something up for us. I'm not familiar with any of the vector graphics applications available under Linux and wouldn't have a clue where to start with them.. haha other than hacking the XML using vim or such

          Many thanks for looking at this.
          Sam

          Show
          Sam Hemelryk added a comment - Hi Dan, Looks like an anti-aliasing issue there. I am aware that some browsers have quirks when displaying some images, and that for some images/components directives about rendering priority may need to be provided. What browser was it that you were seeing that in? Truth be told I was more interested in having the test image than how it looked so I didn't worry about trying to test it or optimise it for browsers. Hopefully its not an issue, or if so then perhaps we're best to get Barbara to knock something up for us. I'm not familiar with any of the vector graphics applications available under Linux and wouldn't have a clue where to start with them.. haha other than hacking the XML using vim or such Many thanks for looking at this. Sam
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated, thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated, thanks!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Hi Sam,

          this is leading to unit tests failures (both servers):

          user_picture_testcase::test_get_url
          Failed asserting that two strings are equal.
          --- Expected
          +++ Actual
          @@ @@
          -'http://www.example.com/moodle/theme/image.php/standard/core/1/u/f2'
          +'http://www.example.com/moodle/theme/image.php/_s/standard/core/1/u/f2'
          
          git_repositories/master/lib/tests/outputcomponents_test.php:176
          git_repositories/master/lib/phpunit/classes/advanced_testcase.php:76
          

          Cya!

          Show
          Eloy Lafuente (stronk7) added a comment - Hi Sam, this is leading to unit tests failures (both servers): user_picture_testcase::test_get_url Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'http: //www.example.com/moodle/theme/image.php/standard/core/1/u/f2' +'http: //www.example.com/moodle/theme/image.php/_s/standard/core/1/u/f2' git_repositories/master/lib/tests/outputcomponents_test.php:176 git_repositories/master/lib/phpunit/classes/advanced_testcase.php:76 Cya!
          Hide
          Sam Hemelryk added a comment -

          Thanks for spotting Eloy, I've pushed a fix up for that now.
          At the start of the get_url test we force the use of SVG images to true, gives us a nice predictable URL again.

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Thanks for spotting Eloy, I've pushed a fix up for that now. At the start of the get_url test we force the use of SVG images to true, gives us a nice predictable URL again. Many thanks Sam
          Hide
          Ankit Agarwal added a comment -

          Works as expected
          Passing
          Thanks

          Show
          Ankit Agarwal added a comment - Works as expected Passing Thanks
          Hide
          Eloy Lafuente (stronk7) added a comment -

          From somewhere within the clouds...

          Congrats, this has been sent upstream and is now part of Moodle (your favorite LMS platform). Many thanks for your awesome collaboration!

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - From somewhere within the clouds... Congrats, this has been sent upstream and is now part of Moodle (your favorite LMS platform). Many thanks for your awesome collaboration! Ciao

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: