Vince Tikász

Héctor,

Is there anything I can help with in development of WPP 3.0?

I had some free time so I continued the refactoring: https://github.com/tikaszvince/wordpress-popular-posts/commits/master. There are some @todo comment. These notes mark some problematic points:

• First of all, I think the admin menu and administration panel setup should not be in the widget constroctors.
• wpp_upgrade() have to move into include/update.php
• I think we need a standalone query builder class.
• image_resize() is deprecated
• I think in get_img() there is a code block could not run
• and there are huge if/elseif/else structures that make it difficult for understanding the logick

That is a little optimization.

When I created the _get_title() method I realized this new function will be called two times on every post rendering. It will be called to create the $title variable in render_popular_post function and it will be called again in _get_thumb().

The _get_title() can be resource-intensive method if qtrans is presented and other plugins/themes are defined some filter on the_title. So we can save some time and resource if we use the previous result.

This cache is only available for runtime. It uses a static variable for store datas.

It’s on Github: https://github.com/tikaszvince/wordpress-popular-posts. I did not finished the refactoring, but you could see the commits step by step whats happening.

It looks fine. My patch define a filter after the DB query and before the HTML markup builder codes. So when some plugin implement that filter, the default HTML build routine unnecessary to run. Because someone is want to override the default output.

I think the best we could do is define multiple filters.

1. Before HTML build, as in my first patch. With this we do not need default HTML builder behaviour (call it wpp_custom_html)
2. In the end of the foreach($mostpopular as $p) loop for every post output (wpp_post)
3. And a last one for the end, as you just defined wpp_html

=======================

If you don’t mind i give some advice. There are some principles I follow when write codes. A functions should do one and only one thing. When I keep my functions and methods as simple as possible at the end I get easily read and understandable code. Only two of these: KISS principle and DRY principle. You can read about these principles, and more in Clean Code by Robert C. Martin.

Now the WordPressPopularPosts::get_popular_posts() method is doing multiple things:

• Builds an SQL query
• Run the builded SQL query
• Iterates over the results
• In this loop builds a default HTML post output…
• … but if the user set some custom post_html builds post HTML from that layout

With an intensive refactoring the code of WordPressPopularPosts can become extremely readable and much more developer friendly. If you have a clean code you can implement new features faster and safely.

If you think and don’t mind i can help to refactor your code. What do you think?

I think in WordPress ecosystem a plugin should define and use filters and actions.

I think in active WordPress development it’s much easier to provide backward compatibility with filters than with custom classes.

Hi Héctor,

why not use the wpp_get_mostpopular() template tag with the post_html parameter instead?

I sorry that I cannot say a lot about this project, but I’ll try to explain the situation for you.

So, as mentioned earlier, the posts have a lots of special, structured extra data. These data have to display for the users. I tried to write the post_html parameter, but with the placeholders, defined in WordPressPopularPosts::format_content() method, no way to show the special post meta fields, or other not handled data.

In earlier (2.3.2) version I extend WordPressPopularPosts class, I have to unregister your widget class and register my (overwritten) class to make it work. In my class I override get_popular_posts function, and call the original one with $return = true paramter. I got the posts data from your method, so i could write my own output. But in version 2.3.3 this method ignore the return parameter and returns all the formatted content. I do not like this way to create special formatted post output, because I built it on a non documented behaviour and i don’t think the widget replacement is a good long-term solution.

I think its a good think to use actions and filters in plugin development, so theme and plugin developers could add extra functions and features without hacking original code