new create entries beta

[denise]

We had the old "new JS on journals" beta reporting entry as the topmost entry in this comm, which was causing some confusion! So, a fresh post for people to report problems they're having with the new Create Entries beta.

Things not yet implemented:

* a WYSIWYG/rich text editor to allow people to post formatted entries

* the ability to save draft entries, both so you can deliberately postpone entries for posting later and so that an unexpected browser crash or problem during the posting process won't cause you to lose work

* admin editing of community entries

* the "don't autoformat" checkbox (we can't quite figure out which pane to stick it in!)

Things that will be documented once it comes out of beta, but some people have missed:

* if you don't like the placement of panels or don't want to see certain panels, you can customize the placement and which panels appear by using the " Settings" link in the main toolbar at the beginning of the form.

If you have anything else to report, please let us know here!

Comments

[fu]

Weird! But I'm glad it resolved resolves itself.

[denise]

Sunspots!

[ilthit]

I've had the beta test on for ages, never had any trouble, but this morning the "post entry" button became unclickable? I tried several times. Odd. The non-beta posting page works fine.

[jazzyjj]

Hope somebody sees this. I originally posted this at the entry above this one, but then I saw this and figured my comment belonged here. I just began testing the new beta Create Entries page this morning. I'm assuming this is the latest beta, since the comm hasn't been updated for like a year and a half. But anyway, I'm running the latest version of OS X El Capitan on my MacBook Air. I've tested with both VoiceOver and Chromevox, and haven't had any issues thus far. I like the new settings form.

[zaluzianskya]

How close is this to complete? I've been using the beta for so long I forget it's not the default.

[denise]

We still haven't found a good solution for rich text/WYSIWYG, which is the main thing holding it back from being appointed as default!

[ironpeacockworks]

Annoying quibble:

I have no apparent way to select a specific comment option for a particular post. If I'm missing something, please point me to it. :)

The option I'm looking for is whether I want all comments screened for "that specific post" (when it's not the journal default.) I'm looking to apply this to a "sticky", but it could be useful for any post on anyone's journal.

[denise]

It's in the Comment Settings panel!

[zvi]

read the february news post and went looking for the post as mod hat flag. It works a little differently than described 9 months ago (not surprising), but the community moderation specific widgets are not movable in the layout, which is weird because everything else is, and they are beneath all of my other post options (this means I have to scroll 2 and a half screens below the post button to get to them). I realize that other people's layouts will be somewhat different, but I think that a sometimes option that isn't really visible near the main thing one is doing (writing a post) is an option one often won't realize is there.

Probably you are limited in the amount you want to mess with adding a thing to people's create entries page, when 80% of the appeal is that one has customized it, so the two obvious solutions that leap out at me are to put the community admin stuff above the entry or to have a link to the community admin stuff appear somewhere in proximity to the post button. Not sure of the positioning tradeoffs, but just a thought.

[msilverstar]

there's no link for DW-specific HTML as there was on the older create entry page

the default date URL is a great idea, but it is not correct for PST, it says 12/31 when it is 12/30.

[chalcedony_starlings]

FWIW, what I'd really like is for “don't auto-format” to have an autodetect in itself. (I'm writing this here because the lack of it is the one critical thing keeping me off the new create-entry page.)

My use case is that what I want to output to my journal is correct-by-my-standards paragraph divisions in the output HTML, with exactly no “<br><br>” silliness. I'm okay typing these in myself, but then of course I have to turn off “auto-format”. The only way I can stop the march of the icky unsemantic line break tags if auto-format is on is by wrapping my EOLs in comments, or typing the entire thing on one input line…

But what would be really convenient for me is if it detected that I was inserting my own paragraph tags and turned itself off. I think it's a pretty safe assumption that within and between block elements people are manually inserting, the “auto-format” line breaks are undesired because they can just insert their own, but I guess there might be backcompat issues with this, or with the WYSIWYG editor which I've never tried. As a side effect, this would also save me having to click two times when leaving comments every time, because the “don't auto-format” checkbox doesn't show up in the quick-comment form, only on the full preview page…

(What would be even nicer is if the auto-format gave me nice clean HTML with auto-paragraph detection rather than icky line breaks. But that seems like even more work and risk.)

[chalcedony_starlings]

(Oh, right. I guess the incomplete handling of custom moods with preset mood icons was the other thing, maybe? I forget…)

[denise]

Yeah, that's a lot harder than it looks -- trying to parse HTML is really not an easy problem. We don't use the <br> tags because we think we're correct to do so, we do so because AUUUGH HTML PARSING

Beta Posts

[kemander]

Abhorrently slow response time; in fact, so slow it forgets what it was supposed to do and repeats a prior task in the space I've given it a different task to do. There also isn't any means provided to corral picture or image perimeters to a desired size, rather than the image being larger than the entire page or even my 19 inch monitor size.

I am using this on a Dell Inspiron 1545 laptop running on Windows 7 with all the latest updates installed automatically, using the Google Chrome browser, Version 71.0.3578.98 (Official Build) (64-bit).

Atta boys

[kemander]

I certainly hope that you keep working to fin the solutions for rich text/WYSIWYG and never give up until you've conquered the issues.

My Experience So Far

[kemander]

Has been pretty smooth sailing. A little brush-up was needed to recall some HTML issues, but it's always a good time for one to re-consolidate forgotten past. Your support has been tremendously helpful, for which I thank you all from the deepest abyss of my molten core; So, a huge Thank You for a great effort from you and your staff.

Kudos and Gratitude.

Kemander

[silverr]

JUST started poking at this; I realize that the feedback window might be past, but decided to toss comments up anyhow.

LOVING how much easier it is to edit and select tags, and change permissions!

SUGGESTION: I do like that the DELETE button has a larger buffer zone than previously! the only tweak I thought of was to make that button a distinct color (orange or red wouldbe great, though though I realize red is problemmatic or useless for those with visual issues.)

Finally, a small bug/visual glitch: When I first opened the window (desktop computer with large monitor, details below) a few days ago, the entry and display area for tags was nice and large. However, after experimenting with the "Display column next to main entry area" setting and trying to default to the original layout, the tags box remains determinedly small. Neither reset+refresh nor trying to drag the window width out with the half-saltine (see picture below) works. (Is this a "completely empty your browser cache" issue?)

Pictures after mucking with settings (different account, different browser, same computer):
https://i.imgur.com/GCIOFSq.png
https://i.imgur.com/xXyDoI5.png

Picture of how it looked by default: https://i.imgur.com/uM8xr09.png?3
(ETA: Also looks this way for the affected account if I log in with a different browser)

Windows 7 Home Premium + SP 1 (64bit)
Browser: FFox Quantum, up to date as of 4 Jan 2019 (no version given in About box!)
Browser display 1024 x 768 on a 1920 x 1200 monitor (text size 150% in Windows display options)
Addons: Acrobat, Kaspersky, Google Reverse Image Search

[denise]

Hmmm, that is weird. Does it still happen if you use the upper right hand collapse button in the Tags pane and then uncollapse it?

[silverr]

Yeah, I tried that too.

I tried Ctrl-F5 refresh as well, and also exiting the browser completely, but neither of those restore it.

I'm assuming that it's a FFox browser cache type thing, because if I log into the "silverr" account with either Chrome or Opera (which would be first access of that page for those browsers) my suppressed modules carry over, but I don't see the issue with the shrunken tag area:

https://i.imgur.com/ow1zKMM.png

[denise]

Yeah, that's deeply weird. Have you tried clearing browser cache? If that doesn't work, try restarting with extensions disabled.

[silverr]

1. Cleared all data for all sites containing "dreamwidth" -- no effect.

2a. Turned off all 4 extensions. Did not change Plugins settings.
https://i.imgur.com/Qyt9nTH.png
https://i.imgur.com/rVDy5iq.png


2B. Exited then restarted FFox. Problem persists.

https://i.imgur.com/F1RGHJB.png

[denise]

...huh, I am deeply confused at what could POSSIBLY causing this that wouldn't respond to one of those. 

One last thing: try disabling the panel in the settings, hard refresh, then re-enable it?

[silverr]

... by 'hard refresh' do you mean Ctrl-F5, or ...?

[denise]

Yeah, sorry!

[silverr]

np, that's waht I thought it meant but wanted to make sure

Also: Does DW cache data under any URL NOT containing the 'dreamm' string?