Sure. I'm opening a PR now! On Thu, Apr 16, 2026 at 3:31 PM Andor Molnár <[email protected]> wrote:
> 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 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>> > >> > >
