My dilemma: My small team has been pegged with the task of refactoring/redesigning a rather large Drupal site. The site is littered with unused modules and content types, CSS/JS/HTML/etc hacks, and has a myriad of strange work-arounds for external data imports. I am currently the sole backend developer for the team, and our Drupal expertise is beginner level. We cannot build a custom CMS because of the amount of content that the site has combined with the complexity of Drupal's DB structure, it would be impossible to export it reliably; as well, content is being constantly added and modified on a daily basis.
My question: Is there any best practices, tips, advice, or any suggestions that anyone can provide that might aide us in our attempt to refactor this site?
Specifically...
Detecting, disabling, uninstalling, and removing unused modules and QAing afterwards.
Updating modules and QAing (systematic approach?).
Detecting and deleting unused content types.
Detecting and removing unused PHP code (tpls mostly).
Detecting and removing unused CSS/JS.
On modules back-end page you have dependencies shown for every module. Is some other module using it and what other modules current module uses. So, if you see that module is not used by any other module and that it's feature is not needed you can try disabling it first, check if everything works well and finally remove the module.
About content types - go to content, check is there some node of specific content type you doubt it's not needed. If there are nodes of that type try viewing them. It they are not styled well...might be that they are not used/needed.
Php - hmm...you can i.e. add some line of your code writing out some thing, or even saving some text to the file and then open page...see if you'll get some output or something saved into your file. You can even call exit() function and check will it break the site.
Similar with JS - alert something or write to console to see will it be called.
And most important thing - make a backup of all files and database first!
Related
I was given a Drupal project and asked to figure out how its code base structured and how the project is structured overall.
I successfully installed it using xampp.
Now I see nothing custom in the project:
For blocks I have only Bartik and Rubik. For content type only Basic page. For file types Audio, Document, Image and Video. For menus Main Menu, Management, Navigation and User menu.
So, does it mean that I was given a blank empty project? What else may I check that may have been customly changed in an empty project? What may I have missed while installing the project that may cause it to become empty, without any customisations? Maybe it is possible to check for something in the files of the project?
I am asking a few questions here, since I am not sure which one of them will convey the matter which concerns me. But basically all of them mean the same: I just want to see what someone else did in the project. And the more customisations I will find, the better it will be.
Thank you.
This does look like a virgin install typically does. If you were expecting to see more, perhaps you need to import a database...
Confirm you've imported the project database and that your settings file is pointing to it. It looks like you're using Drupal 8, so the file should be in sites/default/settings.php
Check under Content to see if any nodes have been created. If you have some sort of botched import, you can also try accessing a few nodes randomly at example.com/node/1, example.com/node/2 to check directly in case something is wrong with the index
Other than Nodes, Drupal content can be also in the form of Views. These are available at example.com/admin/structure/views. This is usually for heavily customised content. There are roughly 15 default Views that come with Drupal 8.
A default install will have no Modules installed in /modules. If you're seeing any directories there, it could be that the site was relying on these to display the content you're being asked to admin.
Trust this puts you on the right path. :)
I have a ((very)) simple WP site with the above mentioned theme.
The theme loads a ton of external .css and .js files above the fold that causes render-blocking and I am sure I don't use half of them.
The header.php only includes a few directly and most are included via the php wp_head() -tag. I am struggling to find out, which .js and .css are in use and which aren't. Also how to get rid of them totally since I feel like using 'defer' or 'async' is only solving the problem partially.
My site is http://toptand.dk. Be aware, that I currently use WP Super cache for compressing and autooptimize to further minimize render-blocking etc. which might make the header look very different. I would rather get rid of it for real.
I have read many articles about how to prevent render-blocking, but non really explains how to deal with all the crap from a WP template.
The theme loads a ton of external .css and .js files above the fold
that causes render-blocking and I am sure I don't use half of them.
This is very typical of commercial WordPress themes; such themes load many files, as many are required for the "multipurpose" backend functions which provide short-codes, drag-and-drop features, custom post types, ecommerce, etc.
You sacrifice speed and page weight for all those features you use as well as the potential features you don't. If you need speed and a light-weight site, don't use a theme like that. You can go into that theme and wp_dequeue_script scripts and style sheets, but the features theme will break. See https://codex.wordpress.org/Function_Reference/wp_dequeue_script
Try a simpler, lighter weight (and free) theme from https://wordpress.org/themes/ and learn how themes work https://developer.wordpress.org/themes/getting-started/ in order to get features you want without all the extra code.
You can utilize Chrome Dev Tools' Audits tab.
I am struggling to find out, which .js and .css are in use and which
aren't
Upon selecting the Audits tab, include Network Utilization based on necessity but mandatorily check Web Page Performance option. Once the selection is done, either click on Audit Present State or Reload and audit.
Once the process is complete, the results will provide inputs on the number of unused CSS rules. This will give you an idea about the unused CSS.
Also how to get rid of them totally since I feel like using 'defer' or
'async' is only solving the problem partially.
The recent version of Chrome (59) has brought in a new feature called Coverage (you can find this under More Tools inside the dev tools). This helps in understanding the percentage of the CSS being used in the current page and clicking on one of the results redirects to the code and marks the portions of non-executed code in red and the executed ones in green.
These inputs should help you optimize your assets and remove the unused code.
Hope this helps!
Before I get to the question, let me say that I saw a similar question here with a fairly detailed response:
https://wordpress.stackexchange.com/questions/115211/loading-wordpress-stuff-on-laravel-site
And it was the closest thing I have found on the web to what I'm looking for, but the potential solution looked like it might end up being so laborious as to not be worth the time. Here is my situation:
I develop and maintain a small custom SaaS program that typically functions on a subdomain of a client site (say, software.client.com). The latest version of the code was rewritten using Laravel and there were a lot of gains associated with that. In the past, when the program was basically procedural spaghetti, if we had a client with a Wordpress site on their primary domain, we ran some atrocious (by best-practices standards) hack-around code to pull the Wordpress header and footer onto the pages of my program - sitting, of course, outside the CMS - while modifying meta tags and doing a number of other things. It wasn't pretty but it worked.
Now I'm in a situation where I'd like to solve the same problem - that is, to at least pull the Wordpress headers and footers onto some of the Laravel subdomain views - but nothing I have found on the web so far has enabled me to make much progress in that direction. I have found a lot of tutorials explaining how to integrate Laravel and Wordpress, or use one for frontend and the other for backend, etc., but nothing yet about the specific type of integration I'm talking about.
What I have tried so far is implementing some of the code I've used elsewhere into various parts of the Laravel codebase. Most of the recent experiments have been in public/index.php and in Controller methods. Laravel will allow me to get as far as including the Wordpress config, but if I attempt to go any further I cause a 500 error. Here's an example snippet that actually attempts to do more than I need, but I can't even get past wp_init(). Imagine the following code in a Laravel Controller method. The first two lines are OK, but:
public function index() {
define('WP_USE_THEMES', false);
require '/path_to/wp-config.php';
$wp->init(); // from here on, 500 errors occur
$wp->parse_request();
$wp->query_posts();
$wp->register_globals();
// And then, at some point, I would call and modify get_header()
(I didn't really expect this to work from the Controller, but it doesn't work from anywhere else in the codebase I've tried either.) This is not a situation where I want to hand off control from Laravel to Wordpress for these URLs (I need Laravel functions / DB queries and more flexibility, and I know I could just do that hand-off through public/index.php and routes.php if it would solve the problem). And for these intallations, I don't need to grab posts or other items from Wordpress. I would just like to find a way to pull the header and footer into these views directly from Wordpress while maintaining control of the views in Laravel. If I can't, among other things, the design team will end up rebuilding headers and footers for every program install on a Wordpress client (for the time being) and they will have to make changes in at least two places when things are modified or updated.
If we have to, we will find a way to live with that until the next program version rollout, but if I can build a solution in what my superiors will deem a reasonable amount of time, we would all be happier. I hope that I have just missed something simple somewhere and I will be embarrassed to find out that I could have solved this in less time than it took to explain the problem. Thank you for any and all helpful responses and potential solutions.
You're not going to be able to cleanly merge the two codebases together. That would cause a disaster.
The complexity of the solution depends on the complexity the information you need to share. The simplest solution possible would be to write something custom to WordPress that builds a document with no body data and just supplies a token, like {!! $body !!}. Then, in Laravel, you can do an HTTP request to localhost to fetch this tokenized content. Store the result in a memory cache and use Blade to render the final view.
Essentially, my suggestion boils down to: Create a Blade layout with WordPress.
There's a thousand different ways to do this, and all of them are wrong.
How do you upload an image with a custom post type in Wordpress without hacking at core files or injecting that multipart thing with jQuery?
The answer depends on what you are going to use to manage those images once they are uploaded. If the upload-and-create-custom-post is all you care about, then you could do it with a trivial plugin.
However, if you want to do the whole management enchilada, then the simplest thing might be to copy the code in wp-admin/upload.php and wp-admin/includes/template.php and make your own changes to that. There are very few action/filter hooks in this code and some of the comments indicate that it goes way, way back. In upload.php there are several SQL statements that have post_type='attachment' hardwired. Changing those should be straightforward. Mercifully, you will probably have only a few changes to make in template.php. As the comment at the top of that file says, "A Big Mess. Also some neat functions that are nicely written." So true.
The one thing you must not do is hack the core files themselves. WP's one-click upgrade is critical to their security fixes.
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.