- (response to another post)
- Pro Creates CSS Bugs
- PRO WON’T SAVE ANY changes to some pre-existing pages,
- UI suggestions,
- (frustration),
- Pro conflict with Redirection Plugin
(RE: a post where Pro dismisses a request to fix HTML/CSS bugs Pro introduces because the pages render)
Especially, since in so many of their posts THEY tell us, that if the page does not save it probably because WE have invalid HTML.
And then they END the support thread. Like that actually answered anything, or helped anyone fix an issue.
So for PRO to hypocritically, purposefully, leave bad HTML, that THEY generate, and we HAVE NO WAY OF FIXING, while blaming PRO Refusing to SAVE Pages on US - OUR BAD HTML (when they actually have NO evidence to even make that assumption), is a deflection, and a slap in the face.
I found additional errors in the HTML they generate (namely, you CANNOT have a zero border-radius. You MUST leave border-radius ON, AND set all sides to something greater than 0. Else it writes out invalid CSS (border-radius: !0px; or border-radius: !0, 0px, 0px, 0px).
The trouble is I ran into this while trying to find my own HTML errors.
This was an extra difficult find, since it is part of a heading, not part of the page itself.
I do not know if the same bug persists outside of a BAR, used in Header files.
There are additional items that W3 Validator indicates, such as Pro createing links without an href or role, and a few others, however I did not see these show up as ERRORS in my browser DEV tools, so I am not reporting those. Also the beta HTML5 version of their validator did not report these items, so :shrug:).
Serious issue is that some OLD pages that previously were saved under an old version, NOW CANNOT BE EDITED AT ALL. They simply refuse to save. I cannot add a single letter of text. I cannot DELETE OR FIX invalid html (such as an improperly closed html tag, or html tags that are improperly nested, or add an id, or remove an id, or remove a duplicate id, or fix an “1fr 150px 1fr” grid definition that outputs to CSS as “1fr150px1fr” (because I added an invisible row/entry using the gear button of “Double Click to edit”, since the UI gives no hints on how to do so. Well, although it looked fine (at least in prior renders) Pro (currently - dunno if it always did) strips white space surrounding that invalid entry. So I found this, “fixed” it, but, again I cannot SAVE.
IF the issues SO MANY PEOPLE are having with saving pages that were created prior to a recent update is BECAUSE there is invalid HTML…
THEY better NOT output invalid HTML !!!
But this issue goes far beyond that.
PRIOR versions of Pro SAVED the page AS IS to begin with.
But Now, NOTHING can be saved. So NOTHING CAN BE FIXED.
The Conditions allowing a SAVE to take place has CHANGED, and WE HAVE NO RECOURSE.
POTENTIALLY ALL WORK DONE prior is subject to this GREVIOUS BREAKING change in THEIR coding.
WE have ZERO CONTROL over this.
We cannot FIX ANYTHING. OUR WORK is DESTROYED by this BREAKING BUG.
There is NO way to import parts of these pages bit by bit into a new one.
We cannot even SAVE a single ELEMENT as a PRESET or Any Container as a TEMPLATE !
And the nature of this builder is that we CANNOT ACCESS OUR OWN DATA directly. Every bit of text, every url, every bit of HTML (well most, I directly type html into some of the builder elements, such as Text Element, and Raw Elements directly.
We cannot even SEE an image URL input via the Image Element: Clicking the box DELETES THE IMAGE URL! (GRRR!!! MASSIVE PET PEVE - we SHOULD be able to OPEN it to see/edit the Link we initially input. By deleting it, we cannot use it as a reference to copy/paste all/part of that url. We cannot even browse the directory to see/select a different image in the same directory (we loose directory reference too, we cannot even correct a SPELLING error if we input the URL directly. (And personally, I HATE that using the Media Library inputs the link using the FULL site url. I WANT ALL my image urls to use Site RELATIVE links. That makes my life SO MUCH EASIER when copying/porting pages/site/code between development servers and/or Live servers!)
But I digress…
We NEED access to revert to a previous version SO WE CAN ACCESS OUR OWN PAGES.
Or they need to return the ability to save, even if there is invalid HTML.
Or they need to fix whatever the NEW underlying ISSUE IS.
And they CANNOT chastise us for invalid html, while THEY write invalid HTML.
HOW CAN WE EVEN CHECK OUR HTML without SAVING and running the page through a validator ??
How can we even see our find lurking errors??
Their CSS classes are not created until SAVE or RENDER happens.
So while I can run a saved page through a validator, none the Pro CSS classes in the output pages do not EVEN EXIST (they are not named anyway) when we are IN Pro. FINDING the element that created some invalid CSS or some invalid HTML can take hours to identify.
Using Pro is is MUCH MUCH more difficult to find errors than using the old style WP editor. There ALL HTML AND PAGE DATA is in one place: Copy Paste. With Pro everything is buried deep in various builder elements. And there is no way to reverse engineer an element’s id or class back to the exact element in builder that it references. Finding bugs, and reverse-engineering where those bugs lie is infinitely more difficult when using Pro.
WE NEED MORE FEEDBACK than “UH OH, FAILED TO SAVE!”.
Seriously? If you refuse to save, you MUST give us HINTS.
Especially when the same pages have saved for months.
These are NOT NEW ERRORS that WE JUST introduced causing failure to save.
If that were the case, we could make 1 change, attempt save. If it fails, we know exactly where to look, and can fix immediately. Especially if you give us a clue.
No, you instead have locked us out of pre-existing pages. NO Way to Fix or Edit them. EVER.
And apparently you have no intentions of addressing this issue.
And honestly, I do not know if the FAILURE to SAVE is a RESULT of my HTML and typos.
For all I know it is a completely unrelated insidious BUG you recently introduced, and are NOT LOOKING HARD ENOUGH to FIND!
And if the failure to save is a result of our own typos,
YOU NEED TO UNLOCK YOUR NEW BUG that refuses to let us CORRECT THEM.
YOU ARE DISMISSING US.
YOU ARE NOT TRYING HARD ENOUGH.
Another Issue I have found in the new version, on a page that will not allow ANY changes to be made to it:
Several elements indicate that there are “ATTRIBUTES” applied.
But I never added attributes.
I cannot find them listed on the “Customize” section.
There is NOTHING in any of the “Customize” fields on these erroneously tagged items.
WHERE IS PRO getting the idea that there are attributes applied.
How can I remove them?
How can I remove what I do not see.
How can I SAVE anyway?
I cannot edit these elements.
I cannot DELETE these elements, even.
(Technically, I can delete just fine. But it is useless if Pro refuses to save).
Because Pro REFUSES to SAVE ANY changes to this page.
Is this the result of some internal Pro bug? Or is is some “safety feature” you introduced? Or the reslut of your own broken CSS/HTML? Is that what is preventing me from saving? Even if it is my own typos or invalid HTML…
Something YOU changed in YOUR code, has now locked us out of much of OUR PREXISTING Work, CREATED IN PRO.
:
BTW, UI request: he text that states there is an attribute, or breakpoint, should link to that setting!
Id, Classes, Breakpoints really need to be made front and center, have their settings directly visible,
and have more direct access.
This is especially necessary when troubleshooting.
- Breakpoints (or even searching visible page elements for a typo say inside a text or image url. - clicking on potential culprits is dependent on them being visible. doing this 5 times duplicates checking any element that is visible on more than 1 size. Clicking on Every Element in the entire element tree ensures everything es checked, but unnecessarily opens a ton of elements that are irrelevant.
- id, as only 1 they must be unique to pages, and a copy or a template can unwittingly create duplicates. being able to directly see every element would be useful (even HIDDEN ones - sometimes we hide an element from ALL breakpoints, when testing out different versions.)
Finally, there is an insidious plugin conflict. If Redirection plugin is active, PRO FALSELY states the page was saved, when in fact it WAS NOT.
So if Redirection plugin is INACTIVE, Pro Accurately gives the Toast Message: "“Uh Oh,…”, and the Save button remains orange.
But if Redirection is ACTIVE, Pro FALSELY gives the Toast Message “Awesome…”, and the Save button turns Green.
The fact that some pages CANNOT BE EDITED AT ALL, after some recent Pro updates is DEVESTATINGLY HORRIBLE enough. (and no the result of any 3rd plugin.)
But, when Pro falsely gives incorrect feedback, this becomes insidiously worse.
It seems that false feedback may be the result of a PLUGIN conflict. Or a combination of conflicts.
(and unlikely to be your fault per se, however it is important to look into this and see if a resolution can be found. Redirection is an important, and popular plugin. Having accurate information about whether or not our edits have been saved is crucial.)
I’ve spend days, weeks on these issues. Beyond frustrated. 
Starting over is NOT an option !
I am BEGGING PRO for your HELP on the issue that YOU INTRODUCED.
On the behalf of others.
And for myself !!!
TAKE THIS SERIOUSLY !!
