[BC] Converted RWD's default logos to SVG (and removed some Magento names)

[fballiano]

This PR removes the reference to the logo.gif files (and _email.gif and _print.gif) which do not look good on high resolution displays, replacing all of them with the SVG version, which looks perfect at all resolutions.

I've also replaced a few occurrences of the "Magento" name that were out of place in those contexts.

Since we're removing some files it should be considered a breaking change, although I'm sure nobody is using those file in any production environment.

BEFORE:

AFTER:

[sreichel]

Better add a new update script to change email templates?

[fballiano]

email temples should read the logo variable with something like the {{var something}} syntax so nothing to update there.

Anyway I don't think I'd want to force force an update on user created content like a template (which they probably would be heavily customised).

[sreichel]

You are right. "Reset" the templates is no good idea.

Mayby add so conditions to that update script ...

if (emailTemplateDb === emailTemplateDefault) {
    // replace logos here
}

[fballiano]

It can't be done, templates in the repo do not reference the logo files:

they're not even part of the RWD theme, they're part of the "app/locale" translation packages

[fballiano]

@justinbeaty right, pushed a new commit.

about the getLogoSrcSmall, I've marked it as deprecated

[addison74]

I looked over the code and the changes concern only the frontend and the printed page. The rest for the email remained as it was initially. Am I right?

The problem of viewing in different email clients was well discussed. SVG is not well digested by some of them. However, as a small improvement, maybe we should leave behind the GIF format and replace the file named logo.gif with an image in PNG format.

[fballiano]

yes the emails remain untouched

[fballiano]

Merged per 1 green and 2 gray checks

[sreichel]

Not so nice. I disagree with changing existing update scripts :/ Better add a new one.

[fballiano]

Not everybody always have your same ideas.

[sreichel]

Why not add a new update script - as it was done before?

[addison74]

If someone does an installation from scratch then the db script will be executed. If he does not then the script is not run and the old data remains in the database. I tend to agree with Sven and with the rule that when changes are made to the db installation scripts, new ones should be created, precisely so that the change is operated in all cases.

[fballiano]

To ask a change after these many weeks…
Anyway I don’t remember everything of this pr since it’s been there for looong time anyway to change user data is not always a good idea just because it seems cleaner.

so old data stays ok while a new install gets the new data.

[fballiano]

And anyway anybody can always write a new pr with a new script if he feels thats necessary

[sreichel]

@addison74 thanks. There are different situation. Rolling back DB, rolling back files, resetting core_resource, plain install ...

[sreichel]

precisely so that the change is operated in all cases.

👍

[sreichel]

To ask a change after these many weeks…

Cmon ... #3148 (comment)

[addison74]

There are few of us who still contribute to this project. For this solid reason the current PR has not been completely brushed. but I am glad that there are still pairs of eyes that see issues and that they need to be discussed. I am sorry to say it publicly, but a maintainer should not ask others to create a PR or a new script, we are still addressing people who have expectations from us and above all a different level of knowledge. It's like going to a car service and the mechanic asks us to do something related to his knowledge.

[fballiano]

Again, not everybody has to do what you want sven, your opinion is not the right one just because you have it.

You know how to open a pr if you want, don’t just complain when somebody else tries to do something

[fballiano]

@addison74 i do not agree. Maintainers should make their hands dirty instead pf just complaining when somebody does something.

[sreichel]

@fballiano i highly appreciate what you do for OM, but please keep quality over quantity.

[fballiano]

Sorry, I do not think you aprecciate my work here since your are always criticising everything I do.
Also, sorry for not meeting your quality standards, there's a million things to do on this project and I prefer doing stuff to the best of my skills instead of trying to be perfect and never finish.
There are many extremely more skilled developers than me here, I'm the first one knowing that. My first objecting is to have them create great stuff, merge it and continue to move on.

You could help me housekeeping the 85PRs that need to be taken care of, we've to examine the 1.9.4.x ones and understand if they're still useful (and rebase them) or close them. I believe that it's absolutely necessary to respect people's time and work and everybody that submitted a PR that's been abandoned should receive an update, sometimes an apology, sometimes we should finish their job. That would give users more will to participate, and I think everybody knows we would need more workforce.

[sreichel]

Sorry, I do not think you aprecciate my work here since your are always criticising everything I do.

I really do! I just do not agree with every change.

[addison74]

I believe that what we do in this repository, we do it because we like to be here, to improve our knowledge, to offer our experiences to others. At the end there should be that absolutely natural satisfaction of the programmer who leaves something behind. That's why I appreciate any opinion for and against, provided it helps us move forward.

In the case of this PR, I agree with Sven, the changes should also cover the current installations. If Sven can make a new PR it would be wonderful, I approve it immediately.

[sreichel]

You could help me housekeeping

Na. I have done it for years and have no mood for it.

(PS: when you close PRs ... maybe add fixed, invalid, wont be fixed tags ...)