OnePressTech

Hi @joyously. Thanks for that.

Can you clarify your last sentence for me please

And if the theme doesn’t use the hook, the child theme and plugins can’t remove the theme code

.

The child theme and the plugins can always hook after_theme_setup and override anything the theme makes overridable whether the theme uses after_setup_theme or not. As I stated previously the theme loading-process is sequential and all a theme really does is load resources, hooks and filters. Anything that can be overridden…can be overridden whether the theme hooks after_setup_theme or not.

I’ll give you an example…add_theme_support( 'post-thumbnails' );

If a plug-in or child-theme wants to override the theme and disable post-thumbnails for some reason then they hook after_setup_theme with a function that calls remove_theme_support( 'post-thumbnails' ); It wouldn’t matter whether the theme invoked add_theme_support( ‘post-thumbnails’ ) in functions.php or a function hooked to after_setup_theme;

Could you please give me a counter-case…something that can’t be done by a plug-in / child-theme if the theme does-not hook after_theme_setup. I’m not being disingenuous…I can’t find any technical reason for a theme to hook after_theme_setup. The purpose of this post is to double-check find a counter-case if my assumption is faulty.

Thanks again for your thoughts. Much appreciated.

Hi @joyously…thanks for your help. Much appreciated ??

I appreciate that everyone believes this practice adds value but no one explains why that is the case for a theme. The plugins and child theme load before the theme and can hook after_setup_theme so they can make adjustments before and after the theme loads whether the theme hooks after_setup_theme or not.

So the loading sequence is:

plugins / child theme / theme /

and the theme hook sequence is:

setup_theme / theme processing / after_setup_theme

So you can see that in a sequential processing model there is no after_setup_theme hook value for a theme. There is after_setup_theme hook value for plug-ins and child themes who want to override the theme but there is no value I can see for a theme to hook after_setup_theme.

Can you think of a use-case that requires the theme to hook after_setup_theme?

Thanks in advance.

Hi Joy…thanks for reaching out to assist. Much appreciated ??

The theme returning immediately without bothering to load its resources on the server side should not affect client side use of the heartbeat. The response to the heartbeat is actually done by the WordPress core later in the loading sequence after the theme has loaded. And the WordPress loading sequence is sequential so plugins and child themes have already been loaded at this point. Good suggestion though.

I hypothesise that the core designers provided a heartbeat call to the Theme via functions.php as a standard optional feature for themes to use without having to create their own heartbeat equivalent should they have a need for a heartbeat. If the theme has a use for a heartbeat it hooks the heartbeat and attaches extra data to the heartbeat subsequently returned by the core and / or uses the heartbeat trigger as an event to execute conditional logic.

I get that.

But if the theme does not use a heartbeat for any reason I don’t see the value in loading all the theme resources on the server side since they won’t affect the client side.

My purpose for this post is that I can’t think of a reason a theme’s functions.php should not return immediately on an unused heartbeat and am reaching out to others to verify my assumption.

You are the first of hopefully many that will lend me sage council. Thanks again ??

Cheers @catacaustic. I agree with your assessment. Every little bit helps though ??

My primary motivation was actually code operation clarity…to clarify all the steps in the theme loading sequence and why. My secondary motivation was to simplify debugging (fewer breakpoint triggers when in xdebug mode).

Thanks for replying…I wanted to make sure that others were not aware of any side-effects of ignoring heartbeats in the functions.php file. Much appreciated ??

Appologies…the previous comment should have started with …I just upgraded to the 5.0 Alpha release…

Typo.

We have this issue as well.

The issue only started to occur when we updated to V1.7. This was not an issue with the previous releases <= v1.6.14.

I took a look at the source code delta (v1.6.14 –> v1.7) and it was clear that adjustments were made to the code in the area of new user notifications but nothing jumped out on first review as a potential culprit.

One possibility to consider is that this is a multi-site issue (our site with the issue is a multi-site).

We will do a test on one of our single sites to determine if this is a general issue or a multi-site specific issue. I will add an update to this forum thread once we have done the tests.

In parallel you might also do a multi-site test.

Thanks in advance for your assistance and all your hard work on this plug-in. It is a very good plug-in and we appreciate your hard work on it. Thank you ??

Kind regards,
Tim (OnePressTech)

Cheers @andergmartins…the fix is much appreciated ??

The problem is not resolved. I just added some custom code to my non-www.remarpro.com theme to support one-buttonpress updates and had it working except for this strange error that 8 seconds after the themes pages is displayed with update notices for the theme(s) the notices disappears! I thought it was my coding error or a core check I had missed. But after exhaustive debugging I finally figured out it was a PublishPress error.

The problem is that the publishpress/modules/modules-settings/lib/modules-settings.js AND the publishpress/modules/settings/lib/settings.js files contain a publishpress_hide_message function that hooks to ‘.notice’. You need to hook to a class that is specific to your plug-in please…you are removing notices that are not set by your plug-in

Thanks in advance…much appreciated ??

It only took me 15 minutes to verify my theory that this is likely a view code error. I changed wsal-items-per-page from 5000 to 10 and verified that there were only 10 entries in the database as expected.

When I look at the 10 entries using different views I see a correct result when sorting by Code and by Date and duplicated entries with incorrect dates when I sort by Username or by SourceIP.

I notice in AuditLogListView.php there are a number of “ToDo” comments related to…Sortable View based on Username or SourceIP…hmmm a bit suspicious!

Can you guys take another look at AuditLogListView.php code. When you tried to reproduce this issue did you try it on multi-site on php7? There have been some changes in php7 related to the logic involved in the display of these sortable lists.

Cheers guys. I didn’t know you could not reproduce this. I asked twice but you never said you tried.

I’m analysing the view source code. As the data I sent you indicated I doubt this is a duplicate data issue but rather a view issue. If this was a duplicate data issue we would see the duplicates in different views. In fact, as I said, we don’t see the entries in one view that we see in the other view.

I’ll let you know what I find.

Thanks guys but I don’t send credentials and I don’t send database dumps.

I’ll obviously have to debug it myself when I get some spare time. Based on the data I sent you I’m pretty sure I can find the bug through code analysis. In the 35 years I have been shipping telecom firmware, software and internet software I have managed to solve every problem reported by my clients with no data, no login, and no client interactions…just the bug reports. Based on the problem manifestation I have recorded here I expect this to be pretty simple to solve through code analysis.

Don’t think me unappreciative…you have my thanks and respect for providing a great open source plugin. It will just take me less energy to go into your code and find the bug then to follow the debug approach you are taking. No disrespect intended ??

I’ll let you know the outcome when I get the time to solve the bug.

Cheers

I provided the additional information to try to reduce your debugging burden. More info is usually better than less info.

We have…
a) The database has more entries for an IP address than are displayed in the IP sorted view
b) The lead display entry on the IP address sorted view does not appear in the Date sorted view
c) Duplicated entries in the IP sorted view but not in the date-sorted view

I would suggest that you consider than these are not “different” problems but just different manifestations of the same logic bug. I could be wrong but it is a reasonable initial assumption. I am puzzled that you cannot reproduce this!

I will defer to you on next steps you would like to take in solving this…I do appreciate your time investment…thanks in advance…much appreciated ??

Yes…this effect applies to all entries regardless of type.

Here are some other oddities I notice:

1) In the initial screenshot I provided to you I am puzzled why the first IP address that appears when I click “sort by IP” is 31.207.194.33. This is clearly not the lowest IP address if you look at the following IP addresses in the screenshot

2) I sorted by date and then paged to the location where the 02-22-2017
6:46.251 AM 31.207.194.33 entry would be and….interesting…it is NOT displayed! See screenshot #2 below:

So I did a database search on 31.207.194.33 and there were 6 entries in the database…but only 2 instances are displayed when I sort by IP address! So the plugin seems to have some orphaned entries in the database or entries with missing fields so you see some of the entries under one view and other entries under a different view.

Can you please confirm that you have tried to reproduce this. I am assuming you run your own plug-in on your own company’s website. Do a sort by IP address and a database search on the IP address of the first entry displayed and see if the number of entries tally. I would be surprised if you can’t reproduce this. Cheers. Thanks for your help…it is much appreciated ??

Cheers Jan…I was going to say no to the request anyway ??

I agree with you. I find too many theme and plug-in authors jump immediately to the “give me credentials” request.

I’m actually a tech-savvy user so if the author wants to point me at a likely section of the code I can add some extra debugging to try to narrow down the problem area.

To be honest I would think that locating a duplicate display entry would be reasonably straight forward from a code analysis perspective.

I guess we’ll find out ??

NOTE: This is a multi-site installation with the plugin network enabled.