|
Dave replied to keymasher (message subsequently removed), but somehow it's become attached to a different thread. Or appears to be...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Looks like a case of careful timing: the reply message was posted while the offending message was being deleted.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: a case of careful timing
I'm stealing that phrase!
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
It's turning this:
<div>
<div style="clear:both;"/>
</div>
Into this:
<div>
<div style="clear:both;"> </div>
Needless to say, it's crapping all over my article content when it does that.
EDIT =================
The article editor does not match the preview
When I published my article all of the images disappeared.
It's clearly valid html, and to "fix" it so I can submit my article, I have to put a blank line were it's trying to artificially insert one.
What ever happend to the checkbox that said "Don't mess with my markup"? This is annoying as hell.
Here's the article - Entity Factory - Get Your ORM-less Freak On![^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 9-Dec-20 18:19pm.
|
|
|
|
|
The problem is almost certainly that your article contains the phrase sucks donkey balls, and in oversized red type to boot! 
EDIT: Might I be so presumptuous as to suggest rephrasing it as sucks the Big One, an expression much beloved by one of my former managers?
|
|
|
|
|
Greg Utas wrote: he problem is almost certainly that your article contains the phrase sucks donkey balls
I'm a truth teller. Sometimes, that violates sensitivities. That can't be helped.
Everyone will miss me when I'm gone. 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Unfortunately DIV tags are not self closing, so the wizard will auto-correct the HTML.
better to do
<tag style="clear:both">
content
</tag>
Than an empty DIV block. This way there are no extra divs
#realJSOP wrote: When I published my article all of the images disappeared
You need to ensure you reference images as src="image.ext", instead of the full path. Images move around. They get bored and restless. Referring them by name not path means they will be referenced in the article correctly.
There are a couple of other things I fixed, and a couple of code changes I'll add to fix a couple of odd issues your article raised.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: empty DIV blocks / self-closing
I wonder if I've ever know that... I built the HTML in the project, and Visual Studio didn't flag that (self-closing DIV) as an error. Bug in VS?
The really weird part is that when I previewed, and it mangled the article, I went back to the editor, and it had took all the missing div end tags and put them at the end of the article.
BTW, I always edit my articles in source mode.
Chris Maunder wrote: You need to ensure you reference images as src="image.ext", instead of the full path
Ahhhh, I thought using the full path would more reliably find the images.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
BTW, thanks for fixing it for me.
I have one more question...
Despite the width being specified to be 240px (like all the rest of the images), the first image is displaying much larger than the rest. Why is it doing that? Do I need to put a "first image" in there to make it leave all of the other images alone?
BTW, this seems contrary to the purpose of the Preview functionality that's available while you're editing, because the preview version of the page doesn't match the editor (which shows the image the desired size).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: the first image is displaying much larger than the rest
Welcome to my world. I've thought about creating a 1-pixel high white line and putting it at the top of my articles that contain graphics to see if it fixes this bug. 
|
|
|
|
|
Point me to an article that's having issues and I'll take a look.
cheers
Chris Maunder
|
|
|
|
|
This[^] is one of them. The width of the first image is set to 600, the same as the others, but displays as 720. It looks fine when previewed, so something is changing during submission.
|
|
|
|
|
This image[^]?
In my browser it's displaying at 700 wide (and smaller on small devices) but click it and you get the full 720 wide image in a popup
cheers
Chris Maunder
|
|
|
|
|
Yes, it's originally 720 pixels wide, but so are all the other images. They look a bit large in articles, so I scale them down to 600. But the first image insists on being 720 wide.
|
|
|
|
|
|
I don't follow. You tried to fix it, but you don't think it worked? The image is 720 pixels wide, but so are all the others. I set all of them to 600 pixels in the article editor, and all but the first one display at 600.
|
|
|
|
|
I didn't touch the images, so no change
You said "so I scale them down to 600" which I assumed to mean you physically created images that were 600px wide and then uploaded them. I assume you mean you set the width attribute on the IMG tag at 600 to have the browser scale it.
In that case, I'll dig in and see why it's showing at 720.
cheers
Chris Maunder
|
|
|
|
|
I re-scaled the originals, which fixed the problem in this article. I'll do the same to other articles that have the problem. But it's a curious bug and may only occur when the article has more than one image.
|
|
|
|
|
#realJSOP wrote: this seems contrary to the purpose of the Preview functionality that's available while you're editing
You mean when you switch from source mode to WYSIWYG mode, or when you hit the Preview button?
The Preview renders the article exactly as the article display page would. The exception is that once you publish, your images may get moved (eg you move sections or you go from pending (working image directory) to published (published image directory) hence the missing images.
There's also the issue of caching. Sometimes the browser (especially Chrome) is like a dog with a bone and won't let go.
I've re-edited the article (which forces the cache to be cleared our end) and that intro image is where it should be.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: The Preview renders the article exactly as the article display page would.
Yeah - what I'm saying is that the article *editor* doesn't match the Preview. That's confusing and frustrating because there's no way to "fix" what's happening in the preview because they're not the same.
I'm using Firefox (I only use chrome for porn - in a Linux VM). 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
The live WYSIWYG editing component uses the same stylesheets as the article display so should be the same. Subtle differences will come into play if our system needs to sanitise the HTML. You add script, or layout we don't accept (eg a 10000px wide div or crazy fonts), or you enter broken HTML.
The HTML you enter is auto-formatted by the editor, and then goes through our formatter to clean, to process images, to colourise code, and to ensure it's well formed.
In your case the issues were that their was malformed HTML and "incorrect" image paths (they seemed good, but hardcoding paths means they were fragile). The other thing that got you was using clear:both. The "clear" CSS is notorious and so CSS frameworks add their own clearfix class that actually does the job as one would expect. Things like that can certainly make things a little weird.
There's another subtlety that may come into play: when you switch back and forth from Source mode the editor will go through and make the HTML well-formed. I don't recall if it take your HTML, makes it well formed, then passes it to the editable DOM element, or if it formats it the other direction, or both. If it only corrects it one direction then you may miss seeing a change that's been made. Not sure on that one but we use CKEditor which has proven to be pretty solid and sensible, so I'm guessing this is probably not an issue (just hypothesizing here)
cheers
Chris Maunder
|
|
|
|
|
I am unable to publish article due to error of "Please choose a section for the article".
While first time drafting article, it was selected but after clicking publish button, error raised and further not able to select section due to no list in dropdown box.
|
|
|
|
|
Which article? I saw there was an article in draft form under your account but it was empty (and no auto-saved drafts so I assume it was never worked on)
cheers
Chris Maunder
|
|
|
|
|
I have saved this draft but after error it is showing empty.
This was happened 3 times.
Mahesh Patel
|
|
|
|
|
While tidying up D&A - the random keyboard masher's forum of choice - I found something new (or at least, new to me). CTRL + the "Delete message" button opens the confirmation in a new window - so with a bunch of 'em, hold CTRL down, click each button, then use CTRL+TAB to confirm each of 'em without having to move the mouse about so much.
That's brilliant - saves a little time when batch deleting "Message Closed" messages.
A little tiny change would help though: if the CTRL key is held down when confirming the delete, the newly cleansed page is opened in a new tab as well. If it could remain in the current tab, it would be one less operation: CTRL+click "delete" on six closed messages, then CTRL+TAB to visit each confirmation box, and don't move the mouse off the confirm button, just click it, and press CTRL+F4.
At present, I have to remember to release CTRL before I click and then hit it again for the "close this tab" command, or I get a new tab opening with the rest of the closed messages in it and have to CTRL+TAB past it.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
