chrismcintosh

Database Timing Out or Not Persisting Changes on Laravel Chained Jobs

October 3, 2022 by chrismcintosh Leave a Comment

I ran into an issue with a Laravel application I was working on. The issue was related to a long running job. The job generally takes between 10 to 15 minutes to complete.

Before the job kicked off we would change a value in the database to indicate the job was in progress – we’ll call this state as “active”. At the end of the job we would change the value in the database back – we’ll call this state “inactive”. Changing the record back would allow the record to be picked up by other jobs in the future.

At the end of the job (job still in progress) I could see the value as being set to “inactive” (as desired). However once the job was fully over – a peek into the database would show the record as “active” still. So during the job we would get a false positive of our database record being changed. After the job the record would “snap back” to an undesired state of “active”.

I tried multiple things to rectify this issue and get our database changes to stick after the job completed. One thing that worked – but felt “icky” – was chaining a job onto the main job to do database cleanup. Discovering that this chained job worked led me to discover that the DB::transaction was “locking” the record and preventing permanent changes. Once the DB::commit() line fired our “temporary” changes would go away.

In this instance it made more sense to not use a DB transaction method instead of chaining the job on. Especially since this job runs for so long. Hopefully this can help you identify similar issues in your long running jobs. The best course of action for your application might be different than my solution.

Good luck!

Using The Events Calendar Plugin with Timber and Twig

March 21, 2022 by chrismcintosh 2 Comments

Ensure the Timber Plugin or Composer dependency is installed
Install the Events Calendar Plugin
This works for the free version. If using the paid version of the plugin – you might have to modify the other steps.
Activate the Events Calendar Plugin
Create the template file for the override
Create a file at the following location inside the Timber theme tribe/events/v2/default-template.php
Add the code to the template file
See code snippet 1 below
Render the markup in twig
See code snippet 2

Code Snippet 1

<?php
/**
 * Default Events Template
 *
 * @package TribeEventsCalendar
 * @version 4.6.23
 *
 */

use Tribe\Events\Views\V2\Template_Bootstrap;

if ( ! defined( 'ABSPATH' ) ) {
	die( '-1' );
}

$context = Timber::get_context();
$context['tribe_markup'] = tribe( Template_Bootstrap::class )->get_view_html();
Timber::render( array( 'events.twig' ), $context );

Code Snippet 2

  <div class="events-container">
    {{tribe_markup}}
  </div>

More related information can be found here https://github.com/timber/timber/issues/312#issue-39623334

How To Conditionally Display an Algolia Filter using Vue InstantSearch

March 21, 2022 by chrismcintosh Leave a Comment

I needed to conditionally display a filter in Algolia. I was using vue.js to put the UI together for the site. Conditional display of the filter should be an easy thing but apparently Algolia recently removed easy access to the UI state object.

You can find other reported instances of this issue here

The basic idea here is that you should only be able to select a category if we have set post type equal to “post”. Otherwise the category filter should hide away because it is not relevant.

After many attempts to gain access to the UI state in props I finally ended up with success using the following workaround.

<ais-current-refinements :included-attributes="['post_type']">
    <template v-slot="{ items, createURL }">
    <div v-for="item in items" :key="item.attribute">
        <div
            v-for="refinement in item.refinements"
            :key="[
            refinement.attribute,
            refinement.type,
            refinement.value,
            refinement.operator
            ].join(':')"
        >
            <template v-if="refinement.label == 'post'">
                <div class="choose-block">
                    <label for="category">Category:</label>
                    <ais-menu-select attribute="display_category"></ais-menu-select>
                </div>
            </template>
        </div>
    </div>
</template>
</ais-current-refinements>

You have to wrap your filter that should be conditional in a <ais-current-refinements> tag and do your v-if inside.

There might be an easier way to accomplish this, but I couldn’t find it in the Algolia docs. Please give me a shout if you know a better way.

Use Webpack Without Writing a Webpack Config

March 5, 2022 by chrismcintosh Leave a Comment

I doubt you got into web development because of your desire to write Webpack configs. You shouldn’t have to waste hours to create your bundles. Webpack can sometimes feel like this unagreeable middleman if you haven’t spent significant time with the documentation and hands on experience. Even if you do have considerable experience Webpack can still be disagreeable.

Webpack should be a tool that just gets out of your way. The goal is to get to the actual code you want to write quicker. For these projects there is Laravel Mix.

Although the package has Laravel in the name, you can easily use it in non Laravel contexts. The package does ship by default with Laravel Projects. Thankfully the tool isn’t bound to the ecosystem

Mix does the basic stuff you would expect. You can easily transpile (compile?) your JavaScript and CSS assets. Mix can handle your Typescript, Sass, or PostCSS. If you need to run Vue.js or React.js in your bundle – Mix also handles that without issue.

Mix might not be the best fit for your project if you have very specific Webpack needs. Mix can also start to slow down if your project gets really big.

Ultimately, Laravel Mix is an incredible tool. I believe you should use Mix until you run into a situation where you need to write your own Webpack configuration. Save some time and get back to writing the fun stuff quicker by using this package.

How To Merge Unrelated Git Histories With Conflicts

November 1, 2021 by chrismcintosh Leave a Comment

I recently took over a project that was hosted on WP Engine. When I took over the project I didn’t have a git repository for it. I could have pulled from WP Engine initially – but I didn’t. I downloaded from a WP Engine backup instead and committed this to my new git repository. This was the start of my problem.

The code base was largely the same but git sees them as two separate repositories now. I continue on not knowing I’ll have a problem and work on the features and enhancements I’ve been tasked with building. I set up a staging environment and push to that with no issue. All the work gets approved on staging and its time to push to production. Now I’m aware of the problem.

The problem looks something like this

Now the problem is I can’t just do a force push. I’ve got to handle the merge somewhat elegantly.

Allow me to show you the command that ended up allow me to solve this issue and explain how it works.

I need to warn you that this is a risky maneuver so if you attempt this, please make sure you understand the consequences.

How To Do It

How to merge unrelated histories with merge conflicts in Git

Start from the right branch
Make sure the current branch is the branch where you want to merge the feature branch to (master/main)
Run the command
git merge feature/landing-page –allow-unrelated-histories -s recursive -X theirs
Handle remaining conflicts
There still might be outstanding conflicts that you will need to manually resolve

What does the command do?

git merge feature/landing-page --allow-unrelated-histories -s recursive -X theirs

Command	Meaning
git	We tell the command line we want to use git
merge	Tells git we want to merge a different branch into the branch we are currently on
feature/landing-page	The branch we are merging in to our current branch
–allow-unrelated-histories	Stops git from cancelling the merge due to unrelated histories
-s	Adds a signoff message to the commit – helpful since this a dangerous command to run
recursive	The default merge strategy when pulling or merging one branch but it doesn’t hurt to include it
-X theirs	The bit that says if there is a merge conflict we want to favor the branch we are merging in over the branch we are currently on

Results

The above allowed me to

Merge the unrelated histories into one
Accept the incoming changes as the desired changes by default when there are merge conflicts (this saved from me having to correct thousands of files of code in a merge conflict resolution)

There were still some files where I had to manually review the merge conflict and make a decision but it was a total of 11 files as opposed to more than 1000 files with merge conflicts.