allenjd3 a place to set on

WP Mail SMTP Goodness

I recently migrated a wordpress site that I manage to trellis. Trellis is a deployment tool which makes deploying wordpress sites a breeze. Its fairly opinionated about how everything works however so I wasn’t sure how it would go. Here are my initial thoughts-

Wow it was easy to set up!

Rebuilding the site which used to take an entire afternoon took me about 30 minutes with trellis. Basically all I had was a fresh ubuntu instance on Digital Ocean, my sql dump file from my previous page and the contents of the wp contents folder. Trellis set up everything really quickly and its more secure than I could ever make it.

Hmm- something is weird here…

I immediately started noticing odd issues with wordfence. I uninstalled the plugin and reinstalled- all started working again. Then I started to get fatal errors blamed on yoast seo. I disabled the plugin and everything was working again.

Yoast didn’t like wp smtp

In my efforts to figure out why yoast wasn’t working correctly I discovered that if I disabled WP SMTP then yoast would stop killing my post editing. Then I noticed something odd. Apparently when I migrated the site, WP SMTP didn’t have all of its database tables that it needed. My simple solution: uninstall and reinstall. I was hoping for a quick solution like with wordfence but in this case, reinstalling did nothing.

Long story short, I found a setting that allowed me to delete all data from WP SMTP from the database. It was in the miscellaneous tab of the WP SMTP settings.

Screen Shot 2022-03-30 at 9 44 01 AM

After I checked that box- I just uninstalled and reinstalled the plugin. The only downside was having to find my mailgun key again but that wasn’t a huge deal. WP SMTP installed all its necessary tables and we are back in business

Overall, I love trellis. It is ten times quicker to make changes to the site and if something were to happen to my current site it wouldn’t take long to completely rebuild it elsewhere. I give it two thumbs and two big toes up.

Thinking in React... in Livewire

So I’ve talked a little about Hotwire in the past but for Laravel there is a much more ubiquitous “wire” around- Livewire. Hotwire is very much a “build the way you always build and then sprinkle in the magic” tool. Livewire is more of a thought switch so I struggled with it at first. I think I’ve found the correct balance for it though and it comes from an article I read in the React Docs of all places: Thinking in React

Livewire is a bit of a mental switch. Its more react-like in the way it handles data. The craziest thing to me is that you don’t need controllers anymore. All the business logic can be organized into components. You can even route to individual components.

Route::get('/post', ShowPosts::class);

The key to thinking livewire is to break your component into smaller components like in the ‘thinking in react’ article linked above. This helps to answer the questions-

  1. What do I test?
  2. Where do I query the data?
  3. Do I pass it as props or do I handle it in the component itself?
  4. Where do I change or act on the data?

Without answering these questions, you can get some really odd spaghetti code. You can be querying and modifying data in a sub component that shouldn’t have that ability. It makes it harder to tell which components are mutating state and which are getting their own state. Start thinking in react in livewire. Seriously- helps a lot.

Old is New Again

You may have heard about the latest and greatest new piece of front-end tech : Hotwire. Hotwire literally stands for HTML over the wire. If you don’t have a clue about what I’m talking about, check out this site and then make your way back here. hotwire.dev

So now that you understand the basics I want to provide you with a couple of the small things that weren’t obvious to me from the docks and they all relate to turbo-streams.

  1. Hotwire is not restricted to rails but rails has a couple of neat adaptors for it. You can install hotwire-rails, turbo-rails and or stimulus-rails. Hotwire-rails is just turbo-rails and stimulus rails bundled together.

  2. You need the redis adaptor installed in order to install turbo-rails. This is used if you use turbo-streams and connect it to a websocket. If you need the redis gem enabled that means one other thing- you need redis installed as well. I had a lot of luck using just plain docker for this. If you aren’t super familiar with using redis in rails (which I wasn’t) the config file that has your redis connection information is in cable.yml

  3. Turbo Streams need some Model magic Make sure you put the following for an example model called Post if you want to broadcast your changes.
    class Post < ApplicationRecord
     after_create_commit { broadcast_append_to "posts"}
     after_update_commit { broadcast_replace_to "posts"}
     after_destroy_commit { broadcast_remove_to "posts"}
    end
    
  4. You need to wrap your data that will be appended. Its important to wrap it in something like this-
    <%= turbo_stream_from "posts" %>
      <%= turbo_frame_tag "posts" %>
     #important stuff in here
      <% end %>
    <% end %>
    

    Then within that frame tag each individual posts need to be wrapped in another frame tag with the dom_id helper function like below-

    <%= turbo_frame_tag dom_id(post) %>
      #individual post
    <% end %>
    

    Doing all of the above will allow you to add stuff to your list, remove things and updated things.

  5. Streams need even more help if you want to broadcast errors. The above will have you creating updating and destroying as long as you don’t have any validation. Of course, you will always need some sort of validation so that really isn’t feasible. In order to get your errors sent back and your turbo frame updated, you need something like the following in your controller-
     respond_to do |format|
       if @post.save
         format.html { redirect_to posts_path, notice: 'Post was successfully created.' }
         format.json { render :show, status: :created, location: @post }
       else
         format.turbo_stream {render turbo_stream: turbo_stream.replace(@post, partial: "posts/form", locals: {post: @post})}
         format.html { render :new }
         format.json { render json: @post.errors, status: :unprocessable_entity }
       end
     end
    

    The important bit here is the new format- turbo_stream. This allows you to pass back something from your controller that will replace your original frame.

Anyway, I hope that is all helpful information. Hotwire seems like its really going to help speed up development!