Yeah, we specifically plan to make changes in this vein eventually:

• The web UI will give you an "Upload File..." dialog instead of requiring you to go look up a PHID.
• The web UI will resize the image you upload and/or reject images which have the wrong size instead of letting you get a bad result by mistake.
• We'll set the policy and cache information correctly without manual work, instead of needing to go digging around in the database.

We probably won't revisit this terribly soon, though.

Been thinking if we go back to the rainbow logo, no one will want to change it maybe?

Rainbow logo was pretty fabulous.

I was easily able to get it to display a logo image that I uploaded to the files app. However, I didnt like the result. I followed the same process to configure an alternate image but it doesn't work. It accepts the setting and saves the correct PHID, but when the page is rendered, the inline css still points to the old image. It's not related to caching because I cleared my browser cache and I also cleared php cache and restarted nginx. If I remove the custom logo from the config, it goes back to default. Though when I add any other PHID to be the logo it displays nothing at all in the logo area (b/c the image it tries to show doesn't exist).

cleared php cache

How did you do this? If it was anything other than "by restarting php-fpm", try doing that.

We had a similar experience, set the initial PHID for an image file, didn't like the result and then used the same process to change the image. The PHID changed, but the old file was displayed. I think we found the image was cached in the phabricator_cache database, after clearing those caches the new image displayed.

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

$ bin/cache purge --purge-all

We should also probably put the PHID in the cache key.

In T4214#99869, @epriestley wrote:

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

$ bin/cache purge --purge-all

We should also probably put the PHID in the cache key.

I can confirm that the purge command resolved the issue. Thanks!

D13040 makes this not blocking of the Redesign.

So the current behavior is exactly the opposite of what I expected - changing the "logo" changes the "PHABRICATOR" wordmark in the header but leaves the eye image. Hmmm... I would think it better to keep phabricator but replace the eye.

You want less space?

@chad: No, we just want a way to nuke the "eye" logo.

I suppose a custom css tweak would probably make the most sense, even if it does mean merge conflicts down the road.

I agree with @20after4: We would also like to insert our organisation's logo instead of the "eye". Replacing the text alone feels insufficient.

I think that Phabricator should be "white label" software that anyone can take and quickly configure so it looks like it comes 100% from their own organization. That way, new users won't have any idea they are using Phabricator, and will instead think their own organization has some sweet tools, or in the SaaS competitor case, that SaaS competitor A really builds some great software!

Just kidding. That sounds like a terrible idea for the long term success of Phabricator.

We call it "Wikimedia Phabricator" and our community talks about "Phabricator". Therefore [Wikimedia logo] + "Phabricator" makes sense, while "[What is this spooky eye?] + "Wikimedia" will create more confusion than the vanilla Phabricator header. I think the perceptions in other communities using Phabricator will be similar. All of them know their own logos, and all of them will recognize "Phabricator".

What I didn't explain is that this Phabricator header was one of the most contentious topics among some of our most experienced volunteers and some of my managers too. They were happy to fork the header and assume the cost of maintaining the local code. I calmed the discussion by promising that one day this will be fixed. So yes, communities care about their logos.

PS: if my story encouraged you to lower the priority from Normal to Wishlist, maybe I should have done something different on my Friday afternoon. :)
PS2: The "spooky eye" is not an hypothetical expression, I'm just quoting. In any case, as of today it doesn't compete with the popularity of the "Phabricator" wordmark.

Previously, we had one logo (eye + wordmark). On mobile, the eye was hidden leaving just the workmark. This was because of space constraints. In allowing installs to change the "logo", it made sense to have that be the workmark, which would appear on mobile. Eventually we resolved the mobile header and reclaimed that space, showing again both the eye and wordmark. I can't guarantee this will last depending on how Spaces plays out. If we add switching into the header, we might go back to hiding the eye on mobile. This is why we're currently replacing the wordmark.

At any rate, if we're going to do white boxing, I'd rather properly plan it through and through, not just a header image. (as in, it'd get sprinkled various places like login screens, etc).

+1 to what qgil says.

It's not a big deal for us at the moment (at least not to the point where we can be bothered to do anything about it right now), but if we were to see more usage of our public instance, we would probably be forced to do something, and the target would definitely be the logo. Having it say "Phabricator" up top is not a big deal - but the logo would be. Having our logo up top would let people know at a glance that they are still on our Phabricator (easy to get confused, especially for those of us who move between multiple instances).

In T4214#120383, @qgil wrote:

What I didn't explain is that this Phabricator header was one of the most contentious topics among some of our most experienced volunteers and some of my managers too. They were happy to fork the header and assume the cost of maintaining the local code. I calmed the discussion by promising that one day this will be fixed. So yes, communities care about their logos.

PS: if my story encouraged you to lower the priority from Normal to Wishlist, maybe I should have done something different on my Friday afternoon. :)
PS2: The "spooky eye" is not an hypothetical expression, I'm just quoting. In any case, as of today it doesn't compete with the popularity of the "Phabricator" wordmark.

I have no idea how this got prioritized above "Wishlist" as while its an item that people "care" about but it doesn't yield any strategic benefit from the upstream perspective. Empirically, we have shown that despite angst in a given community not having these features it is not a strong blocker for Phabricator adoption. Hypothetically, folks have argued that white labeling features will have a non-negative impact on future Phabricator growth as well as improve the experience of their local installs; apologies that I don't want to risk future Phabricator growth in a higher priority fashion on a theory where the theorists have clear bias to simply improve their local situation. That said, "wishlist" doesn't mean never.

This got raised to "Normal" so we could brand Phacility on admin.phacility.com

In T4214#98858, @chad wrote:

Been thinking if we go back to the rainbow logo, no one will want to change it maybe?

I was thinking along the same lines. That is, perhaps one way to mitigate this issue would be to use a less creepy and off-putting default image? To me, the eye is really bad.

Maybe in someone else's culture, it works for them, and I'm fine with that. What I'm not fine with is having this image hardcoded into the user interface. Looking at D11886 and T7165, it seems even sillier not to have this customization option.

In T4214#120375, @btrahan wrote:

I think that Phabricator should be "white label" software that anyone can take and quickly configure so it looks like it comes 100% from their own organization. That way, new users won't have any idea they are using Phabricator, and will instead think their own organization has some sweet tools, or in the SaaS competitor case, that SaaS competitor A really builds some great software!

Just kidding. That sounds like a terrible idea for the long term success of Phabricator.

In my reading, these types of comments are just an exhibition of some deep personal insecurity about your product. Great features, a clean user interface, an easy installation process, modular infrastructure, helpful technical support and documentation, and more are what give any product a competitive advantage. I don't think having a mandatory logo does.

In T4214#120453, @btrahan wrote:

Empirically, we have shown that despite angst in a given community not having these features it is not a strong blocker for Phabricator adoption.

"Not a strong blocker for Phabricator adoption" is not a reasonable standard for feature inclusion or exclusion. I understand and appreciate the consequences of technical debt and feature creep, but in a case like this, another question you have to consider is: what kind of horrible hacks will my users deploy in order to do this anyway?

Replace the eye image on the file system with something else and re-generate some sprite? Use custom CSS injected somewhere in a PHP file? Maybe some server-side include after the page's HTML is put together?

And in my experience, each of these horrible hacks that site administrators feel compelled to implement have predictably negative consequences, such as reducing the likelihood of performing a future software upgrade.

If we look at other software packages, logo customization is pretty standard. Even here there doesn't seem to be much argument against the idea. Which brings us to why I'm following this task at all...

For Wikimedia's purposes, as far as I'm concerned, @qgil has had his chance to get upstream to fix this. It's starting to get to be the time when we pick a horrible hack and maintain that for now until this task gets resolved.

Although I like the name Phabricator, and I am not so fond of the logo, I don't think anyone should fault the upstream for their priorities, and the fact that you need to keep your options open, to maintain design flexibility, that is totally reasonable.

Maybe a good solution would be to offer a clean(er) integration point for adding a few lines of custom css, without causing merge conflicts. Essentially a blob of css that can be configured without hacking any files in the core (to avoid risk of merge conflicts). Bonus points if the custom css gets properly optimized and cached but really just spitting it out inline within the page <head> would be good enough for a simple customization. It would still be less than ideal but it would be cleaner than arbitrary hacks. It would be easy to make it clear to downstream users that we are still implementing an unsupported hack and upstream changes might break the custom css at some point. But when that happens it probably won't be very hard to update our hacks to compensate for upstream changes.

In T4214#120610, @MZMcBride wrote:

For Wikimedia's purposes, as far as I'm concerned, @qgil has had his chance to get upstream to fix this. It's starting to get to be the time when we pick a horrible hack and maintain that for now until this task gets resolved.

@MZMcBride: I agree that it is probably time to hack away. We already changed the favicon and I'm really glad we did. It looks nice and makes it easy to see which tab belongs to each phabricator instance.

I will look into it and try to come up with a minimally invasive way to add a couple of lines of css.

It shouldn't really cause us to avoid upgrades - I am committed to (almost-)weekly upgrades of phabricator. It might just cause me some headaches when the upstream does a redesign. I say we take this discussion back to the wikimedia phabricator instance though, no use cluttering this task any further than we already have.

+1 to qgil's suggestion. Our logo looks like this:

And this is how our Phabricator is currently branded:

However, I would much rather it branded like this:

This is how Wikimedia Phabricator is branded as well. The tool is not "Everalbum", it's "Phabricator". The all-seeing eye icon doesn't convey that, and I'm not entirely sure how its presence helps spread Phabricator (which seems to be the concern around a custom logo feature). If the goal is to ensure users know they're using Phabricator, spelling the name out seems like it would accomplish that better.

I strongly recommend a standard panda icon be shipped as a recommended alternate icon.

In T4214#128906, @beng wrote:

I strongly recommend a standard panda icon be shipped as a recommended alternate icon.

I have awarded you some Flimsy Cardboard for this participation in Phabricator.

I thought I'd mention one other thing, since apparently the holdup on this issue is concerns over Phabricator branding. No-one on our team knows what Phabricator is called—they call it Phacility because that's what's in the URL. Allowing customization of the square icon instead of the "Phabricator" text would resolve that issue.

With as much opinions as participants or more, it's important to focus on what user wants to achieve and what Phacility wants to preserve.

All users are concerned with ensuring that their staff/contributors/users know that they are in good place, namely - within environment they want to interact with. Theoretically one look at header should be enough to say "You are in good place, carry on". Most people on this thread would be content with preserving "PHABRICATOR" wordmark, while exchenging "Spooky Eye" with company/organization logo. It does seem veeery consistent.

Phacility wants to maintain brand identity (which is VERY important) - this is very good sign. Currently design is very distinct, looks great etc, and if You enter any recent enough instance of phabricator it looks & feels like phabricator, despite any and all customizations - this is also very good for brand. Some have swapped out PHABRICATOR wordmark, wikimedia has spooky eye swapped out and this instance + phacility instances have wordmark.

I'm not opiniating any way but wikimedia looks best out of those customized - it maintains wordmark while having nice, identifiable organization logo placed. In one of instances i'm administrating due to branding constraints I have weird "[eye] [brand icon] [brand name]" that does not look good ;) best would be in that instance "[brand icon] [brand name] PHABRICATOR" as expressed by owner... However generall consensus is that if "[brand icon] PHABRICATOR" woulb be possible, then that would be preffereable.

test

Would definitely like the ability to swap out the eye via config à la wikimedia install.

Are customizing styles and retaining the Phabricator brand altogether mutually exclusive?

I don't think so. Not if you take the approach letting the user add customizations to a baseline which is not editable from the config iface.

So you would ADD your logo to the right or left of the all seeing eye. You would ADD a custom footer above or below whatever Phabricator likes at the bottom of the page.

MS used to do this with the title bar in IE. I think it was something like IE for so-and-so-company.

As a user that sort of thing and some color tweaks would be perfectly adequate for me.