Hello Thierry,
if you have five minutes, I'd glad to hear from you. I have two questions regarding your framework, cause I am planing to realize a project with it:
1. Design Development Is it correct that global modifications (header, footer, sidebar) should be placed into the child theme's function.php, while different landing page layouts (home, about us, departments etc.) will be placed into an own template file for each landing page? We are going to have about 40-60 pages, with about 15-20 different layouts. Will so many different files can lead to performance issues?
2. Mentainance The most important part for us is to develop a product, which can be easily mentained not for months, but for years. I know that a clear answer on this can not be easily given, since there can be unseen circumstances, which could change the roadmap of beans. Other frameworks have a much more active community forum and community base, which is not always meant to be a good thing. I just want to be sure, that beans is alive and in development for the next few years.
Up to now I've tested your framework a little bit and I am already in love with it. I am far behind to understand how exactly this framework works. But even now I can already imagine how powerful this framework is, cause u can insert anything everywhere the way you want. So I'd love to give beans a fair try.
Kind Regards Pascal
Hello Pascal,
Welcome to Beans! I'm going to answer your questions in opposite order. Plus, I'm going to provide some professional advice along the way too to further help you get started with your project.
I just want to be sure, that beans is alive and in development for the next few years.
The Beans Community and Beans framework are alive and active.
Beans Framework
A quick jump over to GitHub will reveal that Beans has been maintained for years by @thierry. I joined the team as a co-maintainer late last year, partnering with Thierry. Together with the Beans Community, we are driving Beans into the phases of innovation.
Looking on GitHub, notice that we are actively contributing to the framework. Right now, we are working on the v1.5 Roadmap which involves the following:
- Making the codebase WPCS compliant
- Finding and fixing bugs
- Writing both unit and integration tests
- Improving the documentation
Once that process is complete, then we begin work on Beans 2, which will be a huge leap forward with enhancements including:
- Increasing the minimum PHP version from 5.2 to 5.6
- Making it UI framework agnostic, meaning you can use UIKit, Foundation, Bootstrap, or whatever you want (i.e. Beans 1.x has UIKit embedded within it)
- and much much much more
Take a look at the Beans 2 Roadmap.
Beans Community
We have an active Slack team. Our contributing team meets bi-weekly via Google Hangout to discuss our action plans, ideas, Roadmaps, and more.
We are actively working to grow our Community which includes:
- creating a marketplace for theme and plugin authors to sell their products.
- redesigning the Beans website and making it a central repository of helpful tips, guides, and examples to empower developers, designers, implementers, and users to get the most out of their Beans-powered websites.
- creating tools to help people like you quickly acclimate to Beans.
- professional developer training initiatives at my site, Know the Code.
- and much more.
We invite you to come join our contributing team and get involved to propel Beans and this Community far into the future. Come join us on Slack.
- Design Development Is it correct that global modifications (header, footer, sidebar) should be placed into the child theme's function.php, while different landing page layouts (home, about us, departments etc.) will be placed into an own template file for each landing page? We are going to have about 40-60 pages, with about 15-20 different layouts.
The first part of your question is what what goes where in your project.
Let's start with understanding that the theme is for building and rendering the web page's markup and visual styling. It's the "skin" of the website. I talk about the intent of Themes vs. Plugins in this free episode on Know the Code.
Plugins - Extending WordPress' Content
When you have content extensions, such as custom post types, taxonomies, shortcodes, and/or widgets, these belong in a plugin. They are extending the content of WordPress. Therefore, the intent is different from a theme. A good design practice is to group them by intent and build a separate plugin. For example, group everything for a Portfolio and build a separate plugin for it.
Reusable - Group Like Items
As you begin to architect your website, identify commonality between all of the different types of web pages you will have. You'll find that a very large percentage of the website has common features, visual styling, and functionality. All of the commonality can be built into reusable functions.
Building using a reusable, modular architecture ensures that you use as little code as possible without redundancy. That's a better practice, as it reduces your time and costs over the entire lifecycle of the website.
functions.php
The functions.php file is the bootstrap for the theme. Just like we have a bootstrap in a plugin, this file is the theme's launching point. It gets the theme ready to run, initializing states and setting up the theme.
A common practice in WordPress is to dump everything in this file. I'm not an advocate of that design architecture. Rather, I see it as a true bootstrap, calling the files that hold the functionality, theme setup, initializers, etc. that need to be loaded for the theme.
I advocate grouping like functionality and placing them into individual files and folders by their intent. It's part of the Single Responsibility software principle. Think in reusable modules and group like code together.
For example, if you are modifying, replacing, or extending HTML markup, that's structure in Beans. Adding fragments (snippets) would go into fragments. And so on....
Will so many different files can lead to performance issues?
Load one really huge file vs. breaking it up into smaller, more purposeful (grouped by intent, form, or functionality)....
The different is minimal. How small? Microseconds, tiny fractions of a second.
You noted that your project will have a lot of separate templates. But WordPress loads only 1 of those templates, as each is bound to a specific web page. Therefore, your theme could have say 50 separate full templates, but only 1 will be loaded for each web page. Does that make sense?
Wrap it Up
I hope you don't mind that I went a little deeper to help you get started with your project. Feel free to ask any questions here about Beans. Or come join our Slack team.
Cheers, Tonya
Hello Tonya,
thank you so much for your very extensive answer. While I just have started with websites and development last year as a small hobby, I quickly reached the limits of those overbloated multipurpose themes, which are sold on themeforest. Worked with the7, enfold, avada newspaper and divi. Apart from avada those themes do not really have something like custom hooks to modify the markup or output of your website. If the custom wordpress hook did not fit my needs, I begun to edit the pure .php files on a child theme basis. In my last project I modified the custom nav walker just to get a simple html output of some custom information. That was the point where beans popped up. With beans such tasks are so much easier to implement and to maintain. That's the reason why I am going to join the community here. Plus the page sizes. Tons of functions and options, which are never being used, bad UI's, huge style files just make me sick.
I am going to join your slack community, but I have to admit, that I don't have intermediate skills in php. I guess, beans will also be the perfect match to imrpove my php knowledge. Nevertheless I hope, that I can be a help for the community in some way.
Last question regarding my topic: I saw that tip, that we never should edit beans main files. Does this also apply to header.php and footer.php? I searched and studied some child themes of beans on github. Some of them are using a child theme header.php with modifications. Is this the way to go in your opinion or should I really stick to edit the markup by the provided functions?
Thank you so much for your warm greetings and welcome. Nice to meet you! Pascal
With beans such tasks are so much easier to implement and to maintain. That's the reason why I am going to join the community here. Plus the page sizes. Tons of functions and options, which are never being used, bad UI's, huge style files just make me sick.
Innovation. Incredibly fast websites. Rapid web development. These are cornerstones of Beans.
I am going to join your slack community, but I have to admit, that I don't have intermediate skills in php. I guess, beans will also be the perfect match to imrpove my php knowledge. Nevertheless I hope, that I can be a help for the community in some way.
We welcome all skills levels. There are many, many ways to contribute. Plus, we help one another too.
I saw that tip, that we never should edit beans main files. Does this also apply to header.php and footer.php? I searched and studied some child themes of beans on github. Some of them are using a child theme header.php with modifications. Is this the way to go in your opinion or should I really stick to edit the markup by the provided functions?
You should never ever ever modify a parent theme, including Beans. Why? Whenever we release a new version of Beans, all of your changes made in the Beans framework will be overwritten and deleted.
Instead, you build a child theme and make all customizations in the child theme. In your child theme, you can change the HTML markup, build new templates, customize the look and functionality, etc. The child theme is yours, meaning when your client updates Beans, all of your customizations are retained. Why? Because you put them in a child theme.