Forem: Shannon Reca

A WordPress Theme with Next.js

Shannon Reca — Sat, 03 Oct 2020 19:26:32 +0000

Why WordPress with Next.js?

At first glance this may seem a little off from a development side of things. WordPress is it's own platform as Next.js is it's own framework, why even combine to two? There a few reasons why I decided to proceed with this project and for specific use cases.

Use Case Specific to React Developers

Redesigning a current WordPress site.
Customer/Client wants a WordPress site.
You wish to create a web app and choose WordPress as your admin UI.
Already built admin functionality such as: users, plugins, etc; within WordPress.

The Pros of WPNext Builder & Next.js

With the focus of React.js as your primary choice of development, WPNext Builder alongside Next.js, essentially allows you to quickly create and deploy React components to your site. Whether is a request from a client or a need you are trying to fulfill.

This kit relies on the WordPress API to access the content information. However, since this setup includes Next.js, the call gets made on the server-side allowing the page to render no differently than a typical WordPress site. It's a JS application layered on top of WordPress. You can use WordPress to create pages and post, while building a completely standalone web app and create WordPress admin pages to manage the web app features. The possibilities are really up to you.

The beauty of it is, it's all within the theme folder and it's easy to setup. If you ever decide to move away from it, you can quickly revert back to another basic WordPress theme. Just follow the WPNext documentation at my GitHub to properly install and begin use. I've provided some basic components along with some "out-the-box" .jsx modules to handle navigation and site header.

This Project Will Continue to be Maintained

As I continue to use this theme kit, I'm constantly updating and improving it in hopes of streamlining the development process for future projects. I'm also looking to provide pre-built components that can easily be dropped in to existing sites using the WPNext Theme. Finally, I'm planning on releasing a step-by-step video tutorial from start to finish to help out junior developers.

With all this being said, if you happen to use this or any of my open source projects and would like to support my work, please visit my GitHub Sponsor page. Any support is greatly appreciated and helps me reach my goal of just working on projects I enjoy.

Originally posted on ShannonReca.com

Revolutionizing the CMS

Shannon Reca — Tue, 25 Jun 2019 20:29:59 +0000

When you look at the CMS today, most if not all, follow the traditional concept of theme and plugin development. There is no such thing as the perfect CMS, hence the reason for plugins to exist, providing a level of customizing ability to fulfill ones needs.

So then what differentiates one CMS from another? Well, there are certain features that are usually highlighted, along with the type of CMS, such as database driven, flat file, static, and so on. However, I find myself coming back to the same question. Conceptionally, what is the difference?

I concluded, there is no difference. Sure, functionality may be different. The process in which data/content is stored and delivered may be different. Whichever the case may be, it all falls back to theme and plugins.

As a developer, I think of time spent “recreating the wheel.” It's easy when you yourself have a library of code that you can continuously copy with minor tweaks to complete a project. However, you will always cross a point where you simply don't have it and start searching online for free open source libraries in which you retro fit into your project. This is essentially every developer.

This had me thinking since the days of me creating SumCMS and BKDR, what would make a great CMS from a development and user perspective? Today I believe I have, not THE answer, but an answer that can solve a wish list of common ground interest from most web developers.

The Wish List

It does not use “themes” as what is known today.
It does not use “plugins”.
It should be modular and interchangeable with other sites.
It should allow you to essentially create the features needed rather than waiting for the feature to be implemented.

Interested in what it is? Well... I'm about 60% completed with my MVP for public release, but I've been really excited to share what I have thus far. So instead of releasing a half baked project, I decided to create a subscription list so you can signup and get update-to-date info on features before the actual release.

Introducing JayDMS, a JSON based Development Management System. I look forward to creating a community behind this project, because I truly believe this is a fresh new look on web development. Thanks for your interest and taking the time to read this, and hopefully signup.

Why Use A Self-Hosted Code Editor

Shannon Reca — Thu, 21 Dec 2017 17:21:45 +0000

Original Post

Full disclosure, this is a post specific to my code editor that I have launched, called BKDR. It's completely free and available for download. If you know of another, by all means use what you're comfortable with.

So why use a self-hosted code editor. First, for those who may not have used one, or heard of services such as CodeAnywhere, Cloud9, Koding, etc., what is it exactly ?

Basically, it's your code editor within a browser. What is interesting is that popular code editors such as VS Code or Atom are built with web technologies such as JavaScript and packaged as a native app. So the experience is not far off from what you're use to on your local environment. The difference is you're now opening your browser to code.

Self-Hosted vs Cloud Services

Cloud services have revolutionized the online development industry, allowing developers and companies to speed up the development process, and taking most of the burden off their shoulders.

However, cloud services aren't for everyone. Although they provide a great deal of value for developers, and are backed by funding or other corporate entities, there are a few use cases where you may prefer you own self-hosted code editor.

Privacy

Look, lets be clear. For these cloud services to work with your other servers or client's servers, you need to store these credentials somewhere. Cloud services are usually big targets for data breaches. The more sensitive information you put on those servers, the more you're trusting your data is safe there.

I'm not declaring my code editor to be the most top flight secured ever. What I am saying is decentralizing all your projects to their own server, whether a client or your own project, prevents further damage if there is a breach on one particular site. Having a light weight code editor on each site that's installed with a simple FTP upload and a config file is quick and easy.

Freelancers & Small Agencies

If you're a freelancer or a small agency just getting off the ground, you probably have several WordPress clients. How many times have you needed to do a few simple PHP edits to a plugin or theme? How many times have you been contacted while on the road for an urgent update? Having a code editor on that site may save you a lot of time and energy. It's similar to having access to the WP admin. You sign-in, make your changes, save, and you're done.

Extensions

BKDR is built with the ability to add extensions. Although the API docs are still in the works, I’m predicting this will be a huge game changer on your development process.

Lets say you have a particular project that has a specific update workflow, or maybe you need a tailored made validation process. You can possibly make a custom extension just for that project. More so, you can share that extension with other developers for their own self-hosted sites. BKDR's extension API, when completed, will allow access to several built-in functionality that can further your development. Do any of the cloud services allow you to add on your own custom extension for their editor? Please share if they do.

Whatever Works Best

In the end, I'm not saying ditch your cloud service account. I'm simply advocating the use of a self-hosted code editor for developers who thinks it makes sense for their situation, and if so, you may want to try BKDR. It's very new, and I'm looking to continually releasing updates with new features. I welcome and greatly appreciate any feedback.

UPDATE - 1/16/18

I've decided to open source BKDR with hopes that it'll continue to grow into something bigger than what I had envisioned. Hopefully it's enough of a foundation to take it to the next level. You can download BKDR's latest release, or check out the development repo. I'll be updating the repo with more information soon. Enjoy!

BKDR v2 - My Journey Into ReactJS

Shannon Reca — Wed, 13 Dec 2017 03:42:16 +0000

When I originally created my in-browser code editor, I wrote it all in CoffeeScript. Worse, I wrote it in one big file. What started as a simple cool idea, kept getting bigger with every feature or new idea. Eventually, I knew I could not continue working this way. Request for new features were becoming more difficult to organize, and scaling became an issue.

This was all due to not having a plan. It was a fun, cool idea that became something more, and when I realized it, it was too late in the process. So regardless of not wanting to, I knew I needed to start over.

What's Next?

Around the time when I was contemplating on how and what to use to rebuild my code editor, React and Angular where trending. Angular 2 was in beta, and was different enough from Angular 1, that it made me hesitant on any attempt to learn it. Additionally, React was a lighter framework from my brief understanding. So I decided on React.

One thing I didn't want to do was learn React WHILE remaking my web app. It just seemed like an unwise decision that would eventually come back to haunt me. I needed another project to really flex my sandbox adventures. Of course, knowing me, I created a social network (like that was the easier option).

Class In Session

In the end, I was able to take away so many valuable lessons. For example, jQuery sometimes becomes a reflex when you confront a situation. But in React, you need to change your mindset. We're so use to manipulating the DOM with JavaScript and jQuery. However, one of the greatest benefits of React is it's ability to update state changes within components.

Within a component, HTML or other components can be returned within the render method. Every time the state is updated or replaced, it triggers the component to re-render. This is handled through the virtual DOM before being updated in the actual DOM. Redux also adds another great element to React with it's store. Basically it's ability to have a centralized source of data that can be updated via dispatch. This was a huge feature in creating my web app. For simpler projects, this may be overkill. It really all depends on your needs.

The Result

After spending about eight months learning React, I started on version 2 of Backdoor (which I rebranded as BKDR), in March of 2017. Now, 10 months later, I'm about to release my beta within the next couple of days, fully built in React and handling the server side in PHP. I estimate I wrote over 30+ components, all nicely organized and optimal to scale properly.

If you'll like to stay posted on my Backdoor progress, you can visit BKDR.org.