Hi everyone,
I’ve read the docs but I still don’t really understand the purpose of Tailor vs regular plugins.
Anything that could help? I think the idea of Tailor is to develop faster but not sure why/how and if it can be limited at some point.
Hey @apinard
Tailor is indeed a lot faster and easier to learn, however, it makes some common assumptions that sacrifices flexibility. If you are coming from a background of working with plugins, using plugins is still “the way”. You won’t need to redo anything since your work is already following the October CMS patterns.
Tailor implements a newer approach to translation called Multisite, and this is a feature that is available to plugins, including RainLab Blog (with modifications). Here is a link to the multisite trait documentation: Traits - October CMS - 3.x
The Multisite trait is more robust because it uses different models for each locale/site. Whereas the Translate plugin simply swaps specific attributes on the same model. Both have pros and cons, both still offer value for specific scenarios, and we will continue to maintain both.
Regarding the RainLab suite, these plugins were intended to be examples to showcase the possibilities with October CMS. So if you are using them as a basis for your work, then this is also the way.
Moving forward, we recommend designing new plugins in Tailor and then using the Builder plugin to convert them to plugins. This is a powerful way to scaffold your plugins.
For basic content, we recommend staying in the Tailor ecosystem because it provides native tools for managing content, such as drafts, scheduled publishing, import/export, previewing, etc. We will continue to improve Tailor for content-focused use cases, such as content owners, revision history, etc.
This is a design decision that should be made by you:
- Tailor is 10x faster for development and saves you a lot of time (content focused)
- Plugins take more time to develop but have greater flexibility (data focused)
The content focused RainLab plugins (Blog, Pages, Sitemap) are still good as a plugin, but they have difficulty covering a “one size fits all” scenario like Tailor can. The Tailor equivalents of these plugins are included in the demo theme and the implementation uses far less code.
For example, the entire Sitemap plugin is just two files using Tailor:
- october/sitemap.yaml at 3.x · octobercms/october · GitHub
- october/sitemap.htm at 3.x · octobercms/october · GitHub
Hopefully this helps to clarify the purpose of Tailor.
3 Likes
Hi Sam (@daft ),
I was trying to migrate from Rainlab.Sitemap plugin to Tailor solution and the biggest problem was to maintain changes across many sites.
With Tailor solution when you need to change XML structure or configuration structure, you need to manually change them on all sites (60+ in my case).
With plugin solution I can change plugin’s source on one place and with next update all sites are up to date.
I love Tailor for single site solutions when building separate plugins is time consuming.
But for code I need on many sites - like sitemap XML - plugins are better solution I think.
Best regards,
Jan
2 Likes
Hey @jan-vince
Yes, plugins are still really valuable and Tailor is just another tool. So the choice is yours.
For example, plugins support the “blueprints” directory just like the app. So, you could build a plugin that has the sitemap blueprint inside and use a PHP route to serve the sitemap.xml content. It is the same outcome, but with the benefits of blueprints.
1 Like
The sitemap shipped with the v3.6 demo theme uses the Site\Menus blueprint. Create one and use a slug specifically called sitemap and the sitemap page will locate it.
If you want the old sitemap blueprint, you can find it here and copy it to your app/blueprints directory:
Thanks @daft - I’m happy to create a new one under the Menus blueprint, I discovered it yesterday and how to create it. The issue I have now (having copied over the original sitemap.yaml file is a bindings issue too. Is there a way for me to remove the Sitemap option under the Settings > CMS menu if it’s not going to work?
Clear the cache with this command
php artisan cache:clear
This should remove the cached blueprint from the system. And check that the blueprint is not still in the app directory.
I am not that knowledgeable using those commands - is there a way to do this within the Dashboard?
We really need a button in the admin panel for this.
For now, delete this file manually storage/cms/blueprint-navigation.php