I have recently deployed a solution from Development into Staging but the scale of pages on Staging are noticably different to how they were rendered in Dev. It's the same on pages with the default master page like settings.aspx pages see how the grey ribbon doesn't quite line up when they are put side by side.
The s4-workspace div has a style element attribute applied to it on the default pages, but when using the custom master these don't exist. Also changing the attribute values to be the same on the two sites in the browser dev tools doesn't make any difference to the display.
The corev15.css of the two servers are not quite the same which is interesting, but the differences are so small and definately aren't causing the issue.
This phenomenon disappeared without a fix.
It was suggested to me yesterday by a colleague that it might have been a zoom setting in IE. I've just set one browser to 105% and another next to it at 100% and it was an idential the originally identified size differential.
Looks like it was an accidental Ctrl+Mouse_Wheel_Scroll.
Related
I am working on an e-commerce site and the product images are NOT visible on the live site but they are visible on my local development version even though I am using an exact copy of the code and database. What is even weirder is that when I open the developer console and look at
- the source code for the images is there and also the preview of the image is correct which tells me that the image is loaded correctly it must be something else.
Also, the only difference between the development site and the live site is that the live site runs on SSL, so I guess the problem could be related to that but I have no idea what it could be - the image urls start with https.
Here is an example page where the images are not visible.
Also, to mention the website is build with WordPress and WooComerce, custom theme.
EDIT: For some reason the images are no longer visible on the local version as well.
One of the parent elements / ancestors of the image (in single product view) is a DIV which has the class attribute woocommerce-product-gallery woocommerce-product-gallery--with-images woocommerce-product-gallery--columns-4 images and a style attribute which contains opacity: 0, i.e. completely transparent, therefore it remains invisible
So you have to find where that opacity setting is added and deactivate it. (Or if it's static, simply remove it from the HTML tag)
Have a look at the following site http://www.soe.gr.
The whole page has been built with CSS Page Builder Magic 2 (projectseven.com).
Every button is a link to a different .html page.
However, I do not know why every button press creates a flash effect in the page, the background changes instantly color and generally it gives an impression of abnormal operation. I have not met any site with such behavior except some pages inside projectseven site.
Do you have any idea why that happens? Is it something wrong with Page Builder Magic approach?
I am new to Web Development world and I want to know if there is any problem with these guys.
Thank you very much
I checked it out, it doesn't behave abnormally at all for all those effects you have there, I checked out the size of one of the images it is about 250kb, then imagine the other images which I assume are of the same size, and they are all going to be loaded when the page loads, you definitely should expect some effect
I have some pages that are loaded with a hash/anchor in the url. When we do this it screws up the padding/margin of the document. Without it, it works fine.
What's even stranger is if I use the browser tools to get to the css and disable the margin and padding and then reenable it, it looks fine. We are using a third party web site to serve our site which means we're kind of locked into a CMS type of service and our hands are tied to a certain extent as to how much we can customize our pages. So, therefore, we have multiple css files referenced and so forth.
If you look at the two urls below you'll see the issue in the one with the #company_settings appended to the end of the url. If you then use inspect element in chrome to look at the header and disable and reenable the custom.css:2 for margin and padding, you'll see it then fixes the problem. Any idea why this is happening and if there's something I can do in css to fix this? Thanks.
http://www.patriotsoftware.com/patriot-pay-help-center-payroll-settings
vs
http://www.patriotsoftware.com/patriot-pay-help-center-payroll-settings/#company_settings
Using a hash in the URL signals the browser to scroll to a specific location of the document.
And the browser is exactly doing so.
If you can edit skin.css (which sounds so by it's name), go into line 6:
#foxboro_header {width:100%;overflow:hidden;}
Change it, remove the overflow rule:
#foxboro_header {width:100%;}
This should make it work.
BTW if it's a block element, the width is automatically set to 100%. Setting it would be redundant then.
Next to that the code of the page is full of validation errors, deal with them otherwise you might run into more and more problems.
I had a similar issue using hash.
There is/was a some bug with display: table and hash url. I changed it to display: block and it was working correctly afterwards.
Hope it helps someone.
A mobile web site project I've been working on has been recently been analyzed by a performance consulting firm and they came back recommending that we move all of our .css file links to the BOTTOM of the HTML to accommodate issues on the iPhone where .css files can block concurrent server requests.
I've always known this to be true on most browsers when it comes to .js files--hence the common practice of putting .js file links at the bottom of one's HTML--but I've never heard this about .css files.
I have yet to get a response from the consulting firm with cited references as to this being an actual issue on Mobile Safari. Has anyone else heard of this and, if so, know of any specific references that talk about it (perhaps from Apple directly?)
This is not intended to be an answer to your question, but as a reference:
Best Practices for Speeding Up Your Web Site from Yahoo:
Put Stylesheets at the Top
While researching performance at Yahoo!, we discovered that moving
stylesheets to the document HEAD makes pages appear to be loading
faster. This is because putting stylesheets in the HEAD allows the
page to render progressively.
Their recommendation to move CSS to the bottom is unusual - would appreciate it if you could share why they found this to be a good idea.
edit: Looking at the general guidelines on apple.com, I couldn't find any particular reference to CSS inclusion applicable only to Mobile Safari. The basic, general instructions still state that you should place CSS in the <head>. See this page.
If you load up the following URL (http://waynepan.com/s/con/) on your desktop and then your mobile browser you'll observe a curious behaviour; On a desktop browser (Chrome & Firefox at least) you'll see the boxes populating from top left to bottom right (in the same order as on the source code) and on a mobile device (iPhone, iPad at least) you'll see the exact opposite occurring.
Albeit undocumented, this observation would suggest that the mobile browser reads the main html file first and then proceeds to render the page bottom-to-top thus loading latter hrefs first and working it's way up to the top.
You'll also observe that on the desktop browser up to 6 boxes are populated concurrently and on the mobile browser up to 4 are populated - this accounts for the maximum concurrent connections that are allowed by the browser in question to any one host.
Therefore, if page load and render speed is especially important in your mobile web app, take special care to order the loading of elements accordingly. I think your consultancy firm colleagues had observed a similar behaviour and wanted to force the CSS to load before all the other content - it would all render with the correct styles from the outset, giving the illusion (or user experience) that the page loads faster.
Alas, my 1 cents worth - I hope it is food for thought. :-)
I have a modified version of a flex calendar found Here, and though it looks alright on most computers I've seen, there is a problem on two of the three servers here. Because of the way Citrix is setup here, I need to have it functional on all of the servers.
When it loads, everything is stretched out vertically, and the numbers are missing on the date boxes. If you mouse-over the flex buttons, they jump to the right size, but there is still rendering errors.
The modifications I made had no effect, because the servers give the same results on both my version and the demo version hosted online. As far as I can tell, the servers are identical (IE version, Flash version, etc.)
How can I get it to display normally?
Initial View
After Mouseover
Usual Demo
Demo in bad server
Edit: On the server that renders it improperly, Firefox renders it fine, but Firefox cannot be used for other (unchangeable) reasons.
From the images it appears this is how the SWF appears in the Browser of each server - one good and one bad. Not how the SWF appears in any browser while being hosted from each server.
Sense it is the browser display that is not working correctly I would assume it is a rendering problem with the browser and not the server.
1.) The problem could come from JavaScript being disabled in one of the browsers and the view being taken from the embed tag. Check to ensure that it looks the same with JavaScript both on and off.
2.) The height being 100% could also be messing it up in the browser. Try setting the height to a specific value (800px) and see if that corrects the problem.
3.) Make sure that the browsers are the same. Is one IE 7 and one IE 8? If they are the same, check the version number to ensure that all updates are the same for each.
4.) View the site from another computer that is connected to the server.
Number 1 and 2 would be my best guess as a way to troubleshoot.