Request for Wiki Account - Sepehr Mahmoudi: View as Markdown

Hi Sepehr

,  I would like to request a Wiki account to propose a new addition to
the PHP core
Proposal: A built-in function to dynamically detect and return the
website's favicon URL (e.g., get_favicon()).
Motivation:
Currently, developers have to manually handle favicon paths. I have
developed a logic that automates this process by dynamically detecting
the favicon file within the project structure without requiring
parameters. I believe having a standard, built-in way to handle this
would improve the developer experience and make PHP more web-integrated.

I have trouble understanding what it is this function would do exactly.
Can you describe that in a high level?

Thanks,
Ilija

Le 13/06/2026 à 19:03, سپهر محمودی a écrit :

, Hi Internals
My name is Sepehr, and I am a web developer. I would like to request a
Wiki account to propose a new addition to the PHP core
Proposal: A built-in function to dynamically detect and return the
website's favicon URL (e.g., get_favicon()).
Motivation:
Currently, developers have to manually handle favicon paths. I have
developed a logic that automates this process by dynamically detecting
the favicon file within the project structure without requiring
parameters. I believe having a standard, built-in way to handle this
would improve the developer experience and make PHP more web-integrated.
Requested Username: Sepehrphp
Email: sepehrphpr@gmail.com
I have a working prototype and I am ready to start the RFC process.
Best regards,
Sepehrphp

HTML already defines a way to configure favicons using the <link rel="icon"> tag and its internal parameters (media, type, etc.).

If no such link is defined in the HTML code, or if the page is not HTML
(pdf, json, image, etc.), most browsers will attempt at fetching the
"/favicon.ico" URL, which implies that it's becoming a standardized
method to both fetch an icon from a page AND create a fallback for any
HTTP server.

Plus, I wouldn't see the actual benefits of a "get_favicon()" function
that returns a "single URL", considering that the <link rel="icon">
tag's behavior is to adapt depending on several contextual information,
like "media" (which is basically a media-query), "type" (which is a
mime-type, allowing compatibility with lots of different formats) and
"sizes" which allows displaying different source media depending on the
final displayed size: the icon in the Windows taskbar will be smaller
than a shortcut for this website on a mobile's homepage, so the first
one can use a lightweight ".ico" image, and the last one can use a
scalable SVG for instance.

I'm curious about what exactly your RFC would provide.

Hi Sepehr,

Could you explain why this functionality should be part of PHP core rather
than a Composer package or framework-specific helper?

PHP is used in many contexts outside traditional websites (CLI
applications, daemons, APIs, desktop applications, etc.), and favicon
discovery appears to be specific to web applications.

Additionally, favicon locations are not standardized. Sites may use
/favicon.ico, HTML link tags, SVG icons, multiple icon sizes, CDN-hosted
assets, or framework-specific asset structures. Because of this, it is not
obvious how PHP core could reliably determine a favicon without making
assumptions about application structure.

It would be helpful to see more details about the prototype and the
specific problem that cannot be solved effectively in userland.

Regards,
Diogoagc

سپهر محمودی sepehrphpr@gmail.com escreveu em sáb., 13/06/2026 às 18:04 :

, Hi Internals
My name is Sepehr, and I am a web developer. I would like to request a
Wiki account to propose a new addition to the PHP core
Proposal: A built-in function to dynamically detect and return the
website's favicon URL (e.g., get_favicon()).
Motivation:
Currently, developers have to manually handle favicon paths. I have
developed a logic that automates this process by dynamically detecting the
favicon file within the project structure without requiring parameters. I
believe having a standard, built-in way to handle this would improve the
developer experience and make PHP more web-integrated.
Requested Username: Sepehrphp
Email: sepehrphpr@gmail.com
I have a working prototype and I am ready to start the RFC process.
Best regards,
Sepehrphp