Forum Replies Created

Viewing 13 replies - 1 through 13 (of 13 total)
  • sb5

    (@sb5)

    For me hard to answer your question as it works now using my workaround to downgrade and upgrade again… All I can say it this settings links didn’t worked before and now it’s working and yes this is the correct URL.
    I think it was maybe not working because I first tried to run “WooCommerce PayPal Payments” plugin and maybe this one made a conflict…
    But I was really badly surprised that this plugin doesn’t allow to use paypal just as a standard payment method, that is the way I want it works. No reason for me to push users to use paypal bypassing other payment method.

    Hello, if it could help… I found a way to make it works, by downgrading woocommerce to 8.6 (using wp-rollback plugin) then restored paypal standard and finally updated woocommerce again.

    Thread Starter sb5

    (@sb5)

    Hello.
    I m not plugin developper, but I finally tried to have a look there…
    The issue seems to be located in the function : extend_admin_search() that is called in case the option to admin-search in GTIN is ticked.
    The thing is that both plugin are hooking the meta_query element of the query object. But this plugin just set the meta_query array without testing if the element already exists.

    So by replacing those lines :

    $meta_query = array( 'relation' => 'OR' );
    			array_push( $meta_query, array(
    				'key'     => '_wpm_gtin_code',
    				'value'   => $search_term,
    				'compare' => 'LIKE'
    			) );

    by those ones :

    $meta_query = $new_query->get('meta_query');
    			if( empty( $meta_query ) ){
    				$meta_query = array();
    			}
    			array_push( $meta_query, array(
    				'relation' => 'OR', 
    				'key'     => 'wpm_gtin_code',
    				'value'   => $search_term,
    				'compare' => 'LIKE'
    			) );

    seems to fix the issue.

    Dear Emanuela could you please confirm this is the correct way to fix that issue ?

    Thread Starter sb5

    (@sb5)

    Yes that’s was my plan. I did some tests now but as I thought the “add to cart” button is not working the generated link is wrong. And I guess the cart is not “cross-domain”. other plugins as the “add to wish list” button I have is neither not working.
    But the categories / sub categories listing are working. So I will organize my landing page to list categories but not products directly…

    FYI I had the same problem. Tried everything already explained here and nothing worked. Then I figured out that’s an access right permission problem and remembered I m running on an Odin (foremerly Parrallels) Plesk VPS that have a WordPress Toolkit and I used it to install my WP. I used the security tool of this and I already had problem with a plugin because of its security patches.
    Now I fixed the problem applying the “roll back” function on the “security of the wp-includes folder”.
    In general I experimented that the “security of the wp-includes folder” and the “security of the wp-content folder” are really tricky option of the Odin Plesk WordPress toolkit.

    No it’s the opposite : I try to upload an image to a file field ! So I want to put a jpg “for download” not “for display”.

    Hello yes it’s exactly what I did too (commenting those lines). But my suggestion is to add an option in the plugin to bypass those options, somthing like this :
    elseif ( $type == 'file' and $valid_image and !$option) {

    Cheers

    Yes of course but in participants-database.php on line 2297 you test if the uploaded file is $valide_image and then return an error if it is. I think the idea of that is that we should use an image field for images… but in my case I want to accept PDF or JPG.

    Just a suggestion more : in the new version you made a test of uploaded-file and generate an error if it’s an known image format. I suggest it should be an option. In my case I want to let people upload either a PDF or a JPG file.

    Cheers

    One note : I fixed it temporary in an ugly way that I will not post here ;-)… but a layout problem is that hidden fields are printed inside “<p>” tags and also are separated with line breaks (
    ). This put vertical spacing that could be annoying for the subscription page layout. You should consider using a special method for printing hidden field in ths signup form.
    Regards

    participants-database/classes/PDb_Signup.class.php on line 296 : Participants_Db::$plugin_options[‘primary_email_address_field’] instead of Participants_Db::$plugin_options(‘primary_email_address_field’)

    ??

    Cheers

    Thanks very much for you work… It helps me ! Just a small bug corrected in the file FormElement.class.php at line 475-477 the built link for the files (file-upload field) is broken (for edit-participant admin page) it’s actually using the wp_upload_dir() that is the wrong page. I put the line
    $field->link = get_bloginfo('url') .'/'.Participants_Db::$plugin_options['image_upload_location'] . $field->value; instead and it’s better now ??

    Cheers

    Hello
    I’ll need to make a form without this 2 restrictions… this week ?? I found several place in the source code to do the bypass, but for sure if you have some tips or “beta version” of the new release I’ll be very interested. Are you so kind to give some tricks or files for that in private message ?

    Kind regards

Viewing 13 replies - 1 through 13 (of 13 total)