New front page (Draft) - #1962
Conversation
…thout having to rely on global-scoped variables.
…le fallback for 'updated' => 'published'.
…ickable card and renderer
…ke strings as an escape hatch a-la dangerouslySetInnerHTML. Use it to highlight code elements in hero page.
… picking up on currentColor
|
OK! What we have in this branch, as I can see:
Here is a screenshot, since we don't have this on a preview branch: Full screen Details
Tasks I think we need to do in order to move forward with this:
I feel like I'm most equipped to be a part of the content and design conversations; as I haven't been really involved in the PHP.net site before, I'd love to leave the first item to others (not sure if @derickr has had a chance to review all this code yet; if not, it'd be great if someone could volunteer to do that.) I'll leave another comment in a minute about my thoughts, and those I've gathered from others, about content and design. |
|
OK, my thoughts on the content: What we have right nowIt feels like we've actually found a decent amount of consensus and we're ready to move forward with figuring out what really belongs on this home page! Things that are in the home page right now:
Things that are in the home page in this PR:
What we need to solve in order to move forwardAs I've been looking at my notes, and also about the conversations that have happened around this page, and the "why php page", I think these are the questions we're trying to answer as we finalize content:
I think we have to agree on those things (not DEEP IN OUR CORE AGREE 100%, but at least COME TO A GENERAL CONSENSUS) in order to make meaningful progress. But that's hard to do, because we don't have any mechanism for conversations like this yet. So. I'm going to make a proposal of what I think content should be, and hopefully we can all work through any concerns quickly and actually get this thing designed and shipped! There's a really skilled designer who's agreed to work on this when we're ready (and will share their info once they tell me they're ok with it), but we have to nail down content first. Quick caveat: yes, I’m on the PHP Foundation board, and yes, helping PHP’s public perception is one of the Foundation’s goals. But neither I nor the Foundation have any authority or desire to dictate this. I’m sharing this as a proposed framework for discussion. My proposal(LMK if there's another format I should put this into--Google Docs?--to separate the conversation around it from this GH issue) My proposal is that we agree on this idea, and then link all decisions back to this:
The audiencesHere's who I think the audiences are, in order: 1. Developers evaluating or re-evaluating PHPThis includes people who think PHP is old, slow, ugly, dead, unserious. 2. Technical decision-makersCTOs, engineering leads, educators, consultants, bootcamp/university people. People who have the influence to say "no, not (whatever framework), because it's PHP and PHP is old", or "Your perception of PHP being old is outdated, here's why". 3. Existing PHP usersThey still need fast paths to downloads, docs, releases, migration guides, events, RFCs, etc. But they should not be the only audience the home page serves, and they're more likely to be willing to navigate a bit to get there. The "jobs" of the home pageIn Jobs to Be Done parlance, we want to know what "jobs" we're "hiring" the home page to do for us. What's it responsible for? Release information is part of that, but it cannot be the whole job. But then, what is it responsible for? Here's what I think: 1. Position PHPAnswer: “What is PHP today?” Not “PHP is a popular general-purpose scripting language…”; that doesn't work toward our goals, and you can get the same from Wikipedia. Something closer to:
We can work on the exact copy, but we want a top hero level, confident, anchor sentence. 2. Prove PHPAnswer the common objections (not directly, but through examples and careful language):
Here we can reach for things like usage statistics, modern syntax, recognizable logos/projects, releases with dates, ecosystem information, community. We want to show vitality! 3. Activate the visitorAnswer: “What can I do right now?” That's CTAs for newcomers like:
We do want to persuade them, but we also want to give them a practical path to running and developing modern PHP. 4. Route existing usersAnswer: “Where do I go?” We want to keep the obvious utilities (whether directly on the home page or in the rich footer):
Existing PHP users should not feel like the home page became a marketing brochure and buried the useful stuff. 5. Show lifeAnswer: “Is PHP alive?” The home page should visibly show motion:
This is important because the negative perception we're fighting, summed up, is "PHP is dead". We need to address that on multiple angles. So what then?If we come to a place of agreement on something similar to this proposal, I think that lands us with these must-haves:
and these strong candidates / open questions:
Next stepsI think the next steps involve conversation around the questions I've asked and the proposal I've shared here, with the hope that we can at minimum agree on a single-sentence declaration of the goals of the home page and a hero hook sentence for the home page. After that, hopefully we can agree on the must-haves, and while any ongoing conversation happens about the nice-to-haves, we can potentially start with the layout and design process. My askDoes this feel like the right framework to use for deciding home page content? If not, which part should change: the goal, the audiences, the jobs, or the must-haves? |
|
@mattstauffer, I think the framework in your content proposal is a good foundation, and I agree with the main statement about how PHP should be positioned. My main addition would be to focus a little less on audiences as fixed groups and more on the journey someone is currently taking. A visitor may be discovering PHP today, evaluating it tomorrow, adopting it for a project, returning later to operate that project and, eventually, contributing to the language. So alongside JTBD, I think this flow could help organize the content: Discover > Evaluate > Adopt > Operate > Contribute This doesn't replace the audiences you proposed. It just avoids assuming that a “new developer”, a “technical decision-maker” and an “existing PHP user” are always different people. The most important part for me is your “Activate the visitor” job. I believe the first fold should get as close as possible to “copy, paste and see PHP working”. Not only a CTA pointing to another documentation page, but a real first result. PHP still gets introduced through a lot of old LAMP-oriented tutorials. LAMP is perfectly valid, but it can make the language look dependent on a complete stack before anything can run. Meanwhile, PHP already has a practical CLI and a built-in development server. Something as simple as running a script or starting a local server already proves a few things better than marketing copy does: PHP is accessible, useful outside a framework and quick to start with. The exact implementation can come later. CLI example, browser playground, built-in server, maybe more than one option. The principle is what matters now: reduce the time-to-first-result as much as possible. Installation is connected to this too. The official installation documentation needs to remain comprehensive, but comprehensive documentation isn't necessarily a good onboarding flow. New users still need to search which package manager, repository or commands are appropriate for their system. php.new shows that a one-command, copy-and-paste flow can work across operating systems. Their complete experience is Laravel-oriented, naturally, but PHP.net could provide a neutral equivalent focused only on installing the runtime. Only the runtime at first. Composer, extensions and frameworks should be presented as following choices, not silently bundled into the definition of PHP. On “Prove PHP”, I would prioritize evidence in roughly this order: first the practical experience itself, then the visible evolution of the language, contextualized benchmarks, and real examples of companies where PHP is publicly known to run an important part of the product. The distinction about companies matters. A logo isn't very convincing if PHP is only used by one small internal service. Better to show fewer examples where PHP is clearly relevant than a big logo cloud with weak context. I also think PHP.net should describe PHP first as a programming language, not as a framework ecosystem. That doesn't mean hiding the ecosystem. Quite the opposite. After someone understands and runs PHP, there should be a clear path into tools such as Composer, PHPUnit and other established categories like static analysis, coding standards and debugging. Today this discovery mostly happens outside PHP.net, through search results, blog posts and framework documentation. New developers are forced to rediscover which tools are considered standard. A tooling section could help with this, without becoming arbitrary endorsement. Mature projects could appear through public signals like adoption, maintenance and stability, while some rotation mechanism could also give newer tools and frameworks visibility. Governance and ranking criteria can be discussed separately, no need to solve all of that in this PR. About the content/design separation you mentioned earlier, I agree they should be reviewed separately, but here they need to support the same argument. If the homepage is trying to change the perception that PHP is old, limited, difficult to scale or tied to legacy stacks, the visual design cannot feel like the current documentation portal with only a new CSS layer. The code presentation, typography, navigation, density and interactions are also evidence. At the same time, it should not become a generic startup landing page. Existing users still need direct access to docs, releases, supported versions, security, migration guides and internals. For reviewing each section, one simple test may help: Audience > Intent > Evidence > Action Who is this for, what are they trying to understand, what are we showing to support the claim and what can they do next? So yes, I agree with the general framework and the jobs you proposed. The main thing I would add is that the homepage should not only explain that PHP is easy to start with, modern and practical. It should let the visitor experience that, immediately. |
|
Notes from PHP Ambassadors marketing call where we reviewed this: On the priority of existing users on the php.net web site
Other notes
|
|
Maybe off-topic, but:
I'm still not at all stoked about this website.
A bit more on-topic: IMO, a redesign should be done by a professional frontend team (if we can find any volunteers, e.g. in return for displaying their logo on the website, or have the budget for hiring someone). https://php.net has always been developed by backend or C developers, and it shows. |
|
I agree with your proposal above in terms of planning the content. In my opinion, we can cater to both categories of people on the home page with more focus on the decisions makers, but at the same time having functional components for existing/new developers. Also, I agree with @iluuu1994 regarding the importance of design in this process. It should be as important as the content and can sometimes also change content decisions. If the design is not refreshed to look like a modern website of today, any content/functionality we put in would invite the same comments. Also, this might be too early to mention and can be discussed later, it would be great to have a modern UI component library as the base, currently basic components have to be implemented from scratch and that leads to inconsistencies across the website. @macoaure |
|
Thanks @iluuu1994 and @shivammathur. I think the The focus was much more on the onboarding experience: reducing the distance between discovering PHP, installing it, and seeing something actually work. I agree that unofficial builds, update policies, dependencies and maintaining binaries for multiple operating systems are separate concerns, and outside the scope of this PR. The downloads page already provides environment-specific installation instructions, so I am not proposing that the homepage replace or duplicate it. My suggestion is that the homepage makes this practical journey more visible and connects the existing installation flow directly to a first successful result. One question, though: why would an official Bash script that only executes the same installation process already documented be inherently wrong? For Ubuntu, users already copy and paste commands provided by PHP.net. A transparent script could wrap those same instructions without introducing a custom build or a different distribution channel. Of course, trust, maintenance and platform support would still need discussion, but conceptually it would only be another interface over the existing process. So the |
|
@macoaure |
That concern makes sense for an opaque remote script, especially one that downloads unofficial binaries or does not clearly show what it changes. I don't think it means a Bash script is inherently the wrong approach, though. Rust, Julia, Elixir and other languages provide official installation scripts, while still documenting alternative installation methods. The important distinction would be transparency and provenance. An official PHP script could be public, versioned and auditable, show exactly what it is doing, and continue using the same installation sources already presented by the downloads page. It would not need to introduce a custom PHP build. That said, the same onboarding goal could also be achieved without a script: PHP.net could generate the complete commands for the selected environment and make them directly copyable. My main point remains the experience, not the implementation. A newcomer should have a clear path from discovering PHP to running it, without needing to reconstruct that path from external tutorials. |
This draft PR is meant to gather comments for the content on the refreshed landing page for php.net
Please do not merge, as it includes changes to the structure which requires modification on the webserver side.