I'm currently experiencing an issue with on-demand entries where when it requests a page to be compiled on the fly, it returns a 404 from the dev-server.
Below is the typical pages directory structure. When inspecting dev_tools console, there is a fetch call to the dev server to compile the page, in this case article.tsx (/article/article-slug), the fetch request returns a 404.
.
+-- pages
| +-- latest-news
| +-- index.tsx
| +-- article
| +-- [slug].tsx
Environment Details:
OS: Ubuntu 18.04.4 LTS
Node: v15.8.0
NPM: 6.14.11
NextJS: 10.0.5
You need a pages/article/[article-slug].tsx page if you want NextJS to recognize the slug.
Follow the NextJS tutorial for more details
Related
I have a static website built with Next.js and currently deployed in GitHub Pages. I already have a custom 404 page created in Next.js with a config trailingSlash: true which puts it under this directory /404/index.html. In GitHub Pages' documentation here and saw that I can use 404.md which can read permalink, I assume this means the path to my custom 404 page. So I created one in the root folder of my deployment branch.
---
permalink: /404/index.html
---
But it didn't seem to work. I was wondering if there's something I've assumed or done wrong. Do also note that my GitHub Pages is already under a custom domain. Please suggest if there's another way but still keep the trailingSlash: true config because I don't want to show .html on the route of my other static pages. Thank you in advanced.
In the end, instead of using 404.md, I just added a step in my ci/cd GitHub Actions workflow to move the generated 404 page and rename it to 404.html which GitHub Pages will understand as my custom 404 page.
jobs:
build:
...
steps:
...
- name: Generate static files
run: yarn export
- name: Move 404 page to root directory
run: mv ./out/404/index.html ./out/404.html
As my project grows I'm wanting to setup an elegant and scalable folder structure but I'm unsure what the best practices are.
My project includes a
Flutter app
Firebase Functions
Firebase Hosting with a static landing page and will soon have 2 Angular apps
My current structure is this:
Root flutter app
|
+-- README.md
+-- package.json (with flutter build commands)
+-- Flutter code (lib, test assets etc)
|
+-- Firebase
| |
| +-- package.json (with firebase build commands)
| +-- Functions
| | |
| | +-- src (functions code)
| | |
| +-- Firestore
| | |
| | +-- firestore.rules
| | +-- firestore.indexes
Should my root directory look like this:
- Flutter
- Firebase (Functions, hosting, firestore)
Or something more like this:
- Flutter
- Functions
- Hosting (App1, App2, Static landing etc)
- Firestore
But then where is best to keep build files and deploy scripts for each site/service/app?
I haven't implemented CI/CD yet, but I plan to implement it soon, so I'd probably want to take that into consideration.
Thanks for any advice!
This is actually two questions combined into one.
My AIRFLOW_HOME is structured like
airflow
+-- dags
+-- plugins
+-- __init__.py
+-- hooks
+-- __init__.py
+-- my_hook.py
+-- another_hook.py
+-- operators
+-- __init__.py
+-- my_operator.py
+-- another_operator.py
+-- sensors
+-- utils
I've been following astronomer.io's examples here https://github.com/airflow-plugins. My custom operators use my custom hooks, and all the imports are relative to the top level folder plugins.
# my_operator.py
from plugins.hooks.my_hook import MyHook
However, when I tried moving my entire repository into the plugins folder, I get an import error after running airflow list_dags saying that plugins cannot be found.
I read up a little about it and apparently Airflow loads the plugins into its core module so they can be imported like
# my_operator.py
from airflow.hooks.my_hook import MyHook
So I changed all the imports to read directly from airflow.plugin_type instead. I get another import error though, this time saying that my_hook cannot be found. I restart my workers, scheduler and webserver every time but that doesn't seem to be the issue. I've looked at solutions proposed in similar questions and they don't work either.
The official documentation also shows this way https://airflow.apache.org/plugins.html of extending the AirflowPlugin class, but I'm not sure where this "interface" should reside. I would also prefer a drag and drop option.
Finally, it clearly doesn't make sense for my code repo to be the plugins folder itself, but if I separate them testing becomes inconvenient. Do I have to modify my Airflow configurations to point to my repo every time I run unit tests on my hooks/ops? What are the best practices for testing custom plugins?
I figured this out by doing some trial and error. This is the final structure of my AIRFLOW_HOME folder
airflow
+-- dags
+-- plugins
+-- __init__.py
+-- plugin_name.py
+-- hooks
+-- __init__.py
+-- my_hook.py
+-- another_hook.py
+-- operators
+-- __init__.py
+-- my_operator.py
+-- another_operator.py
+-- sensors
+-- utils
In plugin_name.py, I extend the AirflowPlugin class
# plugin_name.py
from airflow.plugins_manager import AirflowPlugin
from hooks.my_hook import *
from operators.my_operator import *
from utils.my_utils import *
# etc
class PluginName(AirflowPlugin):
name = 'plugin_name'
hooks = [MyHook]
operators = [MyOperator]
macros = [my_util_func]
In my custom operators which use my custom hooks, I import them like
# my_operator.py
from hooks.my_hook import MyHook
Then in my DAG files, I can do
# sample_dag.py
from airflow.operators.plugin_name import MyOperator
It is necessary to restart the webserver and scheduler. Took me a while to figure out.
This also facilitates testing since the imports within the custom classes are relative to the sub modules within the folder plugins. I wonder if I can omit the __init__.py file inside plugins, but since everything is working I didn't try doing that.
Recently, I added a sub-directory and few script files with an empty init.py in the new sub-directory. There is no init.py in foo_main_dir.
foo_main_dir
|
|---- main.py
----- foo_sub_dir
|
---- foo.py
Sometimes pyinstaller stoped working completely after I made some changes in foo.sub.dir with an import error at run-time of the executable file:
ImportError: No module named foo
Due to main.py import:
from foo_main_sub.foo import FOO
None of .pyc was generated in both directories.
A workaround is to reinstall pyinstller. It is quite annoying.
Appreciate if you know a permanent solution.
I've my site structure as below
root
|
|-- ProjectDir
|
|-- fonts
| |-- my-webfont.woff
|
|-- css
| |-- vendor
| |-- my-style.css
|
|-- rent.html
In "my-style.css" file, font is linked using a site-root-relative url
url('/fonts/my-webfont.woff')
I use a local webserver to view
http://localhost/ProjectDir/rent.html
But my fonts are not loading and when I try to load
http://localhost/fonts/my-webfont.woff
it shows a 404 Error (File Not Found).
You can see the my git repo here: https://github.com/abhisekp/House-Rent-Calculator and see the fonts/ directory.
And loading the font file using the web server shows 404 Error. See here: https://abhisekp.github.io/fonts/fontawesome-webfont.eot
What's wrong with all this? My local server also behaves this way.
Try using this:
url('../../fonts/my-webfont.woff');
Thanks everyone. I found the bug.
Actually, the problem was the root itself. When viewing using https://abhisekp.github.io/House-Rent-Calculator address, the root is "abhisekp.github.io/" not "abhisekp.github.io/House-Rent-Calculator/" hence the #font-face urls refer to the former rather than the later.
The fonts lies under "House-Rent-Calculator/" directory. I fixed it by using a relative link (safe for everything if "fonts/" & "css/" directories are not changed frequently).
No more root-relative links as I test using various servers and my "House-Rent-Calculator/" directory might be anywhere in the server.
Better be safe than sorry! ;-)