How to 'pjax' with bricks?

Hi @ribarich @luistinygod @thomas,

it it possible to get bricks working with something like swup.js or barba.js?

The swup documentation explains pretty well where the problem is: Reloading Javascript.

I know that this is not an easy peasy 5 minute thing… but is there any chance to get this up and running?


I haven’t used any of those two page transition libraries myself. But as they have to be implemented on the frontend I don’t see any reason why I can’t work. Is there a specific point where you are stuck at in implementing those libraries with Bricks? Maybe you can share the code you are currently using …

This might actually be a good feature request to submit to the idea board: Ideas – Bricks


Hi Thomas,

thanks for the reply. The request is already on the idea board and complements this request (page loading progress) very well.

The implementation (adding the necessary IDs or data-attributes etc) is straight forward and the first page load works fine, but when moving to another page, it’s hard to call the appropriate bricks js. I’ll take a look at bricks 1.3.4 beta soon and give it another try. If i can get this to work, i’ll share my code of course.

I keep you updated :smiley:

Btw., what do you personally prefer? CSS Transitions like with Swup or “more enhanced” javascript transitions / animations with something like gsap or comparable libraries?

1 Like

Hi Thomas,

i got swup working (with inline styles, external files doesn’t work at the moment - maybe i’ll check that later), but there are a lot of pitfalls on the way which for the most part do not relate specifically to bricks, but to the way Single Page Applications (like Swup or Barba) work, like:

Body Classes won’t update
This can easily be solved with the swup body class plugin.

Head Styles / Scripts won’t load
This can be solved with the swup head plugin.

Admin Bar doesn’t update
This is more complicated, so i decided to run swup only when there is no admin bar :grinning:

Footer JS / Scripts
This is where it get’s even more complicated, because it depends on the Javascript used on the site. Since swup removes the page reloads from site, it also removes a standard lifecycle of scripts, which come with a set of problems that those pjax-like libraries bring.

So first of all, you’ll have to create and call an init function that checks if there is any element that uses js (like .bricks-animated) and if so, call the appropriate function (bricksAnimation()) and call the function again, when the content is being replaced (this can be done with swup events). Depending on the script, it might be good to cleanup all the instances, listeners and mess when leaving a page, which can be done with another swup event that will call a cleanup function before the content is getting replaced (didn’t integrated that into my example).

To keep the example (the init function) simple, this is the code i used (if you want to cover every Javascript function, the init function will of course be a lot bigger…).

I don’t know if there is a more “elegant” way of doing this, but after all, it works and looks like this:

Custom CSS

.transition-fade {
  transition: 0.8s;
  opacity: 1;
  transform: translateY(0);
} .transition-fade {
  opacity: 0;
  transform: translateY(100%);

Body (Footer) Scripts

<script src=""></script>
<script src="https://brickswup.local/wp-content/themes/bricks-child/assets/js/SwupBodyClassPlugin.min.js"></script>
<script src="https://brickswup.local/wp-content/themes/bricks-child/assets/js/SwupHeadPlugin.min.js"></script>

const wpadminbar = document.getElementById('wpadminbar');

if(!wpadminbar) {

const options = {
  containers: ["#bricks-content"],
  plugins: [
    new SwupBodyClassPlugin(),
    new SwupHeadPlugin()
const swup = new Swup(options);

// run once 

// this event runs for every page view after initial load
swup.on('contentReplaced', init);

function init() {
   if (document.querySelector('.bricks-animated')) {


Personally, I prefer CSS over JS libraries as they are more lightweight and have no dependencies (i.e. more lightweight). And are usually sufficient for most page transitions, too.

Thank you so much for all the information, and the video. Much appreciated!

If the objective is only about page transitions simply fading the HTML in and out, could be enough without using any library. In that case pjax’ing seems like an overkill.

I can see in your example that you leave the header visible during the pjax call. Which makes me think that some users might want to apply such conditions to different parts of their site. Therefore adding a whole slew of possible settings to the builder.

Not sure if the AJAX fetched HTML might cause some other problems, too. As there is so much to consider I tend towards the more simple more CSS-based page transitions I described at the beginning of this post. Thoughts?

You’re welcome!

Yeah, like i said… not an easy peasy thing to integrate and to cover all possible cases and like you said, for most people a “simple” solution (with simple transitions and without the technical stuff behind) will work as well.

I mean that divi offers page transitions, but I can’t tell you how they solved it. But a smooth transition, maybe with an optional loading progress counter or bar, would be a nice add on i think.

Okay, let’s first see how much traction the “Page transition” feature request gets (Ideas – Bricks). This one feels more like a “nice to have”, but not an essential feature. The latter are the ones that we want to focus on and execute first.

1 Like

You’re right, let’s see… there are definitely more important building sites than this :slight_smile: