From UA to GA4 with nuxt

Recently we have begun our work to convert our site from Universal Analytics to Google Analytics 4. This project consisted mainly of adding new variables that fit the datamodel that GA4 has and making the Events.

We use GTM so most of the variables are populated from our GTM package in Nuxt. All I had to do was to make javascript variables in GTM that converts the UA values to the GA4 values. One of these is the array of products during checkout which has a completely different structure compared to how it is in the old system.

Reworking my website - Let's deploy.

Deploying the front is done using Netlify. Any code uploaded to GitHub gets automatically deployed and viewable on the Netlify domain.

The process of deploying the admin panel is more manual. Old school uploading files with filezilla.

For the front I want to use my existing domain. To do this I have to map it to Netlify which is easy enough. My site is now live!

Reworking my website - Blog 2.0

So time for the blog to be migrated!

Given how few blogposts I have and how few categories I have, I think I'm going to rework it a little. The plan is to load all blog posts and sort them into different arrays and using filtering I'll show different blogposts using CSS. I think this will work fine for what I need.

For up is pulling the data and just displaying all of them. To do this I just copy the portfolio code and base it on that. Pulling the entries looks something like this:

Now I just need to display them. To be able to filter them I am pulling in the category and adding it as a class on the blogpost. This means that I can make CSS that hides posts that the user does not want to show. Hopefully this works correctly in static mode on Netlify.

The DOM will look like this:

Next is to add the category filtering which will work similarly to how the rest is pulled. Each of the categories has a line which then can be toggled. Toggling a category changes the query of the page and based on the query CSS is generated to hide/show blog posts.

I think the blog will have to be done for now. Running out of time for today.

Reworking my website - Nuxt front

The new website will use a nuxt front that pulls all the data from the new API. I am going to be using Typescript and use a static deployed website using Netlify.

The first step is to create new website and I am using my Nuxt Typescript base, but notably I am removing the translation system (i18n) since I'm not planning on having multiple languages in this version.

Connecting the new website to the API is easy. Im using Axios to make calls to the API and I am doing everything locally which helps with speed.

The first part of the website I'm gonna implement is the actual portfolio entries. I am developing a content system where every content block has the same styling and uses the same component with a <slot>.

As part of this, I am also making a different version that has a title which everything else can use as a base (which is using "ContentBlock" as a component).

The portfolio entries are pretty straightforward. Just add components for the two different types (Big and Small) and add lists that also pull the data. The pulling of data will only happen during the build process in netlify. Since the content wont update automatically, maybe I should implement a rebuild feature into the admin panel when saving data (or a manual button).

To pull the data I do:

which pulls all live portfolios and then splits them into two different arrays.

After the portfolio, it's onto the "contact" portion. Same procedure as with the portfolio.

Now I'm only left with some of the styling stuff and then the blog. The blog will have to happen on a different day.

Reworking my website - API

The plan for the API is to have it on the PHP admin panel side (mainly because that's the easiest and most straight forward for me). The implementation for the API is based on my API for which is heavily influenced by the IGDB api.

To make the API modular so I can use it in other projects, I've decided to add a subdirectory for it ("/api") and implement my prebuilt classes for database connection and API.

The first dilemma that I've thought about is whether I need to require authentication to pull data or not. What is the chance/risk that someone will try and pull a bunch of data with my API endpoints? I reckon it's pretty low. For now, I will not implement an authentication system, but ill have to reevaluate at a later date.

To be able to keep track of the status of an API call I have added my context class with a new "status" class. The context class helps me save and reuse information and the status class will hold the HTTP code and potential error messages.

The current plan for what endpoints I need is:

For each endpoint, I will have a way to sort, filter, and limit the result right away. This will be done similarly to how the IGDB works.

Let's start with the portfolio...

Is it possible to make a general structure to the API so that you just input a "table" and an action and it knows where to grab it? Is that the best way of doing it? The API endpoint "dimension" (the first part of the URL) would need to be the same as the table so that I can just reuse it. Preferably I would like to be able to reuse the API without doing any changes. I'm thinking that I can either make one definition for dimensions and one for actions OR I can make just one definition that has a key-value pair between dimensions and actions. I think that the best solution is a key-value pair since I also need to specify accepted columns (since this could be a security issue).

For now, the structure looks like this, which seems to work: