Forum Replies Created

Viewing 15 replies - 76 through 90 (of 470 total)
  • Thread Starter Abigailm

    (@abigailm)

    OK, I created a cloned staging site and upgraded there (from 4.0.5 to 4.0.6) and it looks like features that are no longer available in 4.0.5 are displaying correctly.

    I have also reviewed the information at https://theme4press.com/evolve-multipurpose-wordpress-theme/

    Am I correct in these assumptions:

    1) Fonts: From version 4.0.6 on, there are only 3 Google Fonts that may be selected from customizer. However, for sites being upgraded from earlier 4x versions, the previous font selections will be preserved? (However, they may be lost if the site administrator makes other changes via customizer and does a save which overrides the previous selection).

    2) Slider: The number of slides available in the free version is now restricted. So, for example, I have the Bootstrap slider with 3 slides — but going forward, the customizer can only allow selection of 2 slides. However, with an upgrade the database selection from the previous version is preserved, so my 3rd slide will still be enabled — but I would not be able to use the customizer to modify or change that slide going forward using the free version?

    Am I correct that there is also no longer a native way to export theme settings? (I can’t find it as an option anymore in the customizers).

    Thread Starter Abigailm

    (@abigailm)

    Is there any change to the bootstrap slider?

    Does decrease in font families mean that a font I had previously specified might now be discontinued?

    Is there a place where you have posted a detailed list of which features (including fonts) are no longer supported?

    I appreciate all of the work you do to keep Evolve consistently updated, but it is a huge problem for those of us with developed sites when updates change the function of appearance of our sites– so I really would appreciate specific information ahead of time. For me, it is the difference between an update process that takes a few minutes and one that requires many hours of my time on a live site with critical functions.

    Thread Starter Abigailm

    (@abigailm)

    Thank you!

    Thread Starter Abigailm

    (@abigailm)

    No solution.

    This has now been discussed extensively on several separate threads on github. No resolution and it is frustrating there because the issue has been sidetracked into exploring specific plugin conflicts– which are real, but many users like myself report the problem with all plugins disabled

    However, for me, I have learned that if I do a hard refresh in my browser, I will see the preview — so I’ve just gotten into the habit of doing that each time. (Edit page, click preview — then when the preview opens up in the second tab, do a hard refresh). So it’s an annoyance, but I am able to preview pages before publishing with that extra step added in.

    I also know from the git hub discussion that it is a common but not universal glitch or bug with established websites following upgrade to WordPress 5x. I have not seen reports of the problem for new WordPress installations. It has proved difficult to replicate — those of us who have multiple sites on one server may see the problem on many or all of our sites, whereas people testing on other servers simply cannot replicate the problem. Without being able to reliably replicate, it’s definitely hard to debug.

    Thread Starter Abigailm

    (@abigailm)

    Okay, then you have the same problem that I do. The user reported the problem both on Safari in a Mac laptop and on her iPhone — and that the problem was resolved when I disabled the reveal effect. So, for now, I just won’t use it.

    Thanks anyway.

    Thread Starter Abigailm

    (@abigailm)

    This seems to be the same issue reported in GitHub here – https://github.com/WordPress/gutenberg/issues/12617 – so I’ll follow up in GitHub.

    Thread Starter Abigailm

    (@abigailm)

    As I said, when I do not use Health Check but instead disable ALL plugins and swap out to TwentyNineteen the problem persists. So it is NOT the theme and not any of the plugins.

    Since it works in Health Check but not on the actual site, there must be something in the difference of how Health Check functions compared to the live site. Maybe something in .htaccess files?

    I have one site on the same server that does not have the issue, but for most of my sites I have the same problem.

    Thread Starter Abigailm

    (@abigailm)

    Thanks for that suggestion, but that didn’t help.

    In Health Check troubleshooting mode, there is no problem and the preview function works fine, even with all plugins enabled and using the current theme.

    However, with Health Check disabled — the problem persists, even with the TwentyNineteen theme activated and all plugins disabled.

    I’m seeing the same problem.

    I had similar problems, also running PHP 7.2. (500 error bringing down site as soon as the updated plugin was installed)

    I opened a support ticket but did not get a response.

    Here’s a sample from my error logs:

    PHP Fatal error:  Uncaught RuntimeException: Error while making  'tickets-plus.main': 'tickets-plus.main' is not a bound alias or an existing class. in .../plugins/event-tickets/common/vendor/lucatume/di52/src/tad/DI52/Container.php:348
    Stack trace:
    #0 ..../plugins/event-tickets/common/vendor/lucatume/di52/src/tad/DI52/Container.php(281): tad_DI52_Container->resolve('tickets-plus.ma...')
    #1 ..../plugins/event-tickets/common/src/Tribe/Container.php(176): tad_DI52_Container->make('tickets-plus.ma...')
    #2 ..../plugins/event-tickets-plus/src/Tribe/Main.php(90): tribe('tickets-plus.ma...')
    #3 ..../themes/theme-child/functions.php(146): Tribe__Tickets_Plus__Main::instance()
    #4 ..../wp-includes/class-wp-hook.php(286): tribe_ in /..../plugins/event-tickets/common/vendor/lucatume/di52/src/tad/DI52/Container.php on line 348

    The function in my installation (Stack Trace #3) was:

    // Hide QR Code in Tickets
    
    function tribe_neuter_qr () {
    	if ( class_exists( 'Tribe__Tickets_Plus__Main' ) ) {
    		$qr_class = Tribe__Tickets_Plus__Main::instance()->qr();
    		remove_action( 'tribe_tickets_ticket_email_ticket_bottom', array( $qr_class, 'inject_qr' ) );
    	}
    }
    add_action( 'init', 'tribe_neuter_qr', 10 );

    I did not have an opportunity to test with that function removed; I needed to get the site back up and running so I just disabled the plugin and rolled back.

    @dohadudes – If you have FTP access, there are two relatively easy ways you can fix this.

    1) First way

    Go to FTP and navigate to the wp-content/themes/ directory of your installation.

    In that folder, you should also see a subdirectory called evolve – that is the evolve theme.

    Do you also see another subdirectory with a different theme name? Ideally you should see something like twentyseventeen or twentysixteen (one of the default themes that come with a wordpress installation).

    If so, in FTP, change the NAME of evolve — you can just change it to “evolveX” for now. Any name other than “evolve” will do.

    That will cause your wordpress installation to revert to the default theme (let’s say twentyseventeen). That’s because it won’t be able to find “evolve” with the changed name.

    Your site should be up and running now, but with the different, default theme.

    Now log into the site, leaving the different theme active.

    Go back to FTP and change the “evolve” directory back to what it was. Don’t worry, it won’t break your site, because your site is now running twentyseventeen or whatever other theme it has reverted to.

    Now, while you are still running the alternate theme, go ahead and complete the evolve upgrade. You should be able to navigate to “Appearance/themes” in the WP Dashboard and see the option to update evolve there.

    Go ahead and update; and then once it is updated, you can reactivate evolve.

    2) Second way

    Leave everything in place, but via FTP navigate to find the file at
    /wp-content/themes/evolve/inc/admin/customizer/customizer.php

    Open that file, and at line #1142, make this change:
    change:

    evolve_call_customize_register();

    to:

    if ( is_customize_preview() ) {
        evolve_call_customize_register();
    }

    That is the line that fixes the code that is breaking your site, so correcting that will bring the site back up with evolve still running.

    Once you do that you should go ahead and do the update to version 3.9.8 from your wp dashboard.

    • This reply was modified 7 years, 9 months ago by Abigailm.
    • This reply was modified 7 years, 9 months ago by Abigailm.
    • This reply was modified 7 years, 9 months ago by Abigailm.
    • This reply was modified 7 years, 9 months ago by Abigailm.
    Thread Starter Abigailm

    (@abigailm)

    I’d add that I’ve now disabled the hover effect on the images via customizer, so you won’t see that anymore on this page, but it is still a problem that they link to the image rather than the page.

    I am running a child theme, so if this intended behavior rather than a glitch, I could create a separate archive.php page — if you can give me the modification it would need to function as I would like.

    • This reply was modified 7 years, 9 months ago by Abigailm.

    I’m running 3.9.8 now and still have the featured image issue. As I noted originally, it is on an archive page, not a blog page. So it is a page that pulls up a category of pages that in turn are custom post types. I’m going to start a separate thread on this, as maybe it is a slightly different issue.

    • This reply was modified 7 years, 9 months ago by Abigailm.

    OK, I tested for you.

    Running PHP 7.2.9. (PHP-FPM)

    This seems to do the trick on my system… but I didn’t experience the 500 error others complained about. Instead, when I ran the upgrade, everything looked fine, front & back, but the “Kirki” not found fatal error was registered in my logs.

    I added the line of code at #1142 and the error was generated one more time a few seconds later, but no more after that. I’ve been starting, navigating, and exiting the customizer, so maybe the first error was just because of a cached page that needed to be refreshed. In any case, no more errors being logged, and no evident problems anywhere else on my site. (But then, unlike others… my site didn’t break in the first place… I wouldn’t have known there was a problem but for the fact that I was testing for you and closely watching the error log each step of the way).

    So I think you are probably on the right track.

    Do you have FTP access?

    If you have FTP access & there is also a standard WP theme in the directory (example, Twenty Seventeen) ..then you could just go in via FTP and change the name of the evolve folder to anything else (like, evolve-broken) — that would cause the WP installation to automatically revert to the other theme, and then you should have backend access restored.

    (There are other options as well, but it depends on hosting setup.)

Viewing 15 replies - 76 through 90 (of 470 total)