I’m having the same issue, and I’m also getting the “Sorry, you are not allowed to access this page” that’s been mentioned in other threads. Not supporting parameter based urls looks like I’m going to have to opt for another plugin as they’re a key feature of our setup. As you looked into this, do you have any insight into how this could be rectified? Or is this something that just won’t be supported?
Issue occurs using latest WP, Twenty19 theme and any plugin with parameter based urls… eg Gravity Forms.
I have this issue too. I’ve a massive image library (16,000+ images) and have a few concerns about the plugin working with such a large library. These errors and the post about the plugin eating server space contributing to those concerns. I’ve increased the memory limit and the plugin is now working, but PHP errors remain.
As asked in the linked post, will there ever be an option to delete all the unsmushed images?
Notice: unserialize(): Error at offset 331 of 478 bytes in yadda/yadda/resmushit-image-optimizer/classes/resmushit.class.php on line 328
Notice: unserialize(): Error at offset 764 of 911 bytes in yadda/yadda/resmushit-image-optimizer/classes/resmushit.class.php on line 328
-
This reply was modified 7 years, 2 months ago by Ojay.
Here we go, there’s a temporary fix outlined over on their Github repository.
Yeah same issue here, conflict with jQuery easing.
Thread Starter
Ojay
(@ojay)
Well that was the only scenario I could think of… could time zones come into play? Leaving it closed for some & open for others?
I did what you said, the Auction is closed & there was nothing of note in the backend, let me know if there’s something specific you wanted me to look for.
Thread Starter
Ojay
(@ojay)
No worries,
It was the same site with multiple admins. Only my user account, which is the original admin account, worked before de/reactivating.
Thread Starter
Ojay
(@ojay)
Fixed this by disabling and re-enabling the plugin. Maybe something for you to look at down the line though.
Hi there,
I’ve managed to get the following hacked together, but when adding to cart it only ever adds the first variation.
Excluding a good chunk of the template that’s printed out by…
foreach ( $options as $option ) {
if (sanitize_title($name) == 'print-options') {
$variation_type = '<span class="price">'. apply_filters( 'woocommerce_variation_option_name', $option ) .'</span> -';
} else {
$variation_type = null;
}
echo '<label itemprop="price" class="vari_price" for="attribute_'. sanitize_title($name).'-'. esc_attr( $post->ID ) .'-'.$tick.'">
<input type="radio" value="' . apply_filters( 'woocommerce_variation_option_name', $option ) . '" ' . checked( sanitize_title( $checked_value ), sanitize_title( $option ), false ) . ' id="attribute_'. sanitize_title($name).'-'. esc_attr( $post->ID ) .'-'.$tick.'" name="attribute_'. sanitize_title($name).'">'. $variation_type .' ' . $price{$tick} . '</label>';
$tick++;
}
I guess the issue lays with add-to-cart-variation.js, as it’s essentially working only the wrong variation is being added to the cart. Do you have any idea on what code is responsible for adding what variation to the cart??
Failing that, is this bug a priority bug or something that’s not likely to be looked at for a while as I really need a solution?
Thanks for all your hard work!
Ah… I ran Sweep on a site with Woocommerce before finding this.
Everything seems to be working fine on the front end, do you have any idea as to what issues I could potentially encounter?
I’ve got a backup of the DB so nothing’s lost… it’d be good to know for future reference though
Thanks mate
Thread Starter
Ojay
(@ojay)
No worries mate, thanks for getting back to me.
Sorry, the unexpected token error appears on the front end, at checkout… once the payment button has been clicked.
I’ve spoken to Woo about the issue too, and they’re positive that the “Time took: 1816.406ms” shouldn’t be there. Would or could that response have anything to do with your plugin??
Thanks for your help
I’m in the same boat, did you have any luck with this??
If I find anything I’ll post it here…
I’d very much be up for having this feature… would really appreciate a rough timeframe for the update also.
Thanks so much, good work!
Thread Starter
Ojay
(@ojay)
Yeah… without the if statements, and therefore the markup within them, the articles are loaded perfectly. The counter counts as expected, in my case to 16.
The bug only occurs when there is html that opens at the start and closes at the bottom. For example this works amazingly…
<?php
if (!isset($start)) {
$start = 1;
}
if ($start == 1 || $start == 5 || $start == 9 || $start == 13) {
echo '<p>open the .row div</p>';
}
?>
<article class="clearfix col col-md-3" >
</article>
<?php
if ($start == 4 || $start == 8 || $start == 12 || $start == 16) {
echo '<p>close the .row div</p>';
}
$start++;
?>
This is the strangest bug in the world, ever. 🙂
F.Y.I – I’ve tried this with all my plugins deactivated… though I’m yet to try a completely clean install with twentyfourteen.
Thread Starter
Ojay
(@ojay)
Ok so I’ve nailed the problem down to the use of div tags…
Below is repeater template #1…
<section>
<?php
if (!$start) {
$start = 1;
}
if ($start == 1 || $start == 5 || $start == 9 || $start == 13) {
echo '<div class="row">';
} ?>
<article class="clearfix col col-md-3" >
/// repeater html \\\
</article>
<?php
if ($start == 4 || $start == 8 || $start == 12 || $start == 16) {
echo '</div>';
}
$start++;
?>
</section>
This works perfectly in that you can click the load more button as many times as you like and posts will be loaded.
Repeater template #2
<div>
<?php
if (!$start) {
$start = 1;
}
if ($start == 1 || $start == 5 || $start == 9 || $start == 13) {
echo '<div class="row">';
} ?>
<article class="clearfix col col-md-3" >
/// repeater html \\\
</article>
<?php
if ($start == 4 || $start == 8 || $start == 12 || $start == 16) {
echo '</div>';
}
$start++;
?>
</div>
Repeater template #2 loads one set of articles no matter how many times you click the load more button. The only difference between #1 & #2 is the section element has been replaced with divs.
The only weird thing with repeater template #1 (it also happens on #2) is that the generated html comes out looking like this…
<section>
<div class="row">
<article class="clearfix col col-md-3">
/// article html \\\
</article>
</div>
</section>
<section>
<div class="row">
<article class="clearfix col col-md-3">
/// article html \\\
</article>
<article class="clearfix col col-md-3">
/// article html \\\
</article>
<article class="clearfix col col-md-3">
/// article html \\\
</article>
<article class="clearfix col col-md-3">
/// article html \\\
</article>
</div>
</section>
So in the first <section> only one article is printed…
then everything prints as expected, until you get to the last set of what should be four articles… (not included in the html above)
this last <section> only contains 3 articles… it’s like all the articles need to be moved up 3 places.
Sorry to bombard you, but this bug is soooo strange and I really need a fix. I may have to look to doing it myself somehow, which is a shame because you’ve created such a beautiful plugin.
Thanks for any help!
Thread Starter
Ojay
(@ojay)
Cool, thanks for looking in to it… do you have the Stackoverflow link? I couldn’t find it via search.
As I say, the problem isn’t really the counter. The counter works when the html being echo’d is opened and closed at the same point. You can repeatedly load more articles.
To be fair, the counter works perfectly once when displaying an open div at the top and a closing div at the bottom…
In this scenario the bug occurs when you go to load a second round of articles… you can’t load anything else. The button is just dead. No error in the console or anything. I’ve no idea why opening and closing html in this way would prevent the second load of posts?
With the js counter, I’d be having to append the div’s to the correct place within the most recently revealed div.alm-reveal… is there a baked in method to target that div?
Thanks again for your help, and if there’s anything you’d like me to try to help you debug this please ask 🙂
