Forum Replies Created
-
AuthorPosts
-
SuuzenMember
Dear Jennifer,
1) If you have made the changes in your css file, cleared your browser cache, and do not have any caching plugins like W3 Total Cache installed and activated, and you still cannot see changes you make to your css file, then your hosting company may be using caching technology on their server, which means you will have to wait for anywhere from ten minutes to a couple of hours to see the effect of changes you make to your css. You can contact your hosting company and ask them what you should add to your .htaccess file to prevent this server caching.
2) If you don't mind experimenting, you can try adding the anti-caching code explained in step 6 of http://www.ipserverone.info/programming/how-to-prevent-http-file-caching-with-htaccess/ to see if this will work.
3) To do this, retrieve your .htaccess file from your website server by using an ftp program. If you do not have one, FileZilla FTP is free, but there can be problems viewing the .htaccess file with it. See https://wordpress.org/support/topic/cant-locate-htaccess-files for some suggestions to remedy this. Other ftp programs and solutions for viewing your .htaccess file for retrieval are at https://www.rackspace.com/knowledge_center/article/locate-your-htaccess-file.
4) Once you have downloaded a copy of your the .htaccess file using ftp, save a copy of that original .htaccess file in a separate folder on your computer. it is a good idea to also create a new folder on your website server named something like "originalhtaccess" and upload a copy of the original .htacess file to that folder as well, for safekeeping.
5) In case you do not know how to do this, changes and additions to an .htaccess file must be made in Notepad, not a word processor. Notepad is included with your Windows operating system. If you find you do not have Notepad, you can download the free program Notepad++ and use it instead.
6) Once you have made the changes to your .htaccess file to prevent caching by your hosting company's server, upload the revised .htaccess file to your website server. If you then have any problems viewing your site or logging in, upload the original .htacess file again. If the changed file works, don't forget to upload the original .htaccess file again once your site is finished. If you have somehow lost or damaged it, you can use the copy of the original .htaccess from the "originalhtaccess" folder you created on your website's server.
7) Once your site is finished, you can then upload any caching plugin you want to use and activate it. If you make any subsequent changes to your .css file, you can go through the above process again.
8) Hope this helps! Good luck!
'Best regards, Suuzen Ty Anderson
http://www.lawmarkets.comSuuzenMemberBelinda, you might also want to try alternations to margins and borders - sometimes extra vertical spacing exists due to one of these. Line-height can also influence vertical spacing. You can test alterations to any or all of these directly in Google Chrome’s element inspector, which might allow you to pinpoint the change needed before you alter your css file.
SuuzenMemberBelinda, what theme are you using? It's difficult to provide any detailed suggestions without something to see.
SuuzenMemberCoral Seas IT, I really like your child-of-child concept. I look forward to reading your post when its ready!
SuuzenMemberThanks, Coral Sea IT, but I use specific item identities because I don't style all my inline widgets the same at all - some contain logos, some contain non-logo images with rollovers, some contain multiple lines of text, some contain search boxes, some contain links with explanatory text below. It drove me crazy trying to write css for padding, margins, font color and size, etc. the way I would for a non-content-management site, until I determined that the only way it could be done was to use the widget-specific WordPress id's and then write the css for screen and mobile breakpoints. Specific-item widget id's are also really helpful for styling list items in vertical expanding and collapsing jquery menus, where you may want more padding or margin to separate the top list item of the menu from a menu title.
I absolutely agree, though, that if you change widget types the WordPress id will change and you'll have to get the new WordPress id to rewrite the css. If you just alter the content of a widget, you can use the same id but you'll still have to rewrite the css. And if widgets in the layout differ between pages, you'll have a lot of css to write, and you'll have to be very careful to write tight css so as not to bloat the styles file and slow page loading. And of course, you can't safely do any this on a stock child theme that could be updated; all of this css customizing only really works on a custom theme. Your points are very good ones for anyone who is entering their own content in a stock theme that could change.
SuuzenMemberIt took me a while to get this one figured out as well. You will have to create a new style specifically for that element, but that means you have to know what WordPress is telling the browsers to call that element, and it won't be anything that is currently in your style sheet. You can use Google Chrome's element inspector (see https://developer.chrome.com/devtools/docs/dom-and-styles). You right-click on the element, select "inspect element" at the bottom of the window, and look at the bottom left window to see what the element has been named by WordPress. On the right will be your style sheet, which will not be adequate by itself and will have to be modified to add styling just for that element. Here's an example: I used Brad Dalton's 3-widget header tutorial to replace the header in a child theme with three inline widgets by modifying functions.php. In my stylesheet, I added the styling for .featured-widgets per Brad's tutorial. Then I ftp'd the updated functions file and stylesheet. Then I dragged a text widget into each space and inserted my text - name inn the left widget, phone in the middle, directions link in the right.
Then I looked at the site in Chrome, and of course all three widgets looked terrible. So I right-clicked on each widget in turn, selected "inspect element" and saw that WordPress had named the first widget, "#text-14.widget.widget_text" So I styled that widget separately, meaning I added more styling to what was already given by .featured-widgets. Same with the other two widgets, renamed illogically "#text-3.widget.widget_text" and #text-4.widget.widget_text" So I put new styles for each one, individually, right under ".featured-widgets." After more tinkering, they eventually looked fine.
You have to remember to use the exact id WordPress has given each element - i.e., a div id "#"or a class id "." and be sure to put it in the right place in the stylesheet - right below the element that applies to the whole thing according to the stylesheet on the right side of the elements inspector at the bottom of the screen. If the element then looks terrible on a cell, you will need to drop down to the bottom of the stylesheet and add more styling for that element or others surrounding it using mobile breakpoints. (Don't ever add mobile styling in the middle of a stylesheet - a mistake I have also made.)
Also, if you are really, really stuck on fixing up a widget, try using Black Studio TinyMCE Widget instead. It's free at https://wordpress.org/plugins/black-studio-tinymce-widget/ and will let you add html and styles to just that widget.
-
AuthorPosts