WordPress.org theme replacing custom theme of same name.

[mattk1980]

I'm using WordPress version 6.7.1 and i've created a custom child theme called "Starburst". Which is a child of the generatepress theme.

Wordpress isn't recognising my theme and is using a theme called "Starburst" from wordpress.org.

Very strange because it worked fine but then suddenly changed to this theme i've never seen before.

[siliconforks]

Can you try adding the header Update URI: false to your custom theme?

See: ​https://make.wordpress.org/core/2022/10/06/introducing-update-uri-theme-header-in-wordpress-6-1/

[abcd95]

Hey @mattk1980, Welcome to Trac, and thanks for bringing this up!

I once had a similar problem with my child theme, but I renamed it to something unique and the problem was solved. But what @siliconforks suggests there is also a possible solution since setting Update URI to false explicitly tells WordPress NOT to check for updates for this theme
and this prevents WordPress from looking in the WordPress.org repository and accidentally replacing your custom theme.

[mattk1980]

Thank you for your help here, i ended up just giving it a new name. It made me think though, would it be possible for someone to create a theme on wordpress.org deliberately targeting someones custom child theme name (without the Update URI header)? In order to override their website with malicious code?

Apologies. I don't know how the wordpress.org website works. I dare say someone has already thought of this and it's not possible.

[siliconforks]

Replying to mattk1980:

Thank you for your help here, i ended up just giving it a new name. It made me think though, would it be possible for someone to create a theme on wordpress.org deliberately targeting someones custom child theme name (without the Update URI header)? In order to override their website with malicious code?

Well, obviously, malicious code is not allowed in the theme directory, and if someone managed to add a theme with malicious code it would presumably be taken down pretty quickly. But yes, potentially someone could create a malicious theme in the theme directory with the same name as an existing theme (not available in the theme directory), and that could overwrite the existing theme. I would recommend always using the Update URI header for themes which are not in the theme directory.

[mattk1980]

By malicious I also mean someone who wants to just have links to their malicious website for seo purposes. e.g someone creates a theme which links to their malicious website and the sole purpose of the theme is to gain links from the target because they know their theme could get overwritten with the bogus one. It would be a short term gain i guess. I don't think it would always be obvious the bogus theme is malicious. They may just want a competitors website to be overwritten with the bogus theme.

Maybe it should be a choice to look at wordpress.org for themes and not be the default should the Update URI header not exist.

If you think the conditions for this are very unlikely then maybe i'm misunderstanding the logic of how this happened with my website. It was a brand new setup so perhaps I have created an unusual situation.

[siliconforks]

Replying to mattk1980:

Maybe it should be a choice to look at wordpress.org for themes and not be the default should the Update URI header not exist.

Well, I think the reason it's the default behavior is that themes sometimes receive critical security updates from wordpress.org and users probably should receive those by default. If it's not the default, then some users will inevitably forget to enable the option or simply be unaware that the option exists.

If you think the conditions for this are very unlikely then maybe i'm misunderstanding the logic of how this happened with my website. It was a brand new setup so perhaps I have created an unusual situation.

It's not really an unusual situation: name collisions are not uncommon. But WordPress doesn't really have any way of detecting them (other than using the Update URI header). WordPress doesn't know that your "starburst" theme is different from the "starburst" theme in the wordpress.org theme directory; it thinks that you're running an old version of the "starburst" theme from wordpress.org and there's an update available (which could be an important security update).

[mattk1980]

Just to understand this correctly. If I changed my theme name back to "Starburst" and "Starburst" existed as a theme in my local folder it wouldn't pick the "Starburst" theme from wordpress.org by default, is that right?

I think i've possibly misunderstood the logic. If thats the case then i think this isn't really an issue more of a mistake i've made when setting up this new theme.

[siliconforks]

Replying to mattk1980:

Just to understand this correctly. If I changed my theme name back to "Starburst" and "Starburst" existed as a theme in my local folder it wouldn't pick the "Starburst" theme from wordpress.org by default, is that right?

No, the theme will likely be overwritten with the theme from the wordpress.org theme directory the next time WordPress checks for updates.

I think i've possibly misunderstood the logic. If thats the case then i think this isn't really an issue more of a mistake i've made when setting up this new theme.

Well, this is a known issue, and has been for a long time - that's the reason the Update URI header was designed and implemented: to prevent this from happening.

[mattk1980]

Replying to siliconforks:

Replying to mattk1980:

Just to understand this correctly. If I changed my theme name back to "Starburst" and "Starburst" existed as a theme in my local folder it wouldn't pick the "Starburst" theme from wordpress.org by default, is that right?

No, the theme will likely be overwritten with the theme from the wordpress.org theme directory the next time WordPress checks for updates.

I think i've possibly misunderstood the logic. If thats the case then i think this isn't really an issue more of a mistake i've made when setting up this new theme.

Well, this is a known issue, and has been for a long time - that's the reason the Update URI header was designed and implemented: to prevent this from happening.

I understand the solution, it seems ok but it seems that its quite a critical piece of text to have in the style.css. accidently adding a theme name that you didnt know exists on wordpress.org without this URI could be quite confusing. I actually thought my website had been hacked at first, but thought it was an odd hack.

Would a child theme ever be a theme from wordpress.org e.g my parent theme is generatepress, my child theme has this in the css:

Template: generatepress

Would it still need to be overriden by a wordpress.org theme for an update? I can't imagine that scenario being common.

I guess if this issue has been around for a while someone far more advanced than me would of thought of a solution by now!

Thanks for your help again.

[siliconforks]

Replying to mattk1980:

I understand the solution, it seems ok but it seems that its quite a critical piece of text to have in the style.css.

Yes, you should always have that Update URI header in your style.css (unless your theme is in the wordpress.org theme directory - meaning it's actually your theme in the directory, and not just another theme that happens to share the same name).

Would a child theme ever be a theme from wordpress.org e.g my parent theme is generatepress, my child theme has this in the css:

Template: generatepress

Would it still need to be overriden by a wordpress.org theme for an update? I can't imagine that scenario being common.

That doesn't really make much difference - child themes are allowed in the wordpress.org theme directory too.

[peterwilsoncc]

I know when WP Core merges a new bundled theme, there is a certain point that a theme slug will be blocked in a theme directory if it used by a certain number of websites. I have no idea what the number is, as it's managed by the WP.org meta team, but I think it's relatively low.

That means that if a premium theme uses the slug popular-premium-theme, a theme with the same slug is unable to be submitted to the theme directory once it hits a certain number of installs.

As @siliconforks says, for custom themes it's critical to use the UpdateURI header to prevent updates from WordPress.org.

I see a suggestion of reversing the process so the update URI header needs to be set to call for updates from WOrdPress.org. Unfortunately this isn't a workable solution as once the switch was made, there would be no way to update legacy themes without the header.

As such, I'm going to close this ticket as wontfix with regard to reversing the process.