New in 4.7: Exclude child categories

Up to 4.7, when filtering by a specific category the post items displayed included also posts from subcategories of the selected category. In 4.7 we introduce the option to restrict the post items to a specific category without displaying posts from its subcategory.

Customize test 4.6 – Just another WordPress site(4)

Multi selection is available in the premium widget

Is there a need to filter and select category with multi selection? We support such a feature in our premium widget Term and Category Based Posts Widget. We do this differences because we want a light weight widget with Category Posts Widget. In the most cases filtering and show posts from only one category fits all aims. On the other side our premium widget supports also custom post types. So the aim to select two or more categories, terms, what ever, … is more possible. So the filter UI from the premium widget can takes more time for configuration as the free version it does.

New in 4.7: Show all recent post, no category filtering

We think our widget has great features which are no match for the WordPress recent posts widget, and as there was always a possibility to hack the widget into showing all recent posts, we decided to just make it more organized by letting the user just specify an “All categories” in the category filter ti disable the category filtering all together.

Customize test 4.6 – Just another WordPress site(2)

Select more then one category

Is there a need to filter and select category with multi selection? We support such a feature in our premium widget Term and Category Based Posts Widget. We do this differences because we want a light weight widget with Category Posts Widget. In the most cases filtering and show posts from only one category fits all aims. On the other side our premium widget supports also custom post types. So the aim to select two or more categories, terms, what ever, … is more possible. So the filter UI from the premium widget can takes more time for configuration as the free version it does.

New in 4.7: Try before you buy and license migration

We believe strongly that people are willing to pay for value, and that our products are a good value for the price we ask. We have the whole licensing operation merely to prevent honest people from being tempted by the “dark side”, because we are all just human and no matter how wealthy we are we will always be tempted to save that 10$ if possible.

This is why we want the experience of honest people be as smooth as possible and let them do as much as they want with their license.

The upcoming 4.7 release will have two improvements in this regard:

  • Try before you buy – Even with a mere 10$, you are likely to “hate” yourself if you bought something that do not work for you and because of lack of documentation, or whatever other reason, you thought that it will.
    With 4.7 we will let people to download a version which will not require a license as long as it is used on a local development server (in other words, a localhost or if the site domain resolves to the local host ip of 127.0.0.1). This hopefully will let users check the relevant features before buying.
  • License transfer between sites – Sometimes when going from development to production the domain of the site changes, and if you are not going to keep a live development server, it doesn’t make any sense for both the user or us to make the user buy two licenses just for that.
    With 4.7, in this kind of situation you will be able to just deactivate the license on your development site and activate it on production.

We are also looking at doing licensing per domain instead of per wordpress site, but we have no firm idea yet how such an implementation might look, and when will we do it.

Client-side cropped-, adaptive- and also fluid images for Responsive Layouts

Client-side cropped- and also fluid images

Client-side cropped- and also fluid images

We decided in the past to add a image cropping feature (CPW since 4.1.6, April 13th 2016, as option and TACBPW since 1.0.1, as default), to set your image dimensions in pixel for the feature image or called thumbnail. We called it “CSS cropping for thumbnails“.

This CSS cropping gives your image the possibility to set dimension options for width and height. Our decision till now is to perform this cropping with CSS. CSS is fast and the website admin can use, but it’s not a have to. And our feature don’t neet to generate new images or actually a change for image sizes in the WordPress settings.

We talk much about the feature and implement it to other widgets like Same Category Posts.

We started to solve the max-width problem for our client-side cropped images

Solve "max-width" issue for client-side cropped images with Javascript

Solve “max-width” issue for client-side cropped images with Javascript

The problem we had with our cropped images is we can’t use the CSS property max-width, because the cropping is also made with CSS. No CSS rule solve both features correctly at the same time and we set a fixed width and height. For Responsive Layouts this is very bad to have only one image size and the image can’t be resized, e.g. for many different mobile devices and screen sizes.

For the 4.7 we tried a CSS solution again to solve the aim to have fluid images with CSS attribute max-width. It’s Mark again who mentioned to try it with Javascript. And now it’ll be available with the 4.7 (4.7 beta 1).

The Javascript code works only once at page load or on page resize. Last one is in the normal website usage not performed. The Javascript code is also performance optimized and curse a very less millisecond delay while page load.

Demo page: demo.tiptoppress.com

Advantages with client-side responsive images:

  • No additional (server-side) libraries required.
  • No cookies required.
  • No extra server configuration needed.
  • Does not attempt to perform any client OS detection.
  • Server image storage doesn’t change.
  • Fast server response any time.
  • No image quality loss.
  • No side effects with frequent use on several pages.

Other image features for Responsive Layouts are planed

We’re happy we found a solution and we hope we don’t get problems and can solve the requested Responsive Layout support. What we also want is use the CSS attribute “width” like percentage unit (100%). And either for one dimension and the other as pixels or for both, no size restriction is given and the image fill all the available space. We planed it also for the 4.8 – be patient if all works right.


Related posts:

New in 4.7: Default thumbnail

Thumbnail are great for the look of the page, but the problem with them is that they require some extra effort when editing the content, an effort for which you might not have time when you rush to publish something, or you just forget.

This kind of situation could have been handled in 3 different ways before 4,7

  • Do nothing and just don’t display a thumbnail. If the thumbnail setting produce a small thumbnail, it might be ok, but when the thumbnail is big and dominant, an item without it will ruin the balance of the design and might be harder to spot.
  • Just don’t display posts without a thumbnail. This keeps the visual balance but it means that the post is going to be more hidden than other posts.
  • Use a plugin that lets you specify a fallback thumbnail.

In 4.7 we are going to add an additional option, to set a fallback thumbnail for a specific widget. This will let you keep the visual balance without having to install additional plugins, and even have different fallbacks in different widgets.

default-thumbnail

And something that might have looked like

Customize test 4.6 – Just another WordPress site(2)

easily transformed to (notice the first item)

Customize test 4.6 – Just another WordPress site(3)

This feature will go into the 4.7 version of both the “free” and “pro” plugins due to be released right after WordPress version 4.7 will have its first RC release which is scheduled right now to november the 15th.

You can try the feature by downloading and installing the beta from https://github.com/tiptoppress/category-posts-widget/releases/tag/4.7.beta1, and report bugs or just get an impression of what is planned from our bug repository at https://github.com/tiptoppress/category-posts-widget/issues

New in 4.7: Skip first few items with the offset parameter

Some times you just don’t want to show the most recent posts, maybe because you have two widgets and the two most recent posts you want to display in the sidebar while another 8 are displayed at the footer.

To get this possible in 4.7 we have add an “start offset” parameter (not the greatest name, suggestions welcome) to indicate how recent (or whatever sort criteria is used) the post displayed should be, with a value of 1 indicates that the posts should stat with the most recent, 2 indicates they will starts if one item after the most recent and so forth (we preferred a 1 based system as it seems to be easier to understand than zero based one).

Technically the feature is implemented by requesting the DB to return items starting from position N and does not retrieve the first “ignored” items at all.

Widgets ‹ test 4.6 — WordPress(1)

This feature will go into the 4.7 version of both the “free” and “pro” plugins due to be released right after WordPress version 4.7 will have its first RC release which is scheduled right now to november the 15th.

You can try the feature by downloading and installing the beta from https://github.com/tiptoppress/category-posts-widget/releases/tag/4.7.beta1, and report bugs or just get an impression of what is planned from our bug repository at https://github.com/tiptoppress/category-posts-widget/issues


Related posts:

New in 4.7: Multiple shortcodes

When we added the shortcode to 4.6 we were not very sure about the way the feature was implemented. Due to the large number of option it was obvious that doing it the “normal” way works and users know it and accept it, but making users cram them on one line hoping that they got the syntax correctly is a bad user experience.
Instead we decided to try a different approch, use the shortcode itself as a pure place holder, and configure the settings via the customizer, with the settings being stored as a custom field in the relevant post DB instead of being part of the shortcode itself.

Wanting to reduce the risk of developing something that people will hate, we implemented in 4.6 only one shortcode per post, but in general it seems like the feature got a good reception, we had a very good experience with it while testing the code and setting our own demo pages, and seems like the only problem where with some obscure page builders (Pippin Williams’s review of them is a must read) and therefor we are enhancing the feature in 4.7 and enabling to have as many shortcodes as you like.

The only change from 4.6, is that if you want to have more then one shortdcode, in order to differentiate between the short codes you need to assign a value which will identify them in the attribute “name”. The value can be anything you like, no special formatting is required. If the name attribute is not explicitly assigned it default to be a “” (empty string).

Here is an example of how it looks in the editor:

Edit Post ‹ test 4.6 — WordPress(1)

And the possible front end output.

4.7 test – test 4.6

This feature will go into the 4.7 version of both the “free” and “pro” plugins due to be released right after WordPress version 4.7 will have its first RC release which is scheduled right now to november the 15th.

You can try the feature by downloading and installing the beta from https://github.com/tiptoppress/category-posts-widget/releases/tag/4.7.beta1, and report bugs or just get an impression of what is planned from our bug repository at https://github.com/tiptoppress/category-posts-widget/issues


Related posts:

4.6.1 version of the Term and Category Based Posts Widget is released

 

This is a very feature packet release it was tested for compatibility with WordPress 4.3-4.6.

New

New versiton Term and Categorz Based Posts Widget 4.6.1

  • Insert the widget by using a “dedicated” shortcode – [ termposts ]. No need of any additional plugin to do it.
  • Many new layouts
    • Horizontal (Row), in which post items are arranged in a horizontal row. This layout can also be used as a horizontal news ticker
    • Responsive rows, in which items are arranged in rows, as many rows as needed for all items to be displayed, whatever is the width available to the “widget”
    • Table, in which the post items are arranged in a table
    • Masonry, in which items are arranged in a responsive way in a grid
  • “spice up” the display with alteration pattern which enables different styling of item based on their location. For example, have the title in even items align to the right, while on odd items it aligns to the left.
    Two patterns can be used – a general pattern rule, and a simplified that use alterations only for the last items
  • More thumbnail positions. In addition to the top and left, you can also now align the thumbnails to the right, place them below the title and above the excerpt or align them to the right or left of the excerpt, last but not least, use the thumb as the background to the text.
  • Control title and excerpt alignment without having to modify your CSS. Both can be aligned left, right or center.

Improved

When no explicit dimension are given to the thumbnail we use the thumbnail setting from the media settings

Technical changes

We have started deprecating the CSS file that is loaded on the front end, and move all CSS rules into the header of the pages where th widget is actually being used, using the most specific rules possible. Now it should be easier to override a specific rule without resorting to disabling the CSS for the whole widget.

You can see several great example of what is possible to do with 4.6.1 on our demo site

 

Terms and Category Based Posts Widget support the Masonry framework

Masonry is a JavaScript UI framework and we decided to support it for “Terms and Category Based Posts Widget” from the version 4.6 and higher. The framework do this “masonry” arrangement for posts and much more – we need some time to understand how the framework works – and now we can proudly say, we know a little part of it. This little part in understanding was enough for support thas UI framework.

Masonry with Thumbnail > Position > Background

Masonry with Thumbnail > Position > Background

The problem(s) which Masonry solve and how is unique

Every time we get to deal with the UI framework we discover and learn something new. Therefore, it is difficult to find one suitable set to describe it. Masonry solve many small and big problems in a simple way. For an entry, following remarks:

“Masonry is used for responsive websites, different screen sizes and all mobile devices and without that media-queries must be defined in the CSS file.”

Especially relevant it’s the second UI framework which is added to the core code beside jQuery which must have a reason. That’s why we want to explain how we use it, which features we start implementing with this Masonry framework and which features we want implement with it further versions of our widget.

Edit the Masonry settings with the customizer

Edit the Masonry settings with the customizer

As a result edit the settings with the WordPress customizer, after Terms and Category Based Posts Widget is added to the widget area or with shortcode. Choose in the Styles panel for Layout: Masonry and our posts should rearrange in a masonry pattern. On the screenshots and at the demo.tiptoppress.com page we use post item width or the thumbnails panel width for position. Thumbnails panel width means “background“, so the text, excerpt and other text content is positioned over the image. So you need to define a width for posts which is enough for the Masonry framework to know to make this posts responsive. Change the Browser width and you can see how the post take place of the page width. Once with three columns, two or one.

Hence for the version 4.6 this should be good to use it. And it will be good, you should try it. Simple to use and solve a lot – for responsive webpages.

Responsive webpages and more

Finally in 4.7 we want to implement two other features for Masonry. We want to add pagination and Ajax scripts which perform infinite page loading effects. If you’re interested in grids and columns for your posts we recommend you should try it out.

In Conclusion the masonry feature is available in the 4.6-beta wich we’ll release in a less days. If you’re already interested in a beta version, please write us: http://tiptoppress.com/contact/

Find bugs and test with mobile devices

At the moment we’re hardworking on the release for 4.6 and and look forward to the new version, which has great features. Find last bugs and test with some mobile devices.

Remote debugging with hardware mobile devices

So we stopped implementing features and have the focus on only testing functionality, the rendered HTML and our CSS styles. Our effort is don’t make patch versions after the release. Patch versions can’t be avoided but reduces to a nearly zero. We test with common operations systems and also with mobile devices, like Android, Windows 10, OS X and IOS.

If you are already interested in a beta version, please write us: http://tiptoppress.com/contact/

And we test with some WordPress Themes, like Twenty Sixteen, Twenty Fifteen, … Themes which includes Google’s Material Design Light framework and Themes how build for WooCommerce. We have found the most unexpected error while testing with different WordPress Themes. And is expected to remain in the feature, because each Theme use such different CSS styles and there’re many CSS attributes which can normalized in many ways. So we use in our widget CSS as less as possible normalizing CSS and take our to the layout attributes, like float, text-align, flex-box, … and avoid writing things like sizes, colors or font decoration styles. Implement this is impossible, but with our experience, we get a feel for a happy medium.

mobile-debugging

Testing the upcoming version 4.6, with many operation systems, devices and Themes

We start installing “Terms and Category Based Posts Widget” on our customer pages

The third way we’re testing is with our customer websites and shops. What can only cover a small portion of all our supported features and supported feature variations. What meanwhile matters an important part of our widget concept. But this concept should not part of this post and will be described in further posts more in details. We started with the pro version and support Custom Post Types, Custom Taxonomies, WooComerce Products or events from the The Event Calendar. So there is a wide possibility of websites to use and show posts with our widget Term and Category Based Posts Widget. With the upcoming version 4.6 we leave the widget area and support shortcode as our free version Category Posts Widget supports it. And with shortcode you can use our widget in the post’s content, e.g. over the entire post content width.

This makes us busy and not even easy to decide in which direction the widget had to go. Now we’re on a very good final state and final features.

For sure we support mobile and responsive features and referring mobile devices in further versions in more details.