Moving to

This is the thing that we should have done it a few years ago, but we did not because the person who maintaining the gh-pages and the person who owning the domain name was not the same person. While investigating this unrelated issue recently, I find that it is just a few clicks away to link the two together. At this juncture of the Urho3D project life, this does not really matter much, but at the very least it saves you a few key strokes to access the main site :slight_smile:


The DNS updates propagate faster than I thought. I still have to do a search and replace everywhere in our docs to use “” consistently. While I am at it, I may “refresh” the gh-pages with a newer static site generator technology. Don’t hold your breath for it though.

EDIT: completed the migration setup on “Google Search Console” and “Google Analytics” too. Let’s hope we keep the SEO ranking.

1 Like

So, I have started working on a new website using ReactJS and Docusarus 2. In order to speed up the work, I will reuse the existing content from the old website as much as possible and will use some of the screenshots from the Showcase category in the forums as new assets. For the screenshots as new assets, I assume I am allowed and has permission to do that. However, if this is not the case then the copyright owner of the screenshot can just inform me and I will substitute it immediately. Obviously I will only choose those that are relevant to Urho3D :slight_smile:, but I haven’t started choosing any yet. On the other hand, if you want the screenshots from your new game to be featured/showcase in the website, you can also PM me with the relevant material.

My plan is to release the new website progressively over the next few weeks, migrating the content from the old Jekyll site to the new one bit by bit, instead of one big bang like the one I did many years ago. It was the Jekyll site that we use till today.


You have my bypersonal, nonconfident, outproprietary, subjugated, preposterous, irrevocable permit and/or agreement to

with my content. Hopefully the others will do the same.

1 Like

The “News” (aka blog) section is now in. Temporarily there are two “News” in the navbar. The left hand side is the new one, while the right hand side is the old one. I have migrated the last 4 news entries only. I won’t be wasting my time bringing every entry over. The news content is now hosted on the main repo under Urho3D/website/news at master · urho3d/Urho3D · GitHub. So, anyone could submit PR to add new entry and/or edit the existing entry. Urho3D maintainers (with push privilege) should be able to directly modify the entry using the Github web interface. Check out the link on the lower left corner on rendered page for each entry.

1 Like

Is the documentation available anywhere while the new website is under construction?

It’s still there, there’s a legacy dropdown

Also, please tell me you’re not keeping that red font on the front page.

1 Like

I have been very careful about that. In fact all the old links that people have around the internet will still be able to get served correctly. I will minimize the number of broken links. In fact the whole legacy website is still there, what really got changed so far is the “index.html” page with all the magic of React hydration in the background. In short, currently the website is in the hybrid mode.

It is in my believe that by displaying the pale bones of the dead fish and drawing some new blood, we could summon cadaver back in action. Or may be not :slight_smile:


Well I’m convinced .

Well, seems to come up nicely…

Is there any practical reason why news and docs should be stored in the same repository with code? It obstructs the work of tools like git bisect and maybe wastes CI time (not sure how it’s configured)

I know that existing Urho docs are in main code repo as well, but is it really the only way it can be?

Why not? And why do you care?

The CI/CD will not be triggered if it only contains changes for the website content. When I make changes in the code, I may want to update the docs at the same time. Only in this case both the CI/CD and the website build event will be dispatched at the same time.

Because I’m working with git and doing git bisects regularly.
Unfortunately, git doesn’t know that these are “just doc” commits.

It’s not a big deal since I can always skip commits I don’t want to test, but it’s just one more point for not doing docs and code in the same repo.

I wonder how good “GitHub wiki” is… I don’t like the lack of control tho.

I don’t care with how good you are with git. But have a look around with other projects. There are many projects with docs and codes at the same repo.

There is nothing that prevents us from creating a build job that builds docs/web/whatever using another repo.

You can do whatever you like in your fork. Please leave us die alone. We don’t care what you do over there, so please stop giving us instructions what we can or cannot do in our own project.

BTW. The whole github actions for the new Urho3D website project is in place now. Any pushes to the website content will trigger the website build on my private repo, which in turn will deploy the built result back to There are still teething problem but nothing major. I will fix that when I am in the mood again.

The builder is in my private repo, so no copycat can steal my work.

Just to be clear, our MDX files will contain custom React components that only my/our builder can understand. The custom components will make the website unique. Unfortunately, it will also mean that our MDX files will only be useful specifically for Urho3D project.

If I understand correctly, then users will not be able to generate documentation locally on their computer? I’m not sure how much this is in the spirit of open source.

1 Like

Calm down dude and don’t act like 10 years old kiddo, as I can read he was just suggesting and wasn’t any kind of personal attack.

I mean, what does this mean:

You can do whatever you like in your fork. Please leave us die alone. We don’t care what you do over there

Users will still be able to generate the API doc using Doxygen locally. However, they can’t generate the “website” locally, that looks like the final one on That’s the drawback with my decision to make the builder a private repo, which I am willing to take. However, the online website will be PWA when I am done with my work, so it can be “installed” locally and read offline. So, I hope that addresses your concern.

Getting the website code (builder) closed source is to protect us from having multiple website clones later on. The code is also my own copyright. It is totally up to me whether to license it for others or not. If you hire a dedicated website designer to develop the website, you will probably get the same deal. You got the result deployed somewhere but not the code.

1 Like