Re: WYSIWYG Web Builder 14.4.0 Crack Keygen Is HERE! [Latest]
Violetta Wagganer
whereas doing the same thing in Firefox just opens the editor as expected. Collaborative editing does not work though. I disabled all referrer settings in nginx, but that does not help. Might this be related to https?
You seem to be having a different problem here, both your users see an editor but one of them cannot connect to the collaborative session. If the second user that arrived on the edit URL of that page did not see the locked page message, then my code above worked, provided that you have the right realtime extension installed (see below).
I agree, different topic. Just one remark: We faced a connectivity issue at first as well with Chrome and Edge browser. After adding the redirect in nginx mentioned here Realtime WYSIWYG Editor Page locked - #2 by CaS4YumEE35lJo1UNAhr it worked.
Before the adoption of WYSIWYG techniques, text appeared in editors using the system standard typeface and style with little indication of layout (margins, spacing, etc.). Users were required to enter special non-printing control codes (now referred to as markup code tags) to indicate that some text should be in boldface, italics, or a different typeface or size. In this environment there was very little distinction between text editors and word processors.
I'm still learning the ropes when it comes to JavaScript and one of the issues which is causing me the most problems is understanding the caret position. Currently I'm writing a reference form for a wiki ( :Wikia.js/referenceForm.js) and have it working for the source code editor for the wiki, but not the WYSIWYG editor (Visual Editor). I was wondering if anyone here knew how to get the caret position and then paste text for the iframe in which the edit content sits?
The WYSIWYG editor can be seen here: =edit (edit whilst not logged in for those with Wikia accounts and have Visual set to off). The method I've been using the get the content and attempt to paste at the caret is this:
I have seen many threads complaining about the terrible builder experience, often without specific details on the issues the user happens to be facing. Each time this happens, the CC team replies asking what, specifically, isn't working for the user. In almost any other SAAS product, I would consider this response fair, but in the case of CC, the builder is so abysmal that I doubt most users even know where to start, and I wonder whether CC even uses their own software at all, because I have yet to see the experience improve by an inch. Here's what CC needs to understand; at least for me, making email comms is a small part of my responsibilities. I have so many other things to do, that even when I encounter a bug, I just press on and work around it, because the task at hand just needs to get done as quickly as possible. Here's the takeaway from that: when a user goes through the trouble to report a bug, contact cx service, or complain, it's because the issues have come to a head. So, here we are. Here is a (far from comprehensive) list of the issues I face every week, three times a week, when trying to build a simple campaign.
The CC interface is borderline unusable on normal, office-grade hardware. Before I got a serious upgrade on my company issued laptop for video work, I used a perfectly serviceable, new Lenovo ThinkPad, with decent enough specs for office work. When using the CC builder, however, my machine would absolutely chug, fans going like jet engines. UI elements would disappear as I dragged them, the page would scroll at what felt like 1 FPS, and a single newsletter could take me literal HOURS. This was not a beefy PC, but it ran the entire Adobe CC suite just fine. It should not take a video editing workstation to make a newsletter. Stop it.
Sometimes, for no discernible reason at all, changing the color of one item will change the color of another one somewhere else on the page. As an example, changing the text color of a title somewhere might change the background color of a text block elsewhere. There is no rhyme or reason to this; it just happens sometimes. Sometimes, random color changes even seem to happen when a campaign looks fine, is saved and re-opened, or worse, sent.
Sometimes, when you place an image placeholder into the campaign and double click on it, the media picker modal doesn't open, so you can't add an image. This can *sometimes* be circumvented by dragging an image from your pc onto the placeholder, and then double clicking to change the image. Sometimes. My campaigns are newsletters about the membership of the org I work for. Each and every text block contains at least one image, usually of the member. These are all saved in the media library, but 99% of the time, double clicking on the placeholder doesn't allow me to select an image. To save time, I literally have a folder full of pictures of kittens, SPECIFICALLY FOR THIS ISSUE, that I can drag and drop onto the image placeholders. This inevitably leads to the CC media library, and its limited space, being filled with duplicate images of kittens. There are hundreds at this point. Why not just use the final image, you ask? Well, as I mentioned, I work for a membership org. We have over 500 members, and finding pictures can be difficult using windows explorer. This is why we have them all organized in the CC media library. Shame it doesn't work.
What's the single most important feature of a modern WYSIWYG editor? You guessed it, the ability to drag and drop items. You know, the ability that makes even not so tech literate users feel like they have a chance at putting something together that kind of, almost, maybe feels like a professional did it. Yea, the drag and drop function in CC is beyond abysmal. There are two ways to do it:
Number two is the one that sucks. I don't have the time to spell out the shortcomings of this feature; truly, they are profound. If anyone over at CC is scratching their heads at this one, they have never used the feature in a campaign taller than their viewport. Try it, all of you. I want every single employee at CC to try and organize a newsletter twice the height of their viewport by dragging and dropping this way. Here's an idea: every time an element lands somewhere you don't want it to, take a shot!
Anyway, that's all I can think of right now. I'm sure there are more annoyances that I routinely use cumbersome workarounds for. If I were in a corner-office with a view at CC, this is what I'd do: I'd scrap whatever hellish, Ramos -Gin-Fizz-esque, teetering stack of frameworks comprises the builder, and I'd start again, fresh, with plain old vanilla javascript (or at least a compiling library like svelte), that is nice and fast, and where fixing bugs doesn't require devs to wade into a cesspit of endless dependencies. You could even use web components, they don't need a framework at all! Then, I'd test the hell out of it. I'd test it on windows, mac, linux, android, ios, firefox, safari, chrome, edge... I'd even test it on opera. My experience with CC has really reached a head. Not only have I been actively researching other options, I literally started building an email generator with Jekyll (that unfortunately went down with the ship on a dead hard drive) so that I can just write my newsletters in markdown and copy and paste the generated HTML. It's that bad. Anyway, my org will probably be long done with this platform by the time anything gets better at CC, but I just had to get this out there in the hopes that someones experience with the product, some day, doesn't impede their ability to do literally anything else in an entire workday besides make a newsletter.
I start working on something, click over to my email for just a minute to grab a bit of copy or an image to use and by the time I tab back over to CC I'm greeted with. "Hi there! While you were gone, we may have ended your session for security. If you're done, great. Otherwise, click below. (You might have to log back in.)"
There should be a team attempting to replicate these issues and fix them. Serving as Constant Contact's QC is not what my organization pays for every month. Happy to send GIFs of some of these issues privately.
As for the feedback thread regarding timeouts, I left a comment there back in July that went unanswered. And hey, I get that you guys can't get to every single thing that folks complain about on here, but if something is a fundamental issue, maybe it shouldn't be a popularity contest to get it fixed. Maybe pick the feature requests that would fix a glaring bug or make your customers' lives easier.
Very eloquent presentation of many problems I have experienced. To #3, the line-height bug, I would add that, even though you can specify line height in any block you are working in, Whatever you specify is applied to all the text blocks, so you can't make a block of test stand out as more prominent by adding greater line height. Plus there could be a few more choices.
Haha no one is going to kill you for wanting a feature I must say here's another vote for the Rich Markdown plugin. It does just about everything you asked for in your post, plus you can tweak it even further straight from CSS (there are quite a few posts here in this forum on how to do that).
What the Rich Markdown plugin does is put css clases around the md tokens. This allows you to use css to de-emphasize the tokens and sometimes even replace them. We've now figured out how to turn the *'s that make lists into real dots using css while still having the characters be there as markdown.
Similar with * for strong. With the Rich Markdown plugin you can make those marks a light gray so they don't stick out, but when you want to edit them, you can see where they are. But if you make them disappear then they are much harder to work with.
Just converting the openings and closings of the html tags before textile.js does its job and sends the content to the wysiwyg box, seems enough for HTML to be considered just the text to be displayed in the wysiwyg box. And then we can type any HTML or TXP tag freely in both boxes. Even . Look.
aa06259810