I'm currently working on a website. I am using wordpress along with a theme. I'm trying to make modifications to the theme. I'm doing this via a child theme as recommended.
I'm running into an issue where I'm trying to make changes in the child's style.css . However, many of these changes do not seem to be going through.
As an example (refer to my website here: coffeedev.com), I'm trying to make the main container's corners rounded. I'm doing this with the 'border-radius' function.
When I do this in the child theme's style.css, the changes do not take place. So I'm trying to understand why the changes aren't taking place.
From research, I believe it is either due to my webhosting (through godaddy) having some kind of server caching, thus the changes aren't updating when I reload the page, or it is due to some underlying overriding taking place. However, I'm not familiar enough with CSS to determine where the overriding would take place.
Any help is appreciated!
Issues when the server is running ATS, Varnish or similar cache utility that the author has no control over. Sometimes cache files stick around for a while and users have no control over caching applications. If you want your css, javascript, image or other asset updates to be reflected instantly, this is the perfect solution for you.
https://wordpress.org/plugins/wp-version-in-query-string-modifier/
Related
We need to recreate our site from scratch. When I mean from scratch I mean we want to keep the same content (pages, articles, URLs and tons of media) and move it to a new WordPress installation with a different theme.
A brief background to try to understand what the underlying problem is. The current site (the one to be copied and transferred) is HUGE. It has more than 1500 pages and 3000 articles. It is currently running on an old version of WordPress and an outdated theme. We are deliberately not updating WordPress, theme and PHP so as not to risk crashing and being left without a site (this has already happened in the past with another installation).
What we have done is to create (on the same hosting) a new, updated installation of WordPress (on another directory). This will be the new and definitive one. Then – when all is said and done – we should use the name of the first installation (but this will be another issue to deal with at the end). We decided to operate in this way because we want everything to be done as safely as possible.
Some details:
Objective: SITE 1 -> SITE 2
SITE 1: Installation: domain.org/directory1 WordPress 5.2 PHP 7.1.33
Theme: Awaken
SITE 2: Installation: domain.org/directory2 WordPress 5.7.1 PHP
7.1.33 Theme: Divi Builder
At the moment, we have already installed the new theme in directory2 and created the home page that will host all the pages and articles from the old site. We are not interested in keeping the plugins. Our aim is for the new installation to be as “clean” as possible, without the risk of dragging around old problems.
What do you think is the correct way to proceed? Again, the most important thing is that the links are not changed (so that the URLs will still work once the change has been made; I mean: domain.org/directory1/perma/link/article-written-in-the past = domain.org/directory2/perma/link/article-written-in-the past
Could the export/import tool do this job? How should I proceed to make sure that I don’t affect the performance of the new site? Is it possible to carry out a test with a few pages to see if this can be done?
Thank you all!
The first step is to create a backup of the existing site. You can do this manually, you need all of the site files plus the database.
However, Duplicator is a great plugin that will create a backup package that includes everything for you. One thing to be aware of is the size of your site may cause issues for the plugin do to server load, but its the easiest method. There are other plugins as well to help with migration.
Once you have everything you can copy it to a new domaon like dev.website.com. The installer from Duplicator will help with the url updates, but its pretty easy to adjust in the config file and database options table. If you use relative urls most things wont be an issue, but a simple find and replace in the database will easy update any absolute urls.
Once you have made all your changes in dev you just reverse the process by writing over the live site and your set. This is safe beacuse you have a backup of the live site from step one in case you need to revert to the current state.
I've edited my page defaults in concrete5 and have a frustrating problem - when I add a composer control, I cannot push the change to existing pages. When adding e.g. a page title it works:
but when adding a composer control there's no option to push it to child pages.
This basically means that I have to recreate all my pages if I want to take advantage of the new default component.
Is there any kind of a solution?
This is a C5 bug that is still waiting to be fixed. If memory serves a fix was added to the core but I think it turned out to not be totally solving the problem and was pulled back.
You might want to update to the latest version and see if it fixes the problem but really no guarantee.
The only other alternative is to make sure you really plan your page types well before using them. I know it sucks a bit.
How can you start making changes inside a WP theme and then keep track of them for future them updates ?
You can use some sort of version control software like subversion to track updates. Also in terms of just "hacking", it is all based in PHP so you can just drop into your theme and make changes as needed to any of the files as they pertain to what you want to do. For example in order to make any sort of changes to the header, typically you would edit the header.php file.
One way would be a version control system like Subversion.
My experience has shown that it is best to go with a very well developed and customizable theme (occasionally paid) that allows you to make the majority of changes within the theme's settings rather than hard coding them. When the theme is updated by the author, while not impossible, I find it is rare they've butchered something from a previous version. If they did, they'll often offer not only a reason but a possible work-around.
Another think would be to have a testing environment where you can try out new releases of a theme without risking harm to your live site. Just google 'wordpress testing environment' and that should point you in the right direction. For the record, I run XAMPP on a spare windows pc for this process.
Last bit of advice: if you do make any changes to your theme, back the theme files up regularly. In the event something does go haywire, you wont have to design the site from scratch.
I'm helping a client with their website (it's manually written using a Dreamweaver template and a ton of quadruple-nested table elements for design. Ouch), and I want to offer them a break from using Dreamweaver to write things.
I was thinking of using Wordpress or a similar CMS to do the job, as Wordpress is clean, fast, and really easy to design for. I've done it a few times, and it's almost as easy as just coding pure HTML.
My main concern is that the site has been hacked a few times before, even though it was pure HTML with no server-side code whatsoever. I can setup a manual Linux server for them, because the hosting company they use is one that I've never heard of.
The site owners are completely technologically impaired, so I don't want to scare them off by showing them a dynamic CMS with tons of features, as they think pure HTML is so much safer, they have to go out of their way to work with it.
I know this is a ton of writing, but what would be the most appropriate CMS for such a setup (hard-coding or dynamically generating content) for such a setup? I don't want to keep having the person manually write non-standards compliant quadruple-nested table layouts anymore, but I don't want to be responsible for having their site hacked...
Thanks!
A solution that allows for local editing, and the uploading of only static HTML files, would be the safest way to go. If it's a high-risk site, I would consider staying on that track.
If a site containing only static HTML was hacked, then most likely through some problem on web server or even operating system level - I am not aware of any exploits concerning static HTML resources. Problems usually come up when dynamic languages are involved.
Whatever you do, don't use Wordpress. It is bound to be subject of exploits and attacks simply due to its popularity.
If the site is pure HTML, then the insecurity is in the server, or the connection made between the server and the client.
I'd look into how to make the server more secure before making changes to the site, although doing both is a good idea. CMS's like WordPress use MySQL databases to store posts, etc, so that means client -> server connections. A way to make transfers of data more secure is to use https:// instead of vanilla http://. You can redirect using a .htaccess file if need be.
To summarise, I'd look at the server side of things for any vulnerabilities.
James
Wordpress has become a pretty wonderful CMS. If the site is high-risk, you might want to shy away from it, but I haven't had a site that I thought was too high-risk for WP myself. The site should keep up with regular updates and regular backups and there are some security tips that you can follow to help keep it more secure and less of a target.
First. Hide WP on the front end
Add this to your functions.php:
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
That will remove default header info that can be searched for by scripts.
Install wp in a directory that will help obscure its location and obscure the admin URL.
Change the name of wp-contents folder to something else and move it outside of the main wp directory. For instance, you could name it "includes" and put it into the root folder. and then links to template files will not have wp-contents in them.
On top of that, use a secure host, lock down your files (especially on shared hosting), and you can look at something like vaultpress, but it seems like if you use a solid backup plugin and a good host, that is unnecessary. You can also look at some of the security audit plugins, but don't keep them running after you get feedback.
This code in your wp-config.php file will help to install in a directory and move wp-contents outside of it into an "includes" folder:
define('WP_HOME', 'http://domain.com');
define('WP_SITEURL', WP_HOME .'/admin');
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'].'/includes');
define('WP_CONTENT_URL', WP_HOME .'/includes');
Wordpress is good for blogs
Typo3 is a good cms but hard to learn at start
Joomla and Drupal can be used as cms
Suggest me, is it a good idea to make changes in default Joomla code structure?
I need to keep an insert query after every insert/update/delete operation in Joomla administrator code. so that i can track the change i have made.
Is it good idea to make the changes every where in the default code in Joomla default structure?
Generically speaking (that is, without knowledge of Joomla internals):
If this is your one and only project and you just build upon an existing codebase, go forth and modify it. It helps to keep track on what you did where, if you want to port Joomla updates later to your codebase, but sooner or later you should make a cut.
If, however, you use Joomla for more than one project and/or want to keep in track with Joomla's future development, changing core files can (and presumably will) become a maintenence nightmare. The only way to keep this in usable dimensions is to restrict touching core files to a minimum and well-defined set of places.
I assume, you want to go with the second option. In this case, let me give you some advice on what worked at our company:
We mangled with WordPress. What helped us much, was to store WP in one folder and a version of files we touched in a different folder (in our VCS). This way, we always knew exactly, what file from the WP core we touched. Making a productive environment was 1. exporting the WP files and 2. exporting the shadow copy and move it over the WP core files.
Writing extensions/plugins: Almost any larger software has a way to extend it. Learn the plugin/hook/extension/addon mechanism of Joomla and try to do as much of your changing as possible with that.
If it's database related: Maybe it's enough to change only one file of Joomla: /libraries/joomla/database/database.php. Even better, it might be possible to extend this class (or JDatabaseMySQL, that is) and somewhere in the configuration tell Joomla to use this class.