Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter 182tage

    (@182tage)

    Well thank you. When this way is blocked, i will try the way with

    $wpdb->get_results()

    to use a direct SQL-statement. A simple Query is needed with a subquery for the views per item. This should only need a few ten milliseconds. I think this discussion can be closed.

    Thread Starter 182tage

    (@182tage)

    After some days of watching, comparing and analyzing i found out:

    1. There is a time discrepancy between your function custom_wpp_update_postviews() and wpp_get_views().
    2. wpp_get_views() ist working just in time (that means correct) but custom_wpp_update_postviews ist updated only about every second day.
    3. As a result the sequence (produced by orderby phrase) is old whereas the shown views are fresh. And that looks like a wrong sorting.

    The question is therefore how to refresh the data in the custom fields like views_daily more often, the best would be exactly in the same period as wpp_get_views(), simultaneously.

    As i mentioned twice there is also still an issue with a second orderby, if the number of views in the listing is equal. Using your plugin’s shortcut this sorting is by date/time of last view. I have to emulate this and it would be great to know if there is an accordingly custom field for this.

    Thread Starter 182tage

    (@182tage)

    Hi Hector,

    sorry if i wasn’t clear enough.

    The custom field used for sorting comes from the function you posted here (example for daily), which i placed in the functions.php.

    function custom_wpp_update_postviews($postid) {
    
    $accuracy = 100; // 100 for test purpose
    
    if ( function_exists('wpp_get_views') && (mt_rand(0,100) < $accuracy) ) {
            update_post_meta(
            $postid,
            'views_daily',
            wpp_get_views($postid, 'daily', false)
        );
    }
    
    add_action('wpp_post_update_views', 'custom_wpp_update_postviews');

    So there is no problem with number format for sorting by WP_Query.

    The additional code line

    wpp_get_views($post_ID, 'your_meta_key', false);

    in the loop simply generates the content for displaying, there is no impact on sorting here. Additionally i tested it though. Either the parameter is true or false in this line or in your function custom_wpp_update_postviews has no impact on sorting. Probably the line

    'meta_value_num' => 'DESC',

    makes the typecast automatically.

    The problem as to see here https://182tage.net/blog/test-heute still exists. For smaller numbers as for daily and weekly the sequence is wrong, also listing items with 0 views. For larger numbers as with monthly it works correct (so far as i can see). For example for daily the sequence is 4,3,1,0,0,1,2,0,0,0. There should not be any item with zero views in that list. The sequence should be 4,3,2,1,1 – finish.

    There was a second question: Sorting should be possible with two orderby’s: First for the time range – and if there is more than one item with the same number of views it should be sorted by date of last view (DESC) additionally. Like this about:

    'orderby'        => [
                 'meta_value_num' => 'DESC',
                 'XXX' => 'DESC'],

    Where XXX could perhaps be the name of a custom field for the dates of last views. Is there any possibility for such a custom field?

    Thank you for your advice!

    Thread Starter 182tage

    (@182tage)

    Hello properlypurple, thanks for asking. No, the issue is still existing in the background. I started to program an oldfashioned Javascript-workaround. On mobiles the toggling of the main menu is working now. I will add a similar solution for the submenus. It is a bad and dirty solution but nothing else helped.

    In the footer.php i added:

    function einaus(o)
    {
    if(eval('document.getElementById("'+o+'").style.display == "none"'))
    {
    eval('document.getElementById("'+o+'").style.visibility="visible"');
    eval('document.getElementById("'+o+'").style.display="block"');
    }
    else
    {
    eval('document.getElementById("'+o+'").style.visibility="hidden"');
    eval('document.getElementById("'+o+'").style.display="none"');
    }
    } // Menü ggf. ändern
    function checkMenu(o)
    {
    if(window.innerWidth < 910)
    {eval('document.getElementById("'+o+'").style.display="none"');}
    else
    {eval('document.getElementById("'+o+'").style.display="block"');}
    } // Breitenänderung beobachten
    const mediaQuery = '(min-width: 910px)';
    const queries = window.matchMedia(mediaQuery);
    queries.addEventListener('change', event => checkMenu('site-header-menu'));

    To the body tag in the header.php i added:

    onload=”checkMenu(‘site-header-menu’)”

    And furtheron in the header.php i added to the toggle-button

    onclick=”einaus(‘site-header-menu’)”

    If you have a better solution, let me know …

    Thread Starter 182tage

    (@182tage)

    Thank you for taking that further look. When i switch back the theme, the trouble is back. The full menu is shown on mobiles (<910px width) and toggling does not work. On desktop version everything is fine. Could you tell me in which context that 404 error is thrown? Any idea how to check the javascript backbone?

    Thread Starter 182tage

    (@182tage)

    Hi jordesign,

    thank you for answering. I implemented this section because of the problem. Because the menu was shown while toggling does not work on mobiles I hided the menu and secondly also the menu button for mobiles. For a review of yours I will restore the formerly bad status for a few days tomorrow.

    Meanwhile I also validated css and html and checked JavaScript but did not find any cause. The problem appeared suddenly and I have no idea why.

    Thread Starter 182tage

    (@182tage)

    Thank you Alvaro, this was indeed a solution. It is surprising and so embarrassing simple. The theme twentysixteen has a standard black background generally and the div “site” has a bit less height. So in addition better take

    body { background: #ffffff !important; }

    Thread Starter 182tage

    (@182tage)

    You might not understand the problem which is the resisting 5px black border/stripe on top and bottom of the theme page. It has nothing to do with the general background color of the page.

Viewing 8 replies - 1 through 8 (of 8 total)