Jaakko P?ntinen

Thank you, Nabil ??

FYI, I need your plugin to work with BjornTech’s Zettle integration. The images the plugin uploads in the import process are not being handled by your plugin. Their dev is checking whether their import process triggers the action you described.

Heya,

Thanks for the lightspeed reply ??

No worries, I’ll wait – my import is almost done and the plugin works beautifully otherwise.

This is one of the best POS/PIM-integrations I’ve ever configured. And I know lots of professionals here in Finland think so, too. Another plugin of your making is also gaining momentum, “WooCommerce Accounting Report”. It’s just beautiful. Woo is made for North America and it shows in the way things are organized and presented. We need EU approach and of course even closer to home, Nordic approach.

Keep it up and thanks again!

Resolved.

Ahoi.

Had to come and chip in, I have this EXACT problem and it will not go away with Themehigh’s Checkout Manager Pro. Not even if you hide all custom fields from invoices, it just prints those things we see as default.

I haxed my way around this with CSS in the Pro version of Ewout’s PDF Pro;

1. Go to “Customizer” in Ewout’s plugin’s settings
2. Look down to see “Custom Styles”
3. Use code below (note that it might nuke something in your PDF template, as it targets by CSS classes / HTML tags)

h2, th.quantity, th.product {
visibility: hidden
}
.order-details th.quantity {
visibility: visible
}

Why the second part? Well, the table heading .quantity is a standard in both Themehigh’s and Ewout’s plugins and there is no better way to match Themehigh’s php output, so after making the unwanted stuff disappear, you have to target Ewout’s PDF fields to make them visible ??

Hacky solution, I know, but that’s what the entire software field is xD

I was coming to leave a review of 5/5 but noticed I already had.

Dangit x)

Thanks x)

And if MTS dares to answer here; my client and I are through with you.

Not thanking for your business,

– JP

No, thank you, all resolved ??

Thanks for a great plugin, my go-to choice.

5/5 on this reply as well.

Cheers!

– JP

This has got to be the most epic support given to anything ever ?? The amount of text. Daym. I was looking for a sulotion to a problem (this wasn’t my problem OR a solution to it) BUT I was mesmerized and read through it all.

Good on you, Dima! ??

• This reply was modified 4 years, 11 months ago by Jaakko P?ntinen.

Hello,

Thank you. True, the shortcode needs options, it’s kind of useless right now.

I’m sure you’ll make it useful soon ??

Your plugin now works in my customer’s use case beautifully. Thank you.

Oh man.

I gotta add. I’m thick. Thick, I tell ya. Of course the expiry date can’t be the SAME date as the end date.

That would mean the event expires immediately. What I’ve wanted to achieve was all along just completely doable in this plugin, just set the expiry date to the end date +1.

That way, when the next day begins, the event expires at 00:00. That’s just what I wanted!

Lol. I’m so sorry for wasting your time on this, Hitesh!

I feel bad ??

Doubt it. This plugin seems to be a thrown-together thing. Facebook likes to close up on itself, clearly.

I understand, it’s their strategy. They want to be THE ecosystem, not part of AN ecosystem, which is basically Facebook + everything else online.

Great strategy, bold for sure.

Waiting for Libra and Calibra… Facebook will become a financial ecosystem as well. Unprecedented stuff. Bad for webdevs though ?? Annoying barrier…

No, not a Facebook fan, but gotta hand it to them. Bold stuff.

Thank you!

Continued this topic by submitting a ticket on your system.

Thank you! ??

One more addition:

Would also be nice to expire events immediately after the end date OR end time is over.

Example one: Event ends on 15.6.2019 at 10.00 -> Expiry happens at 15.6.2019 at 10.01.

Example two: Event ends on 15.6.2019, no end time specified -> Expiry happens at 16.6.2019 at 00:00.

Also,

Setting the same option in the settings to “Listing expires on Specifed below Days” and input 1, all the expiry dates get set to 1.1.1970 ??

That’s not ideal…

Hello!

This produces a pubDate reading that feed readers can and will show, thank you! I modified the code as follows to get both date and time with the correct time offset to show:

$start_date = get_event_start_date();
$start_time = get_event_start_time();
$start_all = "$start_date " . "$start_time";
echo "<pubDate>" . esc_html(date('l, j F Y H:i:s +0300',strtotime($start_all))  ) . "</pubDate>";

However, RSS is still fighting back. The original pubDate element stays in the feed, and feed readers either take only the first one and show it (which is, again, the date the event post was made) OR, stupidly, just take both of them and slap them together like this: Wed, 08 May 2019 21:00:00 +0000Thursday, 12 September 2019 19:00:00 +0300

The latter one of those is the correct one that I’d like to show!

But it seems that without somehow altering how the feed gets printed by WordPress to begin with, this is not doable from within your plugin ?? Sadly!

Thank you for all your help. You’ve been outstanding. Now I’m set with a recipe for the pubdate injection. I’ll need to find out how to alter the default WordPress RSS feed and check if the feed being created is an WP Event Manager feed and if it is, change the way the pubDate is printed.

All feeds from our WP cannot be modified, as we have news feeds as well, which rely on the pubDate being the post publication date. No need to modify that…

This is endless ^^ Heh.

Thank you!