YOOtheme Pro is here! The best WordPress and Joomla theme. Learn more

Avatar brad.kaiser.43 asked

Is Yootheme PRO reliable for you? Not for me...

I really want to stick with Yootheme products because the designs are the best and I really love the 'idea' of what they're trying to do here.

But, we've now hit a full year since there was a reliably usable new template.

I'm leaving open a small chance that I am missing something, which is why I'm bringing up the topic.

Yootheme PRO is a new way of doing things and I'm willing to invest the time to learn a new system. But I can't be an ongoing beta tester while I'm trying to make a living.

When I'm doing work for clients, I can't afford to have a project take twice as long as it should because of unknown/unsolved reliability issues.

Both the Site Builder and the Page Builder regularly flake out on me.

Site Builder routinely gets into a situation where I can't save changes.

I can often save one change successfully, but if I want to go back in and make further changes, the changes will show up in the preview and it seems like I'm able to save the changes.

But then I look at the front end and the changes haven't taken effect.
Then I go back into the back end and the settings appear to be saved as expected, but the new preview shows the old stuff (not matching the indicated settings).
I can undo and redo the changes so the preview looks like I want it, and then save. But then the changes still don't take effect on the front end.

Page Builder routinely gets into situations where I can no longer open/edit a page in the Page Builder.

I'll get things started and then, at some point after I've made a few changes, the article will no longer open in the page builder. Just the error message to the effect of "Not available on this page. The builder can only be used on ..."

  • Most of the sites I've been trying to get going have been just Joomla 3.7.x and YooTheme PRO with no other extensions.
  • My session settings are mostly set to 360 and the problems crop up very quickly. Sessions are not timing out.
  • I'll periodically log out and log in again just to be doubly sure it's not a session issue.
  • I've tested multiple times on two hosts plus local (MAMP) environments on two different computers.
  • I've tested with Chrome, Safari, and Firefox (all up to date).
  • I've tested with multiple PHP versions (5.5.x, 5.6.x, 7.0.x, 7.1.x).
  • All caches are always off, except when I am messing around and try to turn a cache on, clear it, and then turn it off again.

So far, when things go wrong, the thing that seems to be a reliable fix is reinstalling the template. But it's only a short time fix – I'm not willing to get into a workflow that involves reinstalling the template three times per hour.

Is there something I should try that I didn't list above?
Or are a lot of people just putting up with the frequent bugs and glitches?

  • Joomla
  • General Question
  • YOOtheme Pro

Edited

13 Answers

1

Avatar erik Yootheme Online answered

Hi again!

Ok, new idea: There are two steps when saving changes in the styles. The first is saving the config in the database. The second is the actual request to create a new css file on the server. Both requests should be visible in the console if the Log XMLHttpRequests option is enabled.

Image

  • Red: This is the option that has to be enabled in the console to see the requests.
  • Blue: This is the first request saving the config in the database.
  • Green: This is the second request actually creating a new css file.

If we are lucky we might see if the second request works as expected, and if not why. If you click the second request once it appears in the console the XHR panel should open. If you click the last request there it should look like this:

Image

If something went wrong an error message should be there instead. And if there actually is an error message this should be the one that helps us solving your problem.

Cheers,
Erik

4

Avatar peter.russell.64 answered

Hi
I have only just bit the bullet and jumped in to see if I like the new environment and I must say, while it allows lots of styling adjustments to content, I am just not a fan of builders. This may change, as I will monitor the progress and re-enter when I see more stability.
The reason I have only just made the leap (and only to test off-line), missing critical functionality that is only just getting there and feedback like this, plus the rate/frequency of fixes. Fixes can be both good and bad, good that developers are active, and yes, more preferable than fixes that are slow or just dry up. But, until I see components like UIKit 3 (beta 26!) become General Release, then I see a beta product. And beta is what Pro is, especially when you have to wait 10 months for a Lightbox function or a Slideshow!
And as you say Brad, we want to stay with Yootheme, but it appears of late, decisions on products like Widgetkit 1 to 2 (no migration path) and the Icons subscription going nowhere and that Zoo has become pretty much static (until your recent announcement), does not endear you.
Cheers Peter

1

Avatar brad.kaiser.43 answered

Hi Erik,

Thanks so much!

I'm cautiously optimistic that this is solved(ish)!

What I'm seeing while watching the console for these messages –
• I make some changes and click the blue Save button
• The request that ends in customizer shows up right away
• The request that ends in styles is slightly delayed, generally taking somewhere around 2-3 seconds, but sometimes taking 8+ seconds to appear.
• If I assume the save is successful and click the Close button before the styles request has happened, then nothing happens.
• If I wait for that second request, even it if takes 8 or 10 seconds, then everything goes as expected.

Until I see the problem come up again, I'm assuming this is the issue and I can avoid it.

I guess my problem is making small changes and moving too quickly.
I wonder if there is a possibility for a progress indicator on the Blue Save button. So, rather than the blue button just going away as soon as the database save has happened, there would be some kind of indicator until BOTH saves/requests have happened...?

I'll test a little more. In the mean time, I'll accept your answer.
Thanks again!

Edited

1

Avatar vladimir.eliseev answered

I have thorough read this topic because I have the same issues as described here...
And here is the real problem - I changed some values and go father too quick. First request is come fast but for the second we need to wait some time.
And we really need progress bar or something else similar to understand that request was fulfilled.

Please help us!

0

Avatar erik Yootheme Online answered

Hi brad.kaiser.43!

First of all: The problems you describe are definitely not normal and not something we and other users encounter daily. Here in the YOOtheme office we work with Pro every day, so problems like yours would definitely be unacceptable for us.

But what has indeed happened is users reporting problems similar to yours and after investigations on our side we have come up with a possible solution: In the Session Settings in the Joomla Global Configuration the Session Handler needs to be set to "Database" for YOOtheme Pro to work as expected.

Image

Could you please check if setting the handler to database solves the problems or at least part of it? And please let us know if this helps, because if it does this might be a big help for most users encountering similar issues.

Cheers,
Erik

0

Avatar brad.kaiser.43 answered

Hi erik!

Thanks so much for your reply.

I feel like, at some point, I've seen someone around here suggest that the session handler should be set to file/PHP rather than database so, indeed, one of the sites I've been testing with was set to PHP.

I believe default installations are set to Database, so I did change it to PHP only in an effort to troubleshoot my issues.

I've now set Session Settings back to Database with a long Session Lifetime.

I'm still seeing similar issues.

Since the change this morning, I have not yet had any new trouble with the page builder.

But...
In the Site builder, I am seeing the same thing.
I went in and made a couple tweaks. I saved the changed and they took effect on the front end.

I then went back into the Site Builder to make a few more tweaks.
• The changes seemed to take effect in the preview
• I saved the changes and closed out of the Site Builder
• The changes weren't reflected on the front end
• I went back into the Site Builder and found...
• The tweaks I made still show in the saved settings, but the preview is now back to the old settings.

If you care to confirm what I'm seeing, I've added the site login info to the original post.

If you go to the site builder > Style > Global...

You can see that I've tweaked the link color and most of the background colors, but those changes are not reflected on the front end or in the Preview > Preview all UI elements.

Image

Based on my recent experience, I expect that if I keep messing with this and try repeatedly I could get the new setting to stick.

It almost feels like there is a cache somewhere, but there's nothing I can see in Joomla or with my host.
And I have nothing remotely similar happening if I use a Warp 7 template and make frequent tweaks.

Thanks again for any input.

I'm rooting for this to be a thing of the past, but... right now it's a real problem.

Edited

0

Avatar erik Yootheme Online answered

Hi again,

thanks for the feedback. :) Good to hear that the Page Builder behaviour has improved, sorry to hear there are still issues. Yes, we would like to take a first-hand look at your problem and thank you for the login data. But either the username or the password seem to be not correct. Could you please try to log in with them and change them if needed? Thanks!

Cheers,
Erik

Edit: By the way, do you use RSFirewall?

Edited

0

Avatar brad.kaiser.43 answered

Sorry... Password fixed.
Should work now.

I don't use RSFirewall. No extra extensions installed with this one yet.

Host is Siteground. All their extra caches are turned off, but not sure if they have some other security feature that has some effect.

Although, as I pointed out, I've had similar issues on localhost installations.

Edited

0

Avatar erik Yootheme Online answered

Thanks for the login data correction! Well, the problem is strange indeed. It looks like the changes are getting saved in the database, but the css itself is not re-compiled according to those changes. Could you please keep a look on your console in the dev tools while saving changes? With a bit of look an error gets thrown there at the moment you save that could tell us why the save is not applied.

Edited

0

Avatar brad.kaiser.43 answered

Thanks for looking, erik.

Im not seeing anything obvious in the console.

Changes still aren't taking effect most of the time, but the only error/warning I've seen so far in the console is:

JQMIGRATE: Migrate is installed, version 1.4.1  jquery-migrate.min.js:2:542  
Use of getAttributeNode() is deprecated. Use getAttribute() instead.
0

Avatar erik Yootheme Online answered

Hi brad.kaiser.43,

thanks for your feedback! To test if saving works in general we dared to hit the save button - and all the changes you entered in the style customizer got applied to the frontend just like expected. So for us it is working, which makes the issue even more weird ...

Could you please try - as weird as it may sound - editing the style and saving it from another computer to see if that works?

Cheers,
Erik

Edited

0

Avatar brad.kaiser.43 answered

Hi Erik,

Thanks so much for following up.
Glad you were willing to test a little bit. Feel free!

I did originally test on multiple computers and browsers before I posted.

I did test on a second computer again this morning.

Interesting results...

On each computer, I was able to make some changes and save them successfully, ONCE.
On each computer, when I went back in and tried to make another change, the changes did NOT take effect in the front end.

This pattern has been pretty standard. Usually, the first time I try to save a change in a given day, it works out. It's the subsequent changes that fail.

Could it still be somehow related to sessions, despite the fact that I have a long session setting and set to database, as you asked?

#

Argument against it being related to sessions –
Getting changes successfully applied seams random.

This morning, I was able to get a new change to take effect on the fourth try, undoing the setting, redoing it, and saving.
As far as I'm aware, I changed nothing from the second and third tries (when it didn't work) to the fourth try (when it did).

Thanks!
Brad

Know someone who can answer? Share a link to this question via email or twitter.