Forum Replies Created
-
Posts
-
See the link below Rikard. Thanks for checking. I did not have to do the same thing for any other Siteground hosted sites, just this one block of 10.
I still have the original distribution I used for the manual update on the first go-around which, as I said, had the 4.6.1 changelog included. If you want me to send to you so you can take a look at it, just shoot me an email address and I’ll upload via WeTransfer for you. That’s about the best I can do since it is fixed already on all my sites.
That is correct and I am absolutely certain that I used the 4.6.1 release since I read the changelog included in the distribution. As always, I created a backup of my current Enfold folder then replace it with the new one. I ended up having to update via the Enfold update now button and perform the update process before it read the version number properly.
Borderline irresponsibility. I had to go back into all 10 sites and update to 4.6.1 through the Enfold Update Theme panel even though I manually updated via FTP yesterday. You really need to do something about this, your current reliability is nearing rookie-ish.
Did you make MORE changes and re-release to Envato after the first time?
We are good now Rikard, no further issue. Thanks again. Günter explained it all at the link below.
https://kriesi.at/support/topic/4-6-update-doesnt-recognize-old-custom-css-class/#post-1133483
I am fine with these options to re-integrate the functionality – SO LONG AS WE KNOW ABOUT THEM upon release.
Thanks for the information Günter, this explains it all. BTW, this information should have been detailed in the changelog so we knew what options we had instead of bothering you folks.
Rikard,
While we all do appreciate the assistance you folks render, it might be a good idea to let us know what the exact global fix is for all of us who have countless custom css classes active within our built websites. I, for one, used this feature regularly for various purposes and have a huge problem with the seeming one-sided decision to drop this. If I am incorrect in what I see going on here, kindly correct me. What are we supposed to use now?Thank you Rikard, issue fixed.
Can you explain the rationale behind changing the DeveloperID functionality? I see your javascript is targeting the page template and not the target item as we previously had done.
Hi Rikard, thanks for the effort but that did not correct the problem. Content on that page is still vertically aligned middle. See below in the snippet from the browser console. Flushed cache and disabled joining and compression.
.avia-section.av-minimum-height .container .content {
display: table-cell;
vertical-align: middle;
height: 100%;
float: none!important;Please refer to other folks issues within the thread below. I am reasonably sure these issues are inter-related.
https://kriesi.at/support/topic/4-6-update-doesnt-recognize-old-custom-css-class/#post-1132942
Rikard, I opened a different thread already (listed above in my post) and no one from Support replied to the very simple request. In my case I have a simple landing page in use for a home page – no need for all this login stuff. The content was aligned to the top using the quick css below. After the update, the custom class was no longer listed but the quick css was retained. So I re-entered the custom class name in the color section as it was before. No longer works. The page is being forced to align middle. When I use Developer Tools to change the value of the alignment live in the browser, it looks the way it’s supposed to.
.landing_desktop.av-minimum-height .container .content { vertical-align: top !important; }
Support Team?? Are you there?? This is a simple question. Just trying to get my content loaded at the top of a page.
I pretty much have the same problem referenced below:
https://kriesi.at/support/topic/vertical-alignment-issue-on-simple-landing-page/For those of us who have numerous custom classes, this is ridiculous.
I’ve had success with a paid plugin named CleanTalk. I use it for all commercial sites I develop and it incorporates easily.
Thanks Rikard. As it turns out, it is not recommended to add titles to links within the site OTHER THAN for menu items, which we have done.
Thanks again.
That’s pretty unbelievable give the level of complexity built into Enfold. I think it’s important to have to ultimately deal with some of the issues surrounding ADA compliant web sites.
Try this page:
Mike, thanks for the great answer! Hope you can help on my other issue related to body copy links, which is => How do we assign a Title Attribute to a link? There is no such option in the Advanced Editor as far as I can see.
Good question Sachs, I was about to ask the same thing as we are dealing with cleaning things up for a self-imposed accessibility audit. Same goes for menu items.
Following up on this and it seems the Poptin exit intent window was creating the issue. Thanks for everyone’s time and efforts.
Okay, so here goes with the details. We have several sites all built using Enfold. All have Google Analytics tracking and Google Tag Manager installed. On two of the web sites we use Poptin, which we use as an exit-intent CRM tool. These two sites are generating significant GA javascript error events in Analytics. One is a low traffic site where we do not spend much on monthly advertising, the other is fairly high volume and we spend a lot on Google paid search – to the tune of $30,000/month. So, this is pretty important we find out why.
We initially were concerned with Enfold’s performance merging of JS and CSS files so they were both turned off.
Below are the URLs and I’ve submitted the GA user login information with Read & Analyze permissions in the private content section.
Thanks for your input Victoria. Please give me some time to work with Siteground on this issue. I’ll be back to you.
This was specifically being caused by Enfold’s Performance compression of both CSS & Javascript files. The file merge and compression was throwing all kinds of error events. As soon as I deactivated both, they stopped dead.
Rikard, thanks for replying. I can certainly wait until next week for it. I’m sure it’ll be tested against WP5.2 anyway so the wait will be just fine.
