I am having an issue with DOMPDF. My code should be fine and I can post if you really want to see it. I dynamically create an HTML page into a cache and then pass it to create the PDF.
I have some REAL BASIC CSS and even was able to use custom font when on LAMP. But even running it with stock fonts, forcing crazy line height in CSS and just about everything else I can think of. I am getting the same smushed text results when on my external linux server.
I have fought with this for days and have googled until my fingers have bled.
Thanks in advance for any advice.
WAMP/LAMP side by side
Related
I have an issue with Ves Contentslider of VenusTheme as it dose not load properly on backend. It still works fine on front end but we cannot do any configuration as it's control panel does not load the content. This is pretty weird as we have not changed any thing in our site recently. Please have a look at the screen shot below to have better understanding. Thank you in advance.
Screen shot
I just fixed this issue and thanks to the Venus Theme team for the quick and accurate suggestion. I did compress the js&css files and it stop the website rendering the js&css codes properly. That is why the configaration panel did not load on the admin site. So, I just need to go to the back end and navigate to Configuration/Advanced/Developers/JavaScript Settings(CSS Settings) and chose No option for the Merge JavaScript Files(Merge CSS Files). Then everything work perfectly again. This is good to know when we consider compress our CSS and JavaScript files. Cheers
So in short, i dont mess with Joomla at all (been a few years) and today i get a "hey can you fix this" problem which ive dedicated too much time to and i cant seem to figure out the problem. i definitively need help
The website is http://www.inrecordtime.net
The problem is that, the slider doesn't fully work and by "fully" i mean that, everything is in place, ive checked paths and replaced the original files with updated versions, also changed out the google hosted cdn version of jquery with a local copy, checked image paths etc....and nothing.
What happens is that when the page loads, the first image on the slider loads, but the slider doesnt "slide" its just one image in place.
Ive tested the images on firebug and they load fine.
Ive removed the parameters in the slider and left it as a regular function call like jQuery('#slider').nivoSlider(); and nothing.
i placed back the parameters and within the slider, one of the parameters is startSlide
and this parameter instructs the slider to start at a specific image in the list.
currently its at "0" which is the first image, when i change it like so startSlide: 2 for example, and then reload the page, the slider starts at the second image (which indicates the not fully working part of it all ) but again, the slider doesnt "slide".
I suggested to the higher ups that instead of mixing it all up, to let me hard code it but that was shot down because they want them to be able to change the images.
Im really lost so any help or code or suggestion etc, i humbly appreciate.
Thanks in advanced.
Based on the errors that are popping up in my console, you likely need to update the jquery.nivo.slider.pack.js file to a later version, which you can grab from here: https://github.com/gilbitron/Nivo-Slider/blob/master/jquery.nivo.slider.pack.js
The version you are running relies on the live function in jquery, which was deprecated and I think is now removed, hence the errors being thrown now that you use the latest jquery version. The new version of nivo slider has been updated to rely on the new on function of jquery and should run.
Looks like your version is located here: http://www.inrecordtime.net/templates/IRT/scripts/nivo-settings/jquery.nivo.slider.pack.js
I'm in a pickle. I've designed a Joomla 2.5 site, which I have locally installed. I typically equip my installations with JCE editor for my clients, but at design time, operate in HTML mode. When all the content was in, I decided to test WYSIWYG mode to make sure nothing went awry. Unfortunately, something did. Observe the lack of spaces:
Very interesting that the problem occurs ONLY when saving from WYSIWYG view.
At first I thought JCE was malfunctioning (although the editor itself continued to show spaces), so I tried reinstalling. Then I tried other editors -- CKEditor and TinyMCE. The same symptoms manifested with them as well.
Trying to isolate the problem, I checked the database after pasting in clean markup in HTML view, and again after saving in WYSIWYG view. This is the result:
So, based on the database field, it would appear that the process of saving, in either HTML or WYSIWYG view is working properly... But then why is the output being fed to the browser different depending on which method was used to edit?
So far I've checked entity encoding, CSS (although it's obviously not a CSS issue), and tried installing on another local server. No changes in behavior.
I could really use some suggestions.
Thank you in advance for your help.
Z
PS: This is the latest version of Joomla (2.5.6), running on Apache.
When we typed some text continually this issue was occurred. Actually this was not the issue this problem was solved by using correct css style for that division.
<style type="text/css">#divid {width:750px;word-wrap;break-word;"}</style>
You have to use this css style for your division . Surely this ll resolve that problem...
I am helping a client with an eCommerce site (runs on ProStores from eBay).
The issue is that the site's base stylesheet is breaking (being disabled) when the page is translated with the Google Translate widget. This only happens in Firefox. Chrome, IE(6-9), Opera and Safari are all fine.
Translate in FF was working prior to some changes we made recently: mostly graphical, some additions to the stylesheet. I had to tip-toe around their templates which were built with tables, outdated code etc. so I am overwhelmed when trying to troubleshoot this.
Here is a link to the site: http://www.myfantasticbags.com
(open in FF and use google translate in the header area to see the issue)
Thanks in advance!
I had the same problem and much frustration with this.
The problem I was having was that it was translating my website's font-resizers - From 'large' to 'grande' etc. which was throwing off the font-resize element and entire site.
Try adding a class="notranslate" to any elements you think may be translating and throwing off your stylesheet.
Hope this helps!
Korey
Add class="skiptranslate" to the head tag.
If you also have a link to a print preview style sheet, so your visitors can see how pages will print, try this: Putting the link to your external stylesheet inside a div with class="notranslate", may not only fix the translation in Firefox but also when flipping back and forth between your print preview and default CSS in all browsers. I know that divs in the head tags are atypical, but I don't see any problem arise from that.
We all know that pre-fetching images can run slow because of browser limits in the HTTP protocol, right? So, I have XHTML, jQuery, Apache httpd, and PHP at my disposal. What's an easy solution to pre-fetch a lot of images, without using sprites or multiple hosts?
See, I have these themes one selects with a SELECT box. It changes the 200x200 theme image on the right of the box. Unfortunately there are like 150 of these. So, when I load the page, the progress bar keeps running to download these all.
How can I get these images pre-fetching faster without using sprites or multiple hosts?
If it's just a theme change, which probably rarely happens (right)? Then why wouldn't you just load the image for a theme when the the select is changed and a new theme is chosen? It seems "strange" to load 150 images of which 149 may not be seen.
Correct me if I'm missing the point - and if so, can you provide a screenshot so I can get an idea of what you're really trying to show?
Hindsight is probably 20/20. I probably should have implemented it in sprites, as well as for many of the buttons I used on the site. It's just that I lack a good sprite editor tool that speeds that process up.
Anyway, the strategy I went with was to use Javascript prefetch via jQuery. But even that wasn't enough. I had to wrap that function in a setTimeout(), but that only helped a little. I then had to fire that setTimeout() during a login form submit. It made the login form submit slightly longer, but made the website appear snappy on load.