Several popular CMS's such as Drupal, Wordpress, etc. have an index.php file that is pretty much empty except for a include/require statement that includes some other PHP file (as in one file) containing all of the bootstrap code for the CMS. What is the rationale for this? Why not just move all of the bootstrapping code into index.php if it is doing nothing other than including the bootstrapping code anyway?
I'm trying to build a CMS as an example project to improve my PHP skills, and I'd like to understand what design considerations led them to do it this way. I understand the benefit of breaking up applications into multiple files, but I've never heard of making a file that does nothing but include another one. Obviously there is some benefit, since several major CMS projects designed it this way, but I just can't figure out what it is.
Can someone explain to me the reasoning for this?
In Drupal's case, there are other files that do a similar bootstrap. These typically aren't normal pages, but do serve important purposes. Off the top of my head cron.php, update.php, and install.php do this. I use the bootstrap process at the beginning of custom import scripts, as well as scripts that get called by cron that I don't want to use a hook_cron for.
I can think of two reasons:
When using a product like Wordpress, you sometimes end up adding user hacks to the front controller - say, setting custom constants, specific redirects, or an additional layer of access control, or whatever. An empty index file allows you to add that kind of stuff without disturbing the product's original code.
Having everything in a separate bootstrap creates the possibility of moving all code (including the bootstrap) to a location outside the web root, and include it from there.
Aesthetics mostly. You can have a clean and neat directory structure (outside of webroot), in which bootstrapping files are separated from index.php file. There are probably several of them (vs. one index.php file) and they are doing different things (db init, authorisation).
I also found one or two CMS which start in debug declaration (in order to switch display errors and warnings before including any files, so you can have your errors printed before php includes a file with syntax error, but that's not really a good practice).
I would say this is good design because you can easily change the path to the bootstrap, which makes it very easy to change location of the CMS, if ever necessary.
Another good reason is you could also be running a dev CMS while developing, and roll out new versions with one path change in the index.php.
Related
I'm sort of new to WordPress and using stripped down WordPress themes. I recently started using underscores. So far its great and I will definitely continue to use it. I would just like to understand it better so I can use it correctly.
One thing that confuses me is the architecture of the theme. All of the templates that are created be default with underscores call to template parts which are located in the template part folder.
I've seen other themes that use this method as well. My question is why is it better to set up the site architecture in this way as opposed to just creating the template by itself with out using template parts? My thinking is the more parts there are the more confusing the site is and the harder it is to debug. There must be a reason if so many sites use this type of architecture.
If you separate your code in "template-parts" (in this case) you can re-use it and if you need to change something on it, you just need to change it once (instead of all the places you used it).
Break your code in smaller and independent parts to make it easier to maintain and to reuse.
I'm working on a premium theme for WordPress, it's my first. My question is how modular should/can I get my code before it gets to be a problem for the server or other developers who buy my theme?
For example I have 3 custom post types with taxonomies and custom column headings. Should they all be in one php file or can I break them up so that each post type is in its own file?
I'm thinking that for future projects more modular is the way to go so I can just drag and drop the pieces that I need for that project. I don't want to make my theme any slower though so I could use a little advise on how granular to make my files.
I've bought themes in the past that have both extremes but want to set myself up properly from the start.
Thanks.
This is an opinion request this one because either approach works and based on this information plus the fact you seem keen on individual files. I would encourage just that.
Modular approach works with themes if you plan to provide the same functionality per theme as you won't need to edit functions per theme. I would go with individual files and just put them in a folder. If one of those files has a bug you'll be quick on applying the changes to all the themes you create.
If you put all the functions in one file and each theme gets its own versions of those files due to requests etc. Then you create a little more work in that you copy and paste code. Not a lot of work but then that demands on just how much that single file changes over the years or even within some months.
There is nothing wrong with many folders and files. It won't have an effect on loading. It would take hundreds of include() or require() before it becomes an issue.
I am working with a pre-existing zen-cart site has been worked on over the years by multiple teams. Backtracking through all of the teams is not a viable option. Some of the development teams implemented some hacks, one of them being replacing how zen-cart normally creates links, and I am stuck as to how they did it. For example, zen-cart normally links to a product through a link such as the one below:
http://yoursite.com/index.php?main_page=product_info&cPath=67&products_id=823
Instead, this zen-cart installation is doing the following:
http://yoursite.com/item-name-here-p-45-.html?cPath=1_26
I have figured out that the number after p-, in this case 45, is the product ID. However, I am stuck as to what that .html file is actually referencing. I am guessing that it is somehow feeding that data back into the index.php file, and it was done for search engine optimization purposes. The server is using nginx if that makes a difference. I would rather use apache for this site, but I am fine with nginx.
Additionally, there are also links such as:
http://yoursite.com/sitemap.html
but there is no file called sitemap.html on the entire system. However, there is a file called sitemap.xml
For a myriad of reasons, I can't link to the actual site and I hope you fellow developers can understand that. However, if anyone has any idea as to whats going on here, I would be very interested to know. I will provide what other details I can.
I just figured this out, and I want to share my answer for anyone that stumbles upon this. This was caused by something called Ultimate SEO which masks urls with html links to make them more search engine friendly. The reason there are no actual html files involved is because Ultimate SEO creates a .htaccess file that reads the filename from the URL, and converts it to parameters to be passed to a php file. I just simply disabled Ultimate SEO from the zen-cart admin page. Furthermore, Ultimate SEO is something that is used outside of Zen-Cart, so if you are having the same issue I did, this might be it, or something similar.
I've built a complex site for a client, who wants this duplicated, and re-skinned, so it can be used for other means.
What is the best way of doing this? I'm concerned about copying every file as this means any bugs must be fixed twice, and any improvements must be implmented twice.
I'd look to refactor your code.
Move common functions into a library you can reference from both projects. As you mention that the new site is for a different purpose then you are likely to see divergence and you don't want to hamper yourself later, so extract the common parts and then modify copies (or if appropriate new files) of the remainder to complete your fork.
If you haven't applied good practice already then now is the time to do it and it'll make your work on both sites easier moving forward.
If all the functionality is the same and only the layout is different you could just create a new css file. 2 websites could have exactly the same code base but have different stylesheets and look completely different.
I think that using a version control system like subversion or preferably git, is a good way to duplicate your website. You will be able to track the changes that you make and revert to older versions if things do not work out.
You should implement some kind of instantiation, so look and feel, content and data will be shown depending of what instance of the application is accessed.
In other words, each application access to the code with a different application identifier, meaning content will be served depending on it.
Both application identifier will be pointing to different settings, so stylesheet and content will be absolutely isolated, and both domain will be living in the same IIS application.
If you want to duplicate a whole site it's probably best to copy the whole thing and amend as necessary. Obviously taking great care not to copy large portions of text or else you may be penalised by the search engines.
There are ways you could put the new site onto the same shared host (say within a subdirectory of the original site) and literally 'share' some files. If a unique change is required, you could instead reference a 'local' version of a particular file.
However that sounds like a recipe for a headache to me. I'd prefer to duplicate the whole site. It would be much easier to replace one or two functions on separate websites than it would to try and work out which website(s) are affected by a particular change to your source.
I starting working with WordPress as a CMS, now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.
My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").
My biggest theme is pretty small, and all it does is display custom posts in a custom way.
After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?
several thousands of LoC
That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;
Write less, do more!
You might be much better off using Pods CMS alongside WP to cut down your code.
This is how we structure client deployments that include themes, third-party plugins, and custom code.
wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed.
wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.
mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations.
That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.
Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?
There are basically three ways you can do this: prefixed functions, with require_once's including files by functionality, which is quite common.
The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.
The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.
I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.
Hope I helped!