Mark-k

Hi @johneer,

It sounds like you are running your site on a very outdated version of PHP (5.3). The best solution is to update your PHP to at least version 5.6 (7.0 is a much better one) which is the minimum version for WordPress 5.2.

This wasn’t an intentional change to deprecate support for old PHP versions, and we are sorry that this happened, but we just don’t test against them so this kind of bug may have crept in ??
Right now we are just unlikely to release an official fix just for this and force all the people that have already upgraded to do another upgrade.

If for whatever reason you can not upgrade your PHP right now, you can just replace the “[]” with “array()”, and things should work (or you can leave that line commented out if you have no additional problem now), but this should be a very short term solution.

1. If the free version works on your site there is a zero chance of the pro version breaking anything unless you have a broken theme or other plugins that misbehave.

2. At no place we even hint that we are doing refunds. Maybe we should be, as you suggest, like other plugins, ask you for inflated prices and auto subscribe you to renewals, and then we will be happy to refund for whatever reason….

3. If you have bothered to ask you would have got an explenation how to test the pro version without requiring a license.

To add to daniel’s question, I just ran a new widget on 5.1 and everything seems to work. Obviously, this does not mean that there isn’t a bug somewhere but honestly, the changes 5.1.1 introduced over 5.1.0 should not have made any such difference with our code.

You are more than welcome to use our support form from our website if you find this forum to be too limiting.

Hi @henrivantsant can you please give some more details? Was there anything specific that didn’t save, where did you save from, customizer or widget admin, and were there any JS or PHP errors?

@sdevad,
There should not be any problem with displaying more than 10 assuming your category has more posts than that. As we never heard anyone complain about it, my gut feeling is that you have some problematic interaction with the theme or some other plugin.

If you have staging/dev environment, can you please try to use one of the default themes, and turn off plugins and try again? Another thing to look for is PHP errors in your error log file.

Hi @kwizzy,

If I understand correctly what is it that you need, this is actually one of the features of our pro plugin – to style the content differently for different items. You can have two different settings one for the “normal” post items and another for “alternative”, and some flexibility in how to define which item is “normal” and which is “alternative”, with the easiest example is exactly something like you describe, with X item at the top being displayed in one way and the rest with another.

You can try to do something similar by having two widgets with different offset one under the other, but this might require more CSS work to make it look right.

• This reply was modified 6 years, 2 months ago by Mark-k.

Hi @nycplugged,

I am not sure that I understand what is the actual issue. What is it exactly that you are trying to do and what is the problem you are facing?

Maybe if there was some information about which conflicts you are talking about, it would have been easier to investigate it.

Generally, conflict means that there are two sides that contribute to having a conflict, so please no need to point fingers as it will be easy to just point it back at avada instead of trying to solve the actual issue.

Lets get this to be a productive discussion. Right now maybe Daniel knows better but I have zero idea what kind of conflict there might be at all as our JS is extremely minimal and should be isolated enought to not cause any problem to anyone.

Unlikely. The core of the “problem” is that the widget uses images which were manipulated by wordpress to fit specific sizes, and that process just do not work with animated gifs.

If you can find a way to prevent wordpress from doing that, animated gifs might work as well.

This should be easy to get with the table layout of the pro version https://tiptoppress.com/term-and-category-based-posts-widget/documentation-4-7/#Table.

You might be able to get it with some advanced CSS with the free version.

Frankly meta handling both as filters and in the template is something we are unlikely to add to the “free” version, while we will work to make it possible with the next version of the “pro”

@sina2008

You can Copy that CSS and add it to your child theme’s CSS, then in the widgets themeselves, you can disable the CSS generation under the “general” section.

I agree with you that inline style of 800 lines long is a little extreme , but technically it is hard to detect when a widget is being used and add its specific inline style in the head while the decision to output it might happen only at the footer. Outputting the style only when the widget is being output violates the rule of not having styles in the body as it makes page rendering slower.

The other option is to have a CSS file, but that will add another http hit and you will need to have style for all of the options and add classes all over the html, which is not nice as well.

You are welcome to open a bug report at our git, and we will will see if we can figure out something for our next release (right now comes into my mind an option or filter that will let us do better detection of widget usage, with the down side of slower generation of the html.

Simple answer, the plugin do not handle any user information in any way, therefor it is GDPR complaint in the best way possible ??

@pidengmor, yes which brings the second part of my review. History shows that the wordpress core plugins fall into disrepair and no one feels like he should “own” them. We seee it with the importer breaking on php 7.2.

So what is going to happen is that in the long run there will be changes to “gutenberg editor”, but there might be no one that will be interested in maintaining the “classic editor” plugin. In addition @pento said in a very clear language that moving forward the gutenberg team do not plan to maintain the possibility to run the classic editor at all, which means that more and more hacks will be needed, and maybe at some point it will not be possible at all.

The only true option that can be actually maintained is an official way to turn gutenberg off and use the classic editor. Any thing else is a hack with an unpredictable life time

in https://github.com/WordPress/gutenberg/issues/4409#issuecomment-357118208 @pento said

“So, to get back to the original question, a single code-based option to disable the block editor isn’t a viable long term solution, it can’t expand to give appropriate options for future WordPress Core development, it really does a disservice to everyone here if we were to create this option.”

Therefor the notion that the maintaining the classic editor plugin is going to be harder and harder.

@pidengmor, and how will they know about this plugin? The realistic scenario of 5.0 is that people upgrade, go to edit some post which prompts them to convert to blocks (or they create some new content) and after a week they decide that they do not like the experience (for whatever reason, plugin incompatibility, inability to properly edit via xml-rpc, wordpress search is 100% useless instead of only 80%, or just a general dislike) at that point they search the interwebs find this plugin and install it.

And at this point, what exactly gona happen to all that content which was authored and changed with gutenberg? gutenberg is disabled, so the inline styling will not be applied any more, and on the editor side you will see only the text, but to see whatever additional data used with it you will need to go to the text tab and guess how to apply all the json data in the comments, something that will be hard even for technical people.