Hello, I’ve the following problem: when writing an article in the wordpress panel, I should see exactly what appears on public website, right? Instead, in WP panel the new line starts before than in the public site. Why?
Also, is there any way to remove this option?
Thanks.
Post editor: http://s17.postimg.org/9r8ifc6kf/Cattura_di_schermata_253.png
On the blog: http://s17.postimg.org/d9kibq7gf/Cattura_di_schermata_254.png
-
This reply was modified 11 years by
daimpa.
Hi,
That line changes based on the screen width you have and it has been added there to help you get a preview of your post depending on the width of the screen in which you view/preview your post.
You can change it by altering it’s css here: http://screencast.com/t/WE4OrojndgTU
Thanks
If I view and preview the post on the same screen, that line shouldn’t resize automatically? I’ve the problem on a PC Desktop, 1440*900px resoultion.
Anyway, if I do the modification suggested by you then it works fine on PC, but I think that it’ll work bad on other devices, right?
Thanks for your patience.
I’ve had no issues with this on our site(s); and I thoroughly test our site on desktop (Mac/PC), iPad Air, and iPhone 6, with no issues with layout when “live” on the web, and no issues with preview.
The line first threw me when I saw it too, but I mostly work in text mode except when pasting in articles from couple of writers who work in MS Word and I have to paste into the visual editor. It’s actually kind of nice once I figured out what it was for, to have a better idea of how wide the “real” column is on the site while working in the editor.
I don’t recall seeing an explanation of that in the theme docs, but I might have missed that also.
UPSHOT: on one production site and one test site, it has not caused any issues whatsoever (links available if curious).
Hello, thanks again for your reply. A great theme with a great support, it’s amazing! 🙂
I’d like this feature too, if it works. For me, it doesn’t work 🙁
I’ve tested it with 4 screen: Desktop PC 1440*900px, notebook 1366*768, windows tablet 1368*768, windows phone 4,5″ 1280 x 768.
With default settings, it doesn’t work in any of them.
If I put the tablet in landscape mode, in the post editor it shows what I see in the post page when it’s in vertical, if I put in vertical in post editor it shows what I see in the post page when it’s in landscape, but I think that it’s just a coincidence.
If I put 640px in the .css files like suggest by Lucian, it works everywhere but in tablet when it’s in vertical mode and windows phone in vertical mode.
The problem is that I’m not the only one who will write articles. If this is not a problem for me, I’m not sure that for other it’ll be fine, so I’ve to fix it.
Hello Chris, thanks once again for your reply.
I’d prefer to have it working rather than disabling it.
Maybe that my bad english is causing some confusion, so let’s try to clarify.
What I expect is that that vertical line should make the text going on a new line in the post editor page exactly when it goes on a new line in the public post page. This vertical line should automatically resize on all devices, so that in the post editor I’ll always see what I see in the post page.
Am I right?
If it would work in that way, then I’d be more than happy to have it enabled in my website. The problem is that that line doesn’t work in that way, like shown in the screens, and I’m trying to understand why, so I can fix it… Am I the only one with this problem?
It doesn’t work that way, due to dpi of the monitor, font size on different devices, differences in font files on different devices, etc.
In other words, expecting the words to “wrap” identically in the editor and the live page will never happen. A web browser is a fluid reader, and not a fixed device like ink and paper (e.g., “real magazine”).
You have no finite control over layout as you do with something like QuarkXPress or similar print production.
So, for example a web-safe font, and even a Google font may have different kerning, metrics, letter spacing, etc. depending on device, and somebody might even have fonts over-ridden to “always” use Times Roman, vs seeing PT Sans or whatever.
So, a line in the editor which is 8 words long, might only be 7 words long on the “actual” page, as it’s only a virtual preview, and not a “pixel accurate” preview of the live page. WordPress isn’t that precise. It’s a blog platform which has “matured” into a CMS. It’s not a professional publishing application for multi-platform publishing at a micro-control-level.
In other words, it’s impossible to make something like “identical” on all devices using this kind of product, or really any modern CMS; because the web isn’t a fixed viewport on ANY device.
——–
In the same way, the “metrics” and DPI of different devices makes WordPress admin panels render slightly differently per device — this is a function of WordPress… so if the “line” is set to take 50% of the view; well, the view is going to vary in width per device. So, 50% of 640px on a desktop might be 50% of 600px on a tablet due to responsive layout and resizing to fit the new device; etc.
Nothing is inherently wrong or needs to be fixed, this is just how it works.
The divider line is an “aid” not a 100% exact representation — it’s not a WYSIWYG setup 🙂
-
This reply was modified 11 years by
simchris.
You can see my sites …
production site now live with Newsmag as of this past weekend; this was old news portal in our network moved from ooooold pre 2009 template system, and still tweaking: http://floridanewswire.com
And here is my test (hobby) magazine site- http://ga-ga.com – which is an ongoing process as I’m basically rescuing content from several of our “defunct” websites and moving them into ONE shiny new place while we’re doing original content as well… it’s not technically a live/promoted site, even though it’s being shared in social – it’s not in Google News, for example, while the Florida site is.
Sites are not fully optimized… meaning minification and font optimization not yet done, as I had done with Newspaper theme. In any case they look great on all devices (well. logos still need to be tweaked for mobile …. but that’s my job, not the theme’s problem).
Just thinking again about this… “It doesn’t work that way, due to dpi of the monitor, font size on different devices, differences in font files on different devices, etc.” If it’s the same monitor, preview and public post on the SAME monitor should look the same, right?
I’m thinking again about this as I’ve just seen this image: https://forum.tagdiv.com/post-editor/ To me it doesn’t work in that way. On the SAME monitor, default settings, preview is different from public post.
I think it’s wrong.. right?
These two screens are taken from the SAME monitor:
Post editor: http://s17.postimg.org/9r8ifc6kf/Cattura_di_schermata_253.png
On the blog: http://s17.postimg.org/d9kibq7gf/Cattura_di_schermata_254.png
Looking at the image you posted in the tutorial, it should’nt work in that way, so I think there’s a bug somewhere…
I have this issue too if I change the post content font or size. I think with the default font/size it works but if you change, the backend editor won’t be a true representation of the front-end.
-
This reply was modified 11 years by
ajaffarali.
I’ve tested it on a new installation, monitor 1440*900px… Nothing to do, the text in public post goes on a new line after it doesn in the preview post, ON THE SAME MONITOR.
Can you confirm that post preview-public post should be the same, on the same monitor, independing on its px, without doing any customization?
-
This reply was modified 11 years by
daimpa.
I would like option to DISABLE the custom functions being loaded for the visual editor, if possible. I’m having some issues when also using WooCommerce. The visual editor, for example, shows bullet lists with indents, but there is no indent on the actual page. The divider line is actually a hindrance when editing some things as I need to keep scrolling more up and down to get to the info I need to edit.
I would prefer normal WP behavior where the visual editor allows you to set bolds, italics, center things, etc., but not try to second guess the page layout which will vary by device.
Also, running into an issue where when switching to visual editor some HTML entities get converted to ISO elements, and then when going back to text editor, they lose the encoding, and in the published page under view source you have ISO garbled characters.
Overall, great idea, but causing some issues, obviously.
An option to DISABLE this custom mods to the visual editor would be appreciated.
I’d like an option to disable it too, but if we can have this working, it’d be better.
Really, I don’t understand why it doesn’t work to me, even on a new installation. Maybe that there’s a bug with PC resolutions 1440*900px? Could you test it with this resolution please?
I’m running two Apple 24-inch cinema displays at 1900×1200 but my issues are slightly different from yours. I only use the visual editor when pasting in MS Word files for articles. The rest of the time I use the text editor as I need to be able to manually enter a div class, or whatever. My issues are where something is conflicting even with the simple use of a <br> tag in the text editor, and <p> tags don’t seem to work either. I can only line this up with the visual editor bleed-over for the whole post page. And of course I could be totally wrong. But, on a WooCanvas site I am using <br> and <p> tags and they all behave as expected; not with Newsmag.
CORRECTION: I am NOT having this issue on my sites which use NEWSMAG and do not have WooCommerce running. I just tested that. Some element of the visual editor code is conflicting with the WooCommerce post page, likely due to the extra meta boxes added by WooCommerce. So, this seems to impact pages, posts, and products.
Weird thing is there is no console error on the pages themselves, so it’s totally a back-end thing.
Will be happy to help debug this for WooCommerce, but I realize this is different issue than what @daimpa is experiencing. Suggestion to @daimpa …. do a screen capture video showing the issue, if possible to best illustrate the situation. In my case I will experiment with turning some things on/off with WooCommerce to sort out what is causing my problem as well as the http element not loading via https in the visual editor page. I have separate ticket for this – and apologize for polluting this thread. 🙂
Don’t know how to explain better than this:
On the same screen
This is what I see in the text editor: http://s3.postimg.org/w6f4wumxv/ex_1.png
This is what I see in public post: http://s3.postimg.org/71o4jfnhf/ex_2.png
This test has been done on a NEW wordpress installation.
Is this normal?
Yes, that is normal. The size of the font used in the admin panel is not the same as you might have on the website, and the theme is responsive, so the “actual” width will vary as far as word-wrap.
Again, the visual editor is not a “what you see is what you get” editor like you have in print publishing; it’s an “approximation” … it’s not “pixel accurate” … partially because the WordPress admin uses CSS from WordPress, while the actual page uses CSS from the theme.
So, the value in the visual editor is in doing elements like alignment, pre-viewing photos and videos, or MP3 audio, bolds, italics and other “presentation formatting” … but it is *not* a 1:1 view of the actual page. This is true of WordPress and always has been.
So, in your last example, it’s working correctly. You cannot manage exactly where line breaks are, or word-wrapping as the font and kerning, and so forth may vary based on the device being used.
So, on one device you might have 7 words, another 6 words and the 7th word goes to next line due to letter spacing, kerning, and the space between letters (not to date myself here, but I went to Compugraphic Typesetting school in 1985… so kind of savvy on font issues).
Upshot; based on your screen shots above… you’re just fine. 🙂
If it works in that way, that tutorial is wrong: The Visual Editor will adapt depending on your Post Layout, and the article will look exactly the same.
https://forum.tagdiv.com/post-editor/
Also, on their preview, the text goes on a new line when it does in preview, and this could be confusing, as I would expect it to work as shown in their screens.
-
This reply was modified 11 years by
daimpa.
Hi,
I have also tested this on every screen width and found no issue:
* http://screencast.com/t/tYm1erJ3 (desktop)
* http://screencast.com/t/Gc7JpvwKoF1s (tablet)
This is influenced if you change posts content font size/family.. so I suggest you test this with the default font settings.
@daimpa This could not work wheel in your case if you have removed the css code I’ve suggested at the beginning of this post so make sure that you take into account this aspect.
@Chris I have added this on our issue tracker list and we will further investigate it and fix if we find something wrong with this and also consider adding an option for this.
Sorry for the inconvenience caused! Hope this helps!
Thanks
Hey @Lucian, I think that I’ve found the problem!
http://s22.postimg.org/fic3k2hc1/Cattura_di_schermata_308.png This has to be set to 1 column and it works fine, if it’s set to two column it doesn’t work, even if there’s enough space on the screen! Tested with 1440px*900px.
Could you confirm that this is the issue? Will you be able fix it?
-
This reply was modified 11 years by
daimpa.
