I have recently upgraded TinyMCE to the latest version and the editor itself loads almost immediately. The issue I'm having is that the placeholder value takes up to 3-4 seconds to appear. I using the latest tinymce-django version and have gone through all of the docs and can't find a way to speed up the appearance of the placeholder. Has anyone else encountered this issue? I've attempted to turn on the compressor but it doesn't seem to make a difference. Because the interface loads right away it's hard for me to tell if the compressor is in fact turned on and if it's working.
So it seems to never fail....but after posting this question...I played with my init file....as it was giving me an error in the developer console....
I would up commenting out the line that was trying to reference my CSS file in the init and this seemed to speed up the load time even more. Now the placeholder loads instantly...This is the line that I commented out...
content_css: [
'//assets/css/mystyle.css'],
I don't appear to need this setting for now based on how I've used the source files to change my config appearance. I had an extra slash in front of the library and that seemed to be what was causing the placeholder load time delay. On to the next....
Related
Currently finding issue lazy loading CKEditor 4, appreciate any advice. What I tried:
Including ckeditor_basic.js but this already needs a CKEDITOR
instance
Loading ckeditor.js on click but this complains
'Synchronous XMLHttpRequest on the main thread is deprecated because
of its detrimental effects to the end user's experience.' as well as
some others errors, fails badly.
Any advice appreciated!
If you would like to insert CKEditor script dynamically you can use technique from this code pen - https://codepen.io/j_swiderski/pen/qPGRGb. It is important to wait for ckeditor.js to load before creating editor instance thus using setInterval to check if CKEDITOR object is available seems like a good idea.
In your comments you have written, you don't want editor to load every time you load the page. One of the reasons for that might be the size of ckeditor.js file.
If you think editor.js is too big it is important to answer yourself how much plugins you really need and then create editor accordingly to your needs using the online builder. Please have a look at below samples using dev-tools and notice the difference in ckeditor.js size: Full package has 600KB while Basic Package has only 400KB. If you just need the basic formatting then your ckeditor.js could get even smaller and should not be a problem when loading the page.
If you have created some custom plugins then recommended practice is to get CKEditor source code from Githhub, fork it, make changes/add custom plugins, build your editor. That way you will get minified and obfuscated editor instance which includes your custom plugins and again should not be a problem when loading the page.
Codekit 2 does seem to be refreshing in any browsers. I've literally just installed it and been setting it up to my own preferences.
I use my Mac's hosts file to point http://localhost.sites to localhost. I've never had an issue with this in the past (I just set Codekit to refresh on any URL including the word localhost).
Now in the new settings file I'm slightly lost as to where to put it... after a load of mucking about I think I'm in a real state and here are my current settings:
Can anyone shed any light on this? Codekit is not refreshing the browser (all files are compiling fine).
I was having the same issue, #Djave.
Now, while I won't assume you make the same mistakes I do, I found that some errors in my
were causing Chrome to ignore the refresh. Specifically, the closing tag was missing. Instead, I had
<script... />
instead of
</script>
Hope you found the issue on your end.
As Bryan from Incident 57 told me, the refreshing process in Codekit 2 is totally different to the refreshing process in Codekit 1.
Codekit comes with its own server which you are required to run. You can click it in the top right hand corner of the program and it will launch.
You need to have this running to get going. If you have PHP files (or other server side code) Codekit won't run it – so this is where you need your external server running but it is important that you still view the site you're testing at the address given i.e. http://djave.local:5757.
For a far better explanation of all of this you can watch Bryan the creator of Codekit walk you through this in this video here.
https://www.youtube.com/watch?v=YUgH0jlYur0
I'm making HAML/SASS changes for a Rails app which I'm running locally using a Vagrant/VirtualBox VM on Mac OSX (Snow Leopard), and I keep encountering a really odd issue whenever I make changes to an image referenced in any of the HAML/SASS files.
Here's an example of what happens:
I open a local Rails app page in my browser and all images are displaying correctly
I re-size an image (using Gimp) to make it smaller and save changes
I refresh the page to see the changes and the original image is still showing, but with the bottom cut off in proportion to how much smaller I made the image
I remove the image file from the directory and hard refresh the page to see what happens.
Sometimes the original cut-off image is still there, sometimes it disappears and I just see the missing image path icon
I move the image file back into the directory to try and force it to pick up the re-sizing
Sometimes this works first time, sometimes I have to do it 3 or 4 times before I see the correctly-sized image
Sometimes I see the old cut off image re-appear even after I have refreshed the page and seen no image!
The same issue seems to occur if I am making other changes to the image file (e.g. if I'm saving an entirely new image with the same file name). Apart from this image issue, all edits to HAML/SASS files work, and I can instantaneously see my changes.
I thought it might be some sort of browser rendering/caching issue, but similar issues occur in Firefox and Chrome. If I use Firebug I can sometimes see that the correct file is being picked up but it's not showing in the page itself.
I can only think that this has something to do with Vagrant. The only thing that is guaranteed to fix it entirely is restrating the Vagrant box, but that takes a long time.
I realise that this may not be a simple problem, as it may have something to do with our Rails app and configuration of Vagrant/VirtualBox, but I just thought I'd post the issue here in case anyone else has had similar issues.
Thanks!
What you're probably seeing is an issue that the VirtualBox shared folder filesystem has along with the sendfile syscall. You need to disable the use of sendfile on your webserver if you're serving files from a VirtualBox shared folder. Doing this is easy:
In Apache, add this to your configuration: EnableSendfile off
In Nginx, add this to your configuration: sendfile off;
I have an ecommerce site built on OpenCart (1.5.0 i believe), which after inserting tracking code from Alexa.com and a block of code for redirecting to another site went entirely blank. Initially it worked, so I felt it was safe to save over my backups. But after refreshing the pages it was blank, and the 'view source' option in all my browsers (firefox, chrome, safari) revealed that there was no code reaching them. I then began to follow a series of debugging steps:
As my text editor was still open I undid all changes and reuploaded with no changes
I scanned the documents to be sure there were no issues in the text, with no discoveries
I ran it through W3C validation, with 2 warnings which are 1- no character encoding and 2- unable to determine parse mode.
contacted host for a server side restore though their earliest backup was a day after the problem began (it took 3 days of arguing to get them to initiate a restore)
In regards to these validation warnings, I am not sure what encoding should be used for OpenCart, ASCII or UTF-8 (which the validator resorted to) or what, in addition I am not sure if the template used with OpenCart would conflict with it if I were to declare encoding. In addition, I find it hard to believe that such a widely distributed product would have something this simple causing such a huge mistake because then all users would have this issue.
In regards to parse mode, the index page does declare parse mode (in the included header file).
In addition to all this, the validator is also claiming that it is not receiving code at all, which disables any chance of determining problems through that route.
The header and footer were both edited for these additions but are relatively long to include in this. The code used to edit were, for alexa <!-- tracking code here --> inserted into the head section of the header file, and the code for the footer was:
<span style="display:inline-block;width:160px;height:30px;text-align:center;border:#000 1px dotted;font-family:Arial,Helvetica,sans-serif;font-size:11px;background-color:#FFFFFF;"><strong style="display:block;padding:0px;margin:0px;">Reputation Management</strong>Submit Express</span>
If anymore code is needed to help then please let me know, I am not looking for someone to fix my problem but to give me relevant tips to help figure it out myself or if they do provide a fix to educate me as how they managed it so I may be able to use the same debugging method. Thanks!
EDIT: The issue, as discovered thanks to Jay, is "PHP Notice: Undefined index: HTTP_HOST in **/public_html/graphic-shack.com/index.php on line 40" and a google search has not revealed any effective results. This, to my untrained mind is jibberish, clarification would be greatly appreciated as line 40 is in fact a blank line, where as the text around it I can not post for some reason but will be viewable at http://graphic-shack.com/example.html
Open Cart uses UTF-8 throughout, so its definitely best to use that which your theme should set for the browser in the
The first thing I would ask is have you got error reporting set up (NOT OPEN CARTS ONE) that logs php errors?
If not, then you need to do something like
php_flag log_errors on
php_value error_log /path/to/custom/error.log
in your .htaccess file, so that you can log all your php errors to a file. this will need to be somewhere you can get the file, so change the path accordingly so you can view it.
Once you have that, you'll have a good base for working out the problem. I find it hard to believe that opencart has stopped because you added code. The most likely cause is a file missing, blanked or half written accidentally when saving or you've got some extra php code somewhere you shouldn't
== TEST.PHP CONTENT ==
<?php
echo '<pre>' . print_r($_SERVER, true) . '</pre>';
?>
It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.