ukeboyska

I’ve narrowed down the issue. It starts occuring in 3.2.3.

3.2.2 doesn’t have the bug.

@etoolsmith after far too many hours banging my head against the wall trying to get this to work, support at the events plugin pointed me towards this updated custom code: https://theeventscalendar.com/extensions/creating-a-custom-filter-for-filter-bar/

I was able to use that plugin extension to put in my own filters for custom taxonomies, by…

• installing the plugin
• duplicating the Time_Of_Day_Custom.php file within the src folder
• renaming “class Time_Of_Day_Custom” to “class Whateveryouwant” (I chose “Locations”)
• removing everything after “use Context_Filter;”
• going to the-events-calendar-filterbar/src/Tribe/Filters/Category.php
• copy/pasting everything within the class function into the new file
• replacing “Tribe__Events__Main::TAXONOMY” with my custom post type name (mine was “wpx-location”)
• editing tribe-ext-custom-filter.php to reference the new function by duplicating the other references and updating the names accordingly

examples:

      include_once __DIR__ . '/src/Time_Of_Day_Custom.php';
      include_once __DIR__ . '/src/Locations.php';

      $map['filterbar_time_of_day_custom'] = 'Time_Of_Day_Custom';
      $map['filterbar_locations'] = 'Locations';

        $locations['filterbar_time_of_day_custom'] = [ 
            'read' => [ 
                \Tribe__Context::QUERY_VAR   => [ 'tribe_filterbar_time_of_day_custom' ],
                \Tribe__Context::REQUEST_VAR => [ 'tribe_filterbar_time_of_day_custom' ]
            ], 
        ];
        $locations['filterbar_locations'] = [ 
            'read' => [ 
                \Tribe__Context::QUERY_VAR   => [ 'tribe_filterbar_locations' ],
                \Tribe__Context::REQUEST_VAR => [ 'tribe_filterbar_locations' ]
            ], 
        ];

        new \Time_Of_Day_Custom(
        __( 'Time Custom', 'tribe-events-filter-view' ),
        'filterbar_time_of_day_custom'
        );

        new \Locations(
        __( 'Locations', 'tribe-events-filter-view' ),
        'filterbar_locations'
        );

hope this helps!

same here. had to disable all opentable, google, yelp, tripadvisor addons to get site back up. trying to re-enable any leads to this error:

Fatal error: Cannot redeclare ti_exclude_js() (previously declared in /home/customer/www/sycamorenewton.com/public_html/wp-content/plugins/free-facebook-reviews-and-recommendations-widgets/free-facebook-reviews-and-recommendations-widgets.php:50) in?/home/customer/www/sycamorenewton.com/public_html/wp-content/plugins/review-widgets-for-opentable/review-widgets-for-opentable.php?on line?50

this is the first time autoupdating any plugins has crashed any of my sites. please make sure this never happens again.

looks like it’s happening every now and then because I’m doing this for various reasons:

wp_deregister_style( ‘dashicons’ );
wp_deregister_style( ‘wp-block-library’ );
wp_deregister_style( ‘wp-block-library-theme’ );
wp_deregister_style( ‘contact-form-7’ );

…please take that in considering when/if you ever update this plugin.

this is a great plugin, but it seems like you’ve abandoned it and no longer reply to anything in the support page. what gives?

this feature would make getwid the holy grail…currently there’s no way to customize the default settings for a getwid block or getwid template, so whenever they’re inserted on any post/page the user has to change every setting manually. this is not very useful for a site if they have to do that 10-20 times while entering content. it also leaves a lot of room for user error. reusable blocks are certainly helpful to save out those default settings, but can be misused by content entry people (easy to hit “convert to regular block” and “remove from reusable blocks” are right next to each other and can be confused easily by accident). and even if content entry folks convert to regular block correctly, the problem still exists that the block defaults cannot be edited universally once they’re converted to a regular block. they have to be removed and re-added afterwards to inherit any changes.

i think this is a priority for the getwid team. you’ve already released a *ton* of great tools, but release this one and you’re the leader here!

aaand they’ve fixed the issue. except, as you probably know, mapify pro doesn’t offer auto updates…you have to download the new version on their site through your account (https://mapifypro.com/my-account/downloads/), deactivate your plugin, and reactivate after putting the new version up.

i contacted support and apparently mapify pro doesn’t work with wordpress 4.7 … they’re working on a fix.

was it mapify pro? how did you solve it?

@damian thanks for double checking…i tried again this morning and it didn’t throw the error!

i’m guessing there was some cache stuck in wordpress after the PHP update — even though the pages were saying the new PHP was being used, wordpress at its core wasn’t aware?

anyhow, thanks again for making and maintaining this awesome plugin. i have a client who really needs the eu cookie popup only to appear for EU residents accessing their site and this is really the only viable way to do it. i was not looking forward to the alternative option in case i couldn’t get your plugin to work.

hi Damian – I got the same error and it prevented me from activating the plugin.

after updating from 5.2 to 5.3 it now allows me to activate the plugin. however when i load my website I get the same error printed out instead of my site – and the only way i can remove it is by deleting plugin files.

do you have a recommended course of action from here?

i’ve confirmed that 5.3 is installed because i get this after putting up <?php echo ‘Current PHP version: ‘ . phpversion(); ?> on a page: Current PHP version: 5.3.24 ….

Here’s the error (very similar to dparadis):

Warning: require_once(__DIR__/composer/autoload_real.php) [function.require-once]: failed to open stream: No such file or directory in /wp-content/plugins/geotargeting/vendor/autoload.php on line 5

Fatal error: require_once() [function.require]: Failed opening required ‘__DIR__/composer/autoload_real.php’ (include_path=’.:/usr/local/php5/lib/php’) in /wp-content/plugins/geotargeting/vendor/autoload.php on line 5

oops – sorry, i didn’t realize the community you represent has achieved absolute perfection. i will code my sites 100% to the way the wordpress community has decreed, because that’s the goal of open source development, right? i forgot there’s no room for tolerance of other opinions or philosophies here, and that wordpress’ core isn’t built on a mountain of hacks.

i appreciate your offer and eagerness to help, but am confounded by your responses on this thread which did anything but help. in fact you’ve only succeeded in insulting me even after i figured out the perfect solution to my problem.

i come from a team of front end developers that had to build agnostic front ends for any backend. i think there are lots of benefits to that coding approach. you code from a different perspective and i’m cool with that. our team – even though we came from a lot of different backgrounds and experiences – never stopped helping figure out problems together, even if we disagreed or had different styles.

instead of just pointing your finger and saying i’m doing it wrong, try giving your fellow coders some respect and after giving your recommendation work with whatever decision they go with.

@royho – okay well maybe it’s not “correct” by your standards but it sure as hell fixed all woocommerce JS integration issues for my custom install.

have a happy thanksgiving ??

for anyone else who refuses to let wordpress dictate your front end, this was the fix:

add_filter(‘wp_enqueue_scripts’, ‘override_enqueue_scripts’, 10);
function override_enqueue_scripts() {
//enqueue your JS here
wp_enqueue_script(‘greencitygrowers’);
wp_enqueue_script(‘ajaxform’);
}

the priority argument (10) essentially tells wordpress to ignore woocommerce’s registration of jquery so that everyone gets to play nice with each other.

@royho thanks for the suggestion but i’m not going to change my philosophy on this overnight. i’ll update jquery manually when i need to. i don’t like wordpress dictating what i should do on the frontend when i’m only using it as a backend platform.

i’ll give separating scripts a shot and i’ll see where that takes me. please let me know if you think of anything else, thanks!