Replace old hilla.dev links from v23

.github/workflows/vale.yml

@@ -5,6 +5,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
+      - uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: 2.7
+      - uses: reitzig/[email protected]
       - uses: errata-ai/vale-action@reviewdog
         with:
           files: articles

README.md

@@ -2,9 +2,9 @@
 
 Official documentation and code examples for Vaadin.
 
-This repository does not generate the [vaadin.com/docs](https://vaadin.com/docs) or [hilla.dev/docs](https://hilla.dev/docs) websites. It only contains the content for them. The builds are done using [Vaadin Design System Publisher](https://vaadin.com/design-system-publisher).
+This repository does not generate the [vaadin.com/docs](https://vaadin.com/docs) website. It only contains the content for it. The builds are done using [Vaadin Design System Publisher](https://vaadin.com/design-system-publisher).
 
-The `latest` branch is for Vaadin documentation and selected by default. Select the `hilla` branch if you wish to contribute to Hilla documentation.
+The `latest` branch is for Vaadin documentation and selected by default.
 
 ## Contents
 

articles/advanced/modifying-the-bootstrap-page.asciidoc

@@ -86,7 +86,7 @@ const {serverSideRoutes} = new Flow({
 });
 
 const routes = [
-  // for client-side, place routes below (more info https://hilla.dev/docs/routing)
+  // for client-side, place routes below
 
   // for server-side, the next magic line sends all unmatched routes:
   ...serverSideRoutes // IMPORTANT: this must be the last entry in the array

articles/configuration/pwa.asciidoc

@@ -12,7 +12,7 @@ They look like a regular application in the home screen of a mobile device or in
 A PWA needs some metadata, such as name, description, and icon, which are used by the operating system to display information about the application.
 
 To enable offline use, TypeScript needs to be used to provide the offline views.
-https://hilla.dev[Hilla] is the recommended framework to build client-side views.
+Hilla is the recommended framework to build client-side views.
 
 For a generic introduction to PWA, see the article on https://vaadin.com/pwa[What are Progressive Web Applications and Why Build a PWA].
 

articles/security/enabling-security.adoc

@@ -293,7 +293,7 @@ The most important configuration in the above example is the call to [methodname
 This is how the view-based access control mechanism knows where to redirect users when they try to navigate to a protected view.
 The log-in view should always be accessible by anonymous users, so it should have the [annotationname]`@AnonymousAllowed` annotation.
 
-This is especially important when using the variant of the [methodname]`setLoginView` method where you provide the route path (although this signature is meant to be used with https://hilla.dev[Hilla] views, not with Flow views).
+This is especially important when using the variant of the [methodname]`setLoginView` method where you provide the route path (although this signature is meant to be used with Hilla views, not with Flow views).
 
 
 .Component-based security configuration

articles/upgrading/recommended-changes/index.adoc

@@ -29,7 +29,7 @@ The reason for this API change is that, with client-side bootstrapping, the init
 - In Vaadin 10 to 14, these two steps are combined and the [filename]`index.html` page includes the code and configuration needed to start the Flow client engine and link the browser page to the server-side [classname]`UI` instance.
 
 - In Vaadin 15 and later, with client-side bootstrapping, the [filename]`index.html` page includes only the basic HTML markup and links to the TypeScript UI code.
-If you have https://hilla.dev/docs/routing[client-side/Hilla views], the [classname]`UI` isn't guaranteed to be created, and so it's optional.
+If you have Hilla views, the [classname]`UI` isn't guaranteed to be created, and so it's optional.
 It's available only after the user navigates to a server-side route.
 
 It's also possible to continue using the bootstrapping mode in V10-14 with the `useDeprecatedV14Bootstrapping` flag.

articles/upgrading/upgrade-tool/flow/_14-15.adoc

@@ -43,7 +43,7 @@ The reason for this API change is that with client-side bootstrapping the initia
 
 - In Vaadin 10 to 14 these two steps are combined and the `index.html` page includes the code and configuration needed to start the Flow client engine and link the browser page to the server-side `UI` instance.
 
-- In Vaadin 15+ with client-side bootstrapping the `index.html` page includes only the basic HTML markup and links to the TypeScript UI code. If you have https://hilla.dev/docs/routing[client-side/Hilla views], the `UI` isn't guaranteed to be created, thus is optional. It's only available after the user navigates to a server-side route.
+- In Vaadin 15+ with client-side bootstrapping the `index.html` page includes only the basic HTML markup and links to the TypeScript UI code. If you have Hilla views, the `UI` isn't guaranteed to be created, thus is optional. It's only available after the user navigates to a server-side route.
 
 It's also possible to continue using the bootstrapping mode in V10-14 with the `useDeprecatedV14Bootstrapping` flag.
 See how the use the flag in <<{articles}/configuration/properties#, Configuration Properties>>.