bowenac

For anyone else that ever runs into this problem, here is how I fixed it for our scenario. As always make sure you have a backup of your database before doing this. This assumes your wpdb prefix is wp_ otherwise replace wp_ with whatever your db prefix is.

Set wp_prli_links link_cpt_id to bigint(20) to match wp_posts ID field type
Set wp_prli_clicks link_id to bigint(20) to match wp_prli_links id field type

Then:

Fix for Links Table

UPDATE wp_prli_links
JOIN wp_posts ON wp_prli_links.name = wp_posts.post_title
SET wp_prli_links.link_cpt_id = wp_posts.ID

Fix for Clicks Table

SET link_id = (
SELECT ID
FROM wp_prli_links
WHERE wp_prli_links.slug = SUBSTRING_INDEX(SUBSTRING(wp_prli_clicks.uri, 2), '?', 1)
)
WHERE EXISTS (
SELECT 1
FROM wp_prli_links
WHERE wp_prli_links.slug = SUBSTRING_INDEX(SUBSTRING(wp_prli_clicks.uri, 2), '?', 1)
);

Thanks, looks like that solved it.

I am looking to override the content inside the iframe when using zoom_join_via_browser shortcode, or Zoom – Join via Browser Gutenberg block… where the fields Name, Email, Join button are. That template embed-session.php template seems to be just the wrapper for the iframe.

Like I mentioned, the edits do show up for the shortcode, and gutenburg block if I edit this template directly in the plugin video-conferencing-with-zoom-api/templates/join-web-browser.php, but it does not pickup the edits in an override file /mythemename/video-conferencing-zoom/join-web-browser.php

The template override does seem to work when joining a meeting from a meeting page and clicking on join via web browser button, which opens a new tab for the same page but with the url parameters. e.g. zoom-meetings/event-name/?url_params

Based on this, it seems to me that the shortcode and gutenburg block is not aware of the template override for some reason.

I did create a template override at mythemename/video-conferencing-zoom/shortcode/embed-session.php just to see if it would then pick it up but it does not.

Does that make sense?

Just wanted to note, I have the same issue but I just hid them on single product pages via css.

Wanted to provide some further findings…

With the debug option disabled, a person can still checkout, however it obviously does not add any shipping costs… and will show the message in the shipping section “There are no shipping options available. Please ensure that your address has been entered correctly, or contact us if you need any help.”

However with the debug option enabled, sometimes it breaks the cart and says “There are some issues with the items in your cart. Please go back to the cart page and resolve these issues before checking out.” Sometimes it just shows the message “There are no shipping options available. Please ensure that your address has been entered correctly, or contact us if you need any help.” and a user can still checkout… it seems hit or miss.

Suggestion: With debug option disabled, there should be some kind of catch and display a different message about weight restriction or something in the shipping section, and possibly disable the checkout button, rather than the default WooCommerce message.

I noticed the fallback option mentions you can set a flat rate if no rates are returned by UPS so the customer can still checkout… well the customer in this case can still checkout anyway… it just isn’t adding the shipping rate. I know this flat rate option is one possible solution to this kind of problem, however there still seems to be an issue without using the flat rate that the customer can still checkout. Also not sure the flat rate option will work for this clients needs. They’re looking into an account option for LTL (Light Truck Load) setup with the UPS account to get rates over 150 lbs apparently, hopefully that will solve the problem. Sounds like that is on the API account so it might.

Another suggestion would be to make note of this on the plugin description.

• This reply was modified 4 years, 3 months ago by bowenac.
• This reply was modified 4 years, 3 months ago by bowenac.

This appears to be a weight limit/restriction to 150 pounds.

I tested this locally on a fresh install with only WooCommerce, Default 2020 theme, and this plugin.

I created a product and set it to 16 oz.

I then added 150 to cart, which works fine… I then edited the cart and set quantity to 151 and then checkout Shipping section would show the message “There are no shipping options available. Please ensure that your address has been entered correctly, or contact us if you need any help.” but no errors and a user can still checkout…

Turning on debug option and doing the same thing…
150 works fine, going back to the cart and modifying the quantity to 151 and updating quantity then triggers the error about a maximum per package weight.

UPS: Failure: The maximum per package weight for the selected service from the selected country or territory is 150.00 pounds. (111035)

• This reply was modified 4 years, 3 months ago by bowenac.

Thanks was able to find the problem and fix it. Was a conflict with a Plugin that was creating an order items override, which was including the refunds template but it didn’t actually exist.

Have the same issue, but I just get a popup saying “Error processing refund. Please try again.” No console erorrs, nothing in woo logs, nothing on stripe logs.

Yes you’re correct sorry I meant the db records. Still it appears when you’re converting the post types from the old db record into the new db record something is happening.

What I did to fix it was I copied the serialized array from the old db record, and copied the serialized array from the new record. I then manually re created the new serialized array with the missing post types data from the old record into the new format. Then replaced the serialized data in the new db record with the fixed/updated array, I was then able to see the custom post types that had been missing.

I still have the data from the old record and the record after updating the plugin, and then the data I fixed and replaced on the new record if you would like to review that data to try and determine what could have went wrong. Let me know if you would like to see that data, I could email it to you or something.

• This reply was modified 5 years, 8 months ago by bowenac.

Was able to compare the two db records, and re-serialize the data and add the missing post types to the new db record, post types are now showing up. So this leads me to believe there is an issue when converting the old db record to the new db record.

• This reply was modified 5 years, 8 months ago by bowenac.

So rolled the backup back to before the update. Disabled all other plugins, and took a loot at the db, and the code in the plugin. This appears to be an issue with the function that converts the post types to the new db table cptui_convert_settings it appears this is getting all the posts from cpt_custom_post_types and converting them into a new table called cptui_post_types, and some of the posts are not being converted and added to the serialized array in the new table.

I will keep digging through and let you know if I find what exactly is causing it. Let me know if you have any ideas. One specific post type was registered with a – instead of a _ and also has a rewrite slug. Example is slug was customer-spotlight and rewrite was customer-spotlights. However there are other posts that are using dashes that are still populating example name/slug = case-study rewrite = case-studies

• This reply was modified 5 years, 8 months ago by bowenac.

Just checked and it’s updating from 0.9.5

I searched the db for one of the missing post types and they are all still in the database, they just aren’t showing in the admin where they should be or anywhere. They also do not show in CPT UI either. The export/import code also does not show the missing post types.

Searched the database with SELECT * FROM wp_posts WHERE post_type =’cptslug’

Before updating the plugin, or if rolling back a backup before the update shows the missing post types, and shows them in CPT UI. So this really seems like something in one of the plugin updates is causing this.

• This reply was modified 5 years, 8 months ago by bowenac.
• This reply was modified 5 years, 8 months ago by bowenac.
• This reply was modified 5 years, 8 months ago by bowenac.
• This reply was modified 5 years, 8 months ago by bowenac.

Any options to exclude custom shortcodes that do not start with vc?

Actually I found where you’re doing this and just used the same relevanssi_page_builder_shortcodes filter with an array of all my custom shortcodes.

Could be nice to add this as a feature though, maybe a field that accepts a comma separated list of shortcode names without the brackets.

• This reply was modified 6 years, 3 months ago by bowenac.
• This reply was modified 6 years, 3 months ago by bowenac.

@mikeyarce like @sharmaabhi adding add_theme_support( ‘woocommerce’ ); fixed the issue for me… still not sure what would have caused this in a recent update… without theme support apparently something odd happens?

For me I’m using a custom theme I developed based on underscores _s