new knoledge unlocked:
I can use :
app.use('/admin', requireAdmin, adminRouter)
instead of :
app.use(requireAdmin)
app.use('/admin', adminRouter)
I know everybody knows this, but this is a knowledge to me
added a very very cool text area for entering description for each field
completely build on bootstrap accordion
check it out !!!
First template design completed !!!
fully using Bootstrap , and some css
Continuing the writting of the first template for the site !!!
basically my project is a invitation page builder, it needs a lot of custom template.
|
▽ not complete yet
In this 6h 44m, I made a lot of features but the main highlight was the work on the template creation form ( continuation of previous devlog)
Basically my project is a wedding invitation page generator. My website will have a lot of prebuild invitation template(HBS) for different different events
So the point is different templates require different forms should be filled by the user.
Therefore when the admin create different template, the admin should list the require fields for the form of the specific template.
My thoughts was to make a prebuild list of fields, from that the admin should list them in specific order.
The first problem was there is no form element to do these. So i used a select element with a ‘Add’ btn.
For the sorting, at first i used up/down button, but that wasn’t smooth. After researching I found sortable js.
At first sortable js also was not smooth, I fixed that by removing some bootstrap classes from the tag.
The next problem I faced was I cant use required in the custom fields list maker, So I can’t make that field mandatory.
The solution was simple,
I made a invisible <textarea required .....>, and add the list of fields to that in json string when the admin edited the list.
Thank you for reading ❤️,
Mrithul.
Spent 4 hours and 52 minutes working on the templates page today.
This page is going to be the main place where all invitation templates are managed, so I wanted to get the basic structure done before moving on to creating more templates.
The first thing I worked on was the layout. I switched the page to a responsive grid system and started building the actual templates page. I also added a Create Template card that is only visible to admins.
Clicking the card opens a modal for creating new templates.
The modal is still incomplete, but the basic flow is now working.
Currently it has fields for:
There’s still quite a bit of work left to do here, but at least the structure is finally in place.
One thing I didn’t want to do was create a completely separate form for every invitation type.
Instead, I’m building a system where templates can be configured using categories and predefined fields.
const templateCategories = [
{ id: "wedding", name: "Wedding" },
{ id: "engagement", name: "Engagement" },
{ id: "birthday", name: "Birthday" }
....
]
const templateFields = [
{
id: "eventTitle",
label: "Event Title",
type: "text",
category: "common"
},
{
id: "groomName",
label: "Groom Name",
type: "text",
category: "wedding"
}
....
]
Right now I’ve added categories for weddings, birthdays, engagements, housewarmings, baby showers and several other event types. The field system should make adding future templates a lot easier.
I also spent some time cleaning up the page and added a footer. The site is slowly starting to look more like an actual product instead of a collection of pages.
The next step is finishing the template creation page and making the field selection system fully functional.
Once that’s done, adding new templates should be much faster than it is right now.
Today I connected my website to firestore for database
I have implemented the saving of login information of user to user collection of firestore database
This is the implementation code:
service\userService.js :
async function saveUserLogin(userRecord) {
return db
.collection("users")
.doc(userRecord.uid)
.set(
{
displayName: userRecord.displayName || null,
email: userRecord.email,
photoURL: userRecord.photoURL || null,
lastLoginAt: new Date(userRecord.metadata.lastSignInTime)
},
{merge: true}
)
}
service\userService.js :
router.post("/sessionLogin", async (req,res) => {
const idToken = req.body.idToken;
const expiresIn = 60 * 60 * 24 * 13 * 1000;
try {
const sessionCookie = await admin.auth().createSessionCookie(idToken, { expiresIn: expiresIn });
const options = {maxAge: expiresIn, httpOnly: true, secure: false};
const decodedClaims = await admin.auth().verifySessionCookie(sessionCookie, true);
const userRecord = await admin.auth().getUser(decodedClaims.uid);
await saveUserLogin(userRecord)
res.cookie('session', sessionCookie, options)
res.status(200).send({status: "success"})
} catch (err) {
console.error(err)
res.status(401).send('Unauthorized request!');
}
})
I also created the redirect from login page if login successful / refresh in login fail (these things where previously missing)
Also there are many UI improvements made, that’s not written in this Devlog
(●’◡’●)
Time spent: 8 hours 15 minutes across ~6 days
This week I mostly worked on security-related improvements and continued work on the invitation template system.
When I opened GitHub, I got a security notification. After checking it, I found that a Firebase client-side API key was present in the repository.
I know Firebase client API keys are not secret credentials by themselves, but leaving them exposed can still make abuse easier, especially if other protections are missing. Since the project is still in development, I decided to clean it up now rather than later.
What I did:
res.locals.firebaseClientCred =
Buffer.from(process.env.firebaseClientCred, "base64")
.toString("utf-8");
The long-term plan is to separate development and production configurations.
Right now localhost access is required for development, so strict domain restrictions are not practical yet. Once the project is deployed, I plan to have:
The developer configuration will stay out of production deployments. Even if development code is accidentally pushed, it should fail instead of exposing access that was never intended for production.
The backend Firebase SDK setup was already safe, so most of this work was focused on the client-side configuration.
I also implemented automatic navbar link highlighting.
Instead of manually setting the active page for every route, the navbar now checks the current URL and highlights the correct link automatically.
function highlightCurrentPageLink() {
const currentPageUrl = window.location.pathname;
const links = document.querySelectorAll("#navbar-ul li a");
links.forEach((link) => {
const href = link.getAttribute("href");
if (href.split("/")[1] === currentPageUrl.split("/")[1]) {
link.classList.add("active");
} else {
link.classList.remove("active");
}
});
}
Small change, but it makes maintaining the navigation much easier.
Worked on the user menu and logout functionality.
Nothing huge here, but it is another piece of the authentication flow that is now coming together.
I created the HBS file structure for the template page and spent a lot of time thinking about how templates should actually be implemented.
This is currently the biggest blocker. There are several ways to handle template rendering and customization, and I don’t want to lock myself into a design that becomes difficult to maintain later.
A lot of the development time this week went into planning, experimenting, and changing approaches rather than writing large amounts of code.
There is still a lot to do, but the project is becoming more stable and secure before moving further into feature development.
Devlog-2:
Today , I added a beautiful animation to the home page
made the home page overall beautiful
Also fixed a authentication error :
What’s next :
Note: the PHONE image have a cool animation effect.
completely done by hands , no AI
only used AI for clearing doubt
within 8h 33m , I made the home page, firebase auth, designed logo etc..
currently I am working on designing the ‘Login with google’ page