Thanks David. Totally agree. Can we move on with the new website Yurii? What do you need to open pull request? What are the open questions?
Andor > On Apr 16, 2026, at 02:07, Dávid Paksy <[email protected]> wrote: > > Hi All, > > In the meantime the Apache Phoenix team merged the new website, you can see > it here: https://phoenix.apache.org/. > > On the other day I had to wait for an hour and I only had my smartphone on > me and I was able to read ZooKeeper documentation from the redesigned > website and learn from it. While not impossible, it would be harder to do > this with the current documentation pages. > > Regarding security vulnerabilities, actually the current ZooKeeper website > page contains Bootstrap v4.1.3 which is end-of-life and contains one known > XSS vulnerability and jQuery v3.3.1 which contains 4 known security > vulnerabilities, including the critical CVE-2019-11358 (Prototype > Pollution) and multiple Cross-Site Scripting (XSS) issues. > > Personally I'd vote for technical modernization here to fix the current > CVE-s and because this also makes the documentation more easy to approach. > I can also offer my help in the website dependency updates. > > Best Regards, > Dávid > > > Yurii Palamarchuk <[email protected]> ezt írta (időpont: 2026. > ápr. 2., Cs, 10:48): > >> Here is the code: >> >> https://github.com/yuriipalam/zookeeper-website >> >> It's not a PR for the zookeeper repo yet. >> >> Regards, >> Yurii >> >> On Thu, Apr 2, 2026 at 3:33 AM Christopher <[email protected]> wrote: >> >>> Where is the code for the react version of the site? >>> >>> On Wed, Apr 1, 2026 at 2:53 AM Dávid Paksy <[email protected]> wrote: >>>> >>>> Hi All, >>>> >>>> To have a sense about maintenance need, you can see the JavaScript >>>> dependabot PR-s in the HBase repo here: >>>> >>>> >>> >> https://github.com/apache/hbase/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+label%3Ajavascript >>>> >>>> So yes, it requires some maintenance. >>>> I'd also recommend to enable Dependabot dependency updates as they are >>>> helpful. But if not, running 'npm audit fix' manually is rather easy. >>>> >>>> For how the sources look you can check here what Yuri implemented for >>> HBase: >>>> >>>> https://github.com/apache/hbase/tree/master/hbase-website >>>> >>>> >>>> Best regards, >>>> Dávid >>>> >>>> Christopher <[email protected]> ezt írta (időpont: 2026. márc. 31., >> Ke >>>> 22:47): >>>> >>>>> It's also pretty easy to use dependabot on the website repo to check >>>>> for updated site dependencies. That should be easy to handle if the >>>>> assets are included in the repo itself, and not loaded from other >>>>> domains, as per the ASF policy >>>>> (https://privacy.apache.org/policies/website-policy.html) >>>>> >>>>> On Tue, Mar 31, 2026 at 11:05 AM Yurii Palamarchuk >>>>> <[email protected]> wrote: >>>>>> >>>>>> I know about it, and we're not affected by it. This vulnerability >>> allows >>>>>> attackers to bypass the React's server authentication, but we don't >>> use >>>>> it. >>>>>> We don't have any runtime node.js server, so we aren't affected by >>> any of >>>>>> these. >>>>>> >>>>>> Best Regards, >>>>>> Yurii >>>>>> >>>>>> On Tue, Mar 31, 2026 at 4:38 PM Patrick Hunt <[email protected]> >>> wrote: >>>>>> >>>>>>> this is from december :-) >>>>>>> >>> https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 >>>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> On Tue, Mar 31, 2026 at 7:27 AM Yurii Palamarchuk < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> You are right, there are almost no concerns. The entire website >>> is >>>>>>> static, >>>>>>>> only the server providing the assets is running. The only issue >>>>> could be >>>>>>> if >>>>>>>> some node.js package becomes vulnerable, allowing hackers to >> run >>>>> scripts >>>>>>> on >>>>>>>> users' machines, but this scenario is highly unlikely. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Yurii >>>>>>>> >>>>>>>> On Tue, Mar 31, 2026 at 4:22 PM Patrick Hunt <[email protected] >>> >>>>> wrote: >>>>>>>> >>>>>>>>> What are the security implications of running React on the ZK >>>>> website? >>>>>>> Is >>>>>>>>> that going to mean additional concerns (eg cve tracking as >>> well as >>>>>>> source >>>>>>>>> security bugs, tracking the "latest react" version and so >>> on...). I >>>>>>>>> believe right now we just have very simple static pages which >>>>> require >>>>>>>> very >>>>>>>>> minimal oversight? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Patrick >>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Thanks everyone for your reviews! >>>>>>>>>> >>>>>>>>>> The only approach I considered for updating the >> documentation >>>>> version >>>>>>>> is >>>>>>>>> a >>>>>>>>>> manual one. It looks like this: >>>>>>>>>> 1) Checkout to the `website` branch. >>>>>>>>>> 2) Build the latest change for the current version, right >>> before >>>>> the >>>>>>>>>> update. >>>>>>>>>> 3) Move the build to `public/released-docs/` and rename the >>>>> directory >>>>>>>> to >>>>>>>>>> the corresponding version. >>>>>>>>>> 4) Update the `CURRENT_VERSION` constant, so now it matches >>> the >>>>> new >>>>>>>>>> version. >>>>>>>>>> 5) Open a PR. >>>>>>>>>> >>>>>>>>>> The Java API docs are built by maven as far as I can tell, >> so >>>>> it's >>>>>>> not >>>>>>>>>> related to the website actually. >>>>>>>>>> >>>>>>>>>> Regarding the automatization of this process, I've never >> done >>>>>>> anything >>>>>>>>> like >>>>>>>>>> this before. Therefore, if you have any suggestions - I'm >>> open to >>>>>>> it, I >>>>>>>>>> think it should be possible since the workflow is not >>> complex at >>>>> all. >>>>>>>>> Most >>>>>>>>>> likely a small bash script could be enough. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Yurii >>>>>>>>>> >>>>>>>>>> On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár < >>> [email protected]> >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Exactly. My 2 cents are: >>>>>>>>>>> >>>>>>>>>>> 1. Storing the entire website at a single location is >>>>> desirable. >>>>>>>> Given >>>>>>>>>> the >>>>>>>>>>> proposed >>>>>>>>>>> technology changes there’s no clear separation possible >>> without >>>>>>>>>> duplicating >>>>>>>>>>> website core logic components which will be a maintenance >>>>> nightmare >>>>>>>> in >>>>>>>>>> the >>>>>>>>>>> long term. >>>>>>>>>>> >>>>>>>>>>> 2. Separate ‘website’ branch or versioned branches. As >>> Patrick >>>>>>>>> mentioned >>>>>>>>>>> the docs are versioned and the ability to accompany doc >>> changes >>>>>>> with >>>>>>>>>>> code changes in the same PR is a big advantage. >>>>>>>>>>> >>>>>>>>>>> Andor >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 30, 2026, at 19:52, Patrick Hunt < >>> [email protected]> >>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> One reason I remember the docs/api/etc... are part of >> the >>>>> source >>>>>>> is >>>>>>>>>> that >>>>>>>>>>>> they are versioned along with it. PRs -- doc changes >>> along >>>>> with >>>>>>>> code >>>>>>>>>>>> changes also part of the release process. >>>>>>>>>>>> >>>>>>>>>>>> Patrick >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 30, 2026 at 5:39 PM Christopher < >>>>> [email protected] >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I think it looks great, but I would really like to see >>> the >>>>> SCM >>>>>>>>> source >>>>>>>>>>>>> for this new site, so I can understand the >>> maintenance/build >>>>>>>>> workflow >>>>>>>>>>>>> for it, before I'd have any useful opinion other than >>>>> regarding >>>>>>>>>>>>> aesthetics. >>>>>>>>>>>>> >>>>>>>>>>>>> I definitely concur with moving the docs out to the >>> site to >>>>>>>>> centralize >>>>>>>>>>> it. >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for your comment, Patrick. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why React? >>>>>>>>>>>>>> Building a website nowadays is not just HTML + CSS, >>> because >>>>>>> doing >>>>>>>>> it >>>>>>>>>>> this >>>>>>>>>>>>>> way turns the developer experience into a nightmare. >>> With >>>>> React >>>>>>>> we >>>>>>>>>>>>>> effortlessly have consistent UI components across all >>>>> pages, >>>>>>>>>> including >>>>>>>>>>>>>> buttons, tables, markdown rendering, colors, and much >>>>> more. We >>>>>>>> also >>>>>>>>>> add >>>>>>>>>>>>> the >>>>>>>>>>>>>> interactivity much more easily with React. A static >>> website >>>>>>>> doesn't >>>>>>>>>>> mean >>>>>>>>>>>>> it >>>>>>>>>>>>>> lacks interactivity; it often has significant >>>>> interactivity, >>>>>>>>>> especially >>>>>>>>>>>>> in >>>>>>>>>>>>>> the documentation section. The difference is that we >>> don't >>>>> need >>>>>>>> any >>>>>>>>>>>>> runtime >>>>>>>>>>>>>> environment, we just return the files generated at >>> build >>>>> time, >>>>>>>>> which >>>>>>>>>>> are >>>>>>>>>>>>>> ultimately just HTML, CSS, and JS. The website also >> has >>>>> dark >>>>>>> mode >>>>>>>>>>>>> support, >>>>>>>>>>>>>> search in the documentation, smooth transitions >> between >>>>> pages >>>>>>> (no >>>>>>>>>> hard >>>>>>>>>>>>>> reload), so it gives smooth and better user >> experience >>>>>>> overall. I >>>>>>>>>> hope >>>>>>>>>>>>> this >>>>>>>>>>>>>> answers your question. Moreover, the website will >> work >>>>>>> absolutely >>>>>>>>>> fine >>>>>>>>>>>>> even >>>>>>>>>>>>>> for those who have JS disabled, this is called >>> progressive >>>>>>>>>> enhancement. >>>>>>>>>>>>>> Initially, the server returns HTML and CSS. The >> browser >>>>> renders >>>>>>>>> them >>>>>>>>>>> and >>>>>>>>>>>>>> tries to fetch the JS files. If it doesn't succeed, >> the >>>>> page >>>>>>>>> remains >>>>>>>>>>>>>> accessible, though it obviously lacks interactivity. >> I >>> hope >>>>>>> this >>>>>>>>>>> answers >>>>>>>>>>>>>> your questions, if not, feel free to ask more about >> it! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it hard for ZK devs to update the content? >>>>>>>>>>>>>> Not at all! I tried to make it so the learning curve >>> for >>>>> non-JS >>>>>>>>> devs >>>>>>>>>> is >>>>>>>>>>>>>> almost 0. For the documentation you still just need >> to >>>>> edit the >>>>>>>> MDX >>>>>>>>>>>>>> (Markdown Extended) files and run the build command. >> I >>> will >>>>>>> also >>>>>>>>> add >>>>>>>>>> a >>>>>>>>>>>>> bash >>>>>>>>>>>>>> script to automate the build process. For the landing >>>>> pages, >>>>>>> you >>>>>>>>>> still >>>>>>>>>>>>>> mostly only need to modify the markdown files. Only >> the >>>>> main >>>>>>> page >>>>>>>>>> isn't >>>>>>>>>>>>>> markdown, modifying something small wouldn't be a >>> problem. >>>>> In >>>>>>> the >>>>>>>>>> worst >>>>>>>>>>>>>> case, if something more complex is required, you can >>>>> handle it >>>>>>>> with >>>>>>>>>> the >>>>>>>>>>>>> AI. >>>>>>>>>>>>>> Nevertheless, the website hasn't been updated for >>> years, >>>>> so it >>>>>>>>>> wouldn't >>>>>>>>>>>>> be >>>>>>>>>>>>>> a big loss :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Yurii >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt < >>>>> [email protected] >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi there, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am proposing an upgrade to the ZooKeeper website >>> and >>>>>>>>>>>>> documentation. We >>>>>>>>>>>>>>>> are moving to a modern React.js stack, which allows >>>>> landing >>>>>>>> pages >>>>>>>>>> and >>>>>>>>>>>>>>>> versioned documentation to live in a single >>> application >>>>>>> sharing >>>>>>>>> the >>>>>>>>>>>>> same >>>>>>>>>>>>>>> UI >>>>>>>>>>>>>>>> components, libraries, colors, etc. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The plan is to move all website and documentation >>> source >>>>> code >>>>>>>> to >>>>>>>>>> the >>>>>>>>>>>>>>>> website branch and remove the zookeeper-docs Maven >>>>> project >>>>>>> from >>>>>>>>> the >>>>>>>>>>>>>>> master >>>>>>>>>>>>>>>> branch. This decouples the Node/JS build >> environment >>>>> from the >>>>>>>>> core >>>>>>>>>>>>> Java >>>>>>>>>>>>>>>> repository. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Versioned docs will be managed via archived folders >>>>> within >>>>>>> the >>>>>>>>>>>>> website >>>>>>>>>>>>>>>> branch. Documentation updates would move from >> master >>> to >>>>> PRs >>>>>>>>> against >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> website branch. Also I'm not planning to keep the >>> app as >>>>> a >>>>>>>> maven >>>>>>>>>>>>> project, >>>>>>>>>>>>>>>> since it's fully JS based. To keep it simple, I >> will >>>>> write a >>>>>>>> bash >>>>>>>>>>>>> script >>>>>>>>>>>>>>>> that installs the dependencies, runs the tests, and >>> the >>>>>>> build. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What do you think about moving the docs out of >>> master to >>>>>>>>> centralize >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> site? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Preview: https://zookeeper-website.vercel.app/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looks pretty slick - nice update and visual refresh! >>>>> Question >>>>>>>>>> though - >>>>>>>>>>>>> why >>>>>>>>>>>>>>> React? This is a static website, what are the >> pro/con >>> of >>>>> React >>>>>>>>>> based? >>>>>>>>>>>>> Can >>>>>>>>>>>>>>> you explain the impact on common use cases like >> making >>>>>>> updates? >>>>>>>> ZK >>>>>>>>>>> team >>>>>>>>>>>>>>> includes a number of people, not all of whom might >>> know >>>>> React, >>>>>>>> how >>>>>>>>>>> hard >>>>>>>>>>>>>>> will it be for them to make changes? Impact on the >>> release >>>>>>>>> process? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Patrick >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Yurii Palamarchuk >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >>
