SearchWP was first released in August of 2013. It’s come a long way since then! Not only has SearchWP itself as a product matured and grown, I’ve learned a ton since writing that first version.
Without waxing poetic about things of the past, I’m very excited to be able to share some preliminary information about SearchWP 4.0 and why this release changes a number of things that will require your attention.
This is the first post of many that will outline what’s new/changing in SearchWP (it’s a lot!)
When first building SearchWP, the scope was limited in such a way that would have it work only with WP_Post objects, because it was during a time where the WordPress community at large was (mostly) against custom database tables and heavily in favor of “the WordPress way” being adoption and usage of existing APIs. It also made building the first version much easier.
The WordPress world (myself included) has changed direction on that, and we’re all going to be better for it.
That said: SearchWP 4.0 will NO LONGER be limited to WP_Posts! ? Note Users in this preview screenshot ?
With that, though, comes the biggest announcement:
SearchWP 4.0 is a (full and complete) rewrite!
To date, SearchWP has stood alongside the idea that backwards compatibility should never be broken. It’s one of the things WordPress has done really well, as have a number of fantastic WordPress products that the community holds near and dear to its heart. That is changing in SearchWP 4.0.
Please note: SearchWP 3.x will continue to be supported well after SearchWP 4.0 becomes available, allowing ample time to upgrade when customers see fit.
In order for SearchWP to support more content types than WP_Post (and without having to write/maintain Extensions that would mirror additional content types as WP_Post entries) it meant that (quite literally) every existing model would need to change. The database schema would need to be updated, the assumptions made by the code would need to change. Terminology would need to change. The indexer would need to change.
Rewriting a code base is often frowned upon for a number of legitimate reasons, but if SearchWP is going to mature and get even better, a line had to be drawn in the sand.
Committing to this rewrite means that as of version 4.0 SearchWP is adopting SemVer. SemVer is an intentional versioning approach that better communicates what’s happening with a project. To date it hasn’t been super popular in the WordPress world, but that tide is changing as well.
If you aren’t familiar with SemVer, it means that major releases of SearchWP will include breaking changes. SearchWP 4.0 is the first of these releases. Because so much had to change in order to support what SearchWP 4.0 has to offer, the code has been completely rewritten, without regard to backwards compatibility. On purpose.
There will be a partial upgrade process (e.g. existing engine configuration) but SearchWP’s index will need to be rebuilt when upgrading from SearchWP 3.x. It will also be possible to upgrade to SearchWP 4.0 without losing your existing settings/index in case you need to switch back for any reason. There will also be the option to clean up (remove) all traces of SearchWP 3.x once you are ready to finalize your upgrade.
In subsequent posts more detail will be given regarding the upgrade process and details about SearchWP 3.x support/updates.
Technical debt be gone
With SearchWP being nearly seven years old, it had its fair share of technical debt. Moving to SemVer allowed all of that debt to be removed which has resulted in a much leaner and cleaner (and faster!) code base that can be iterated upon in a much more stable way than was possible with SearchWP 3.x.
Further, the WordPress ecosystem has embraced modern PHP which means that SearchWP 4.0 is going to require PHP7 at a minimum. This is good for everyone all around. ?
Technical debt wasn’t limited only to the database schema and models used, it overflowed into front end code and just about everything SearchWP did. Being able to remove all of that and embrace how much both the back and front end has modernized in the past seven years is a big win.
It also allows for new (and better!) features to be included. Take for example the updated Rules implementation in the screenshot above. SearchWP 3.x had some exclude/limiter Rules, but they were limited in and of themselves and a bit awkward to work with. SearchWP 4.0 rethinks both the implementation and UI resulting in something much more powerful:
Much about the main interface in SearchWP 4.0 looks similar, but time was given to evaluating the existing workflow and optimizations have been made to ensure that setting up SearchWP is as easy and straightforward as possible.
Managing which attributes are considered for each engine source (e.g. Posts, Pages, Users, etc) has also been updated and streamlined:
There is so much more to talk about (including enhancements to the indexer and search algorithm itself ?) but hopefully this brief overview begins to outline how great SearchWP 4.0 is going to be. Stay tuned for additional updates outlining what to expect and when!
