Jürgen

Hi properlypurple, I was afraid of that… too bad…

I’m not a fan of installing a plugin for every small problem, because the stability, performance and maintainability of the site decreases with every plugin…

…I’ll then try to expand the standard list block accordingly ??

I found the Problem ?? There was a filter ‘wp_mail_from’ set by an installed plugin. This removed the default sender address ??

The decisive factor was the error log without which a problem cannot really be solved ??

• This reply was modified 1 year, 3 months ago by Jürgen.

Thanks for the tip… but that doesn’t really help… it just shows that there are a lot of problems here that have existed for many years and have never been solved.

I now have an error log showing that the “From” address is missing.

[20.08.2023 07:19:04.000000] [ERROR] WP_Error Object
(
    [errors] => Array
        (
            [wp_mail_failed] => Array
                (
                    [0] => Invalid address:  (From):
                )

        )

    [error_data] => Array
        (
            [wp_mail_failed] => Array
                (
                    [to] => Array
                        (
                            [0] => [email protected]
                        )

                    [subject] => Test Mail
                    [message] =>  This is the test mail from Trimension
                    [headers] => Array
                        (
                        )

                    [attachments] => Array
                        (
                        )

                    [phpmailer_exception_code] => 0
                )

        )

    [additional_data:protected] => Array
        (
        )

)

There is a comment on this that is 7 years old and describes that the sender address has to be predefined as a variable since WP version 4.6… but obviously it isn’t.

For testing I use the “WP Test Mail” plugin… this does not transfer a From address in the header and therefore probably doesn’t work.

Contact Form 7 passes the wp_mail function a correctly filled headers array, which also contains “From: “. Still the same error flies… The from is either removed or doesn’t arrive.

And BTW How I wrote, PHPs mail works fine directly called from any script ??

• This reply was modified 1 year, 3 months ago by Jürgen.

Hi…

seems to be fixed…

Plugin updated, Option activated and I no longer get any more PHP warnings from the cron jobs

Many Thanks for the really quick help ??

• This reply was modified 1 year, 3 months ago by Jürgen.

Hi Thorsten,

Yes, I’m well aware of that… but it’s time-consuming and ultimately just a crutch…

The plugin does not distinguish between ‘spam’, ‘trash’ and ‘normal’ comments when deleting IPs and deletes all existing, which is probably not even necessary…

A better solution would be not to save the IP address at all for NON-Spam comments in the first place. Storing spam comments with IP addresses should not violate the GDPR as there is a continuing legitimate interest here (Blacklist)

But the problem is that I don’t have a hook that would allow me to remove the IP address after the spam checks but before saving…

The correct hook would be “preprocess_comment” but the spam checks happen later so I don’t know which IPs to delete and which not. The “pre_comment_approved” hook would be suitable here, but unfortunately it only filters the spam identifier itself… The comment data cannot be manipulated here ?? It should happen between the “pre_comment_approved” and the save into the db…

Hence my question, is there a way to implement this, because that would be the cleanest solution, I think ??

The behavior and semantics of the two “required” attributes are different. It’s not just about the styling. reqired is the modern html5 attribute, aria-requird is not html5-conform…

The user should be able to decide for himself which variant he uses, perhaps via an additional setting.

ja, das w?re klasse… es würde ja schon helfen, wenn die nicht immer prominent im ersten Popup stehen würden… da sollten eigentlich die letzten 6 benutzten Bl?cke stehen, oder die 6 am meisten benutzten Bl?cke… sonst würde dieses Vorschau-Fenster wenig Sinn ergeben und man k?nnte gleich immer in die vollst?ndige Liste wechseln…

Viele Grü?e
Jürgen

Hello Felipe,

thanx a lot… thats it! activating the checkbox in the screen options makes the post type visible and choosable for the menu… simple and without any changes in the code ??

I didn’t thought about the screen options (it’s not the first time) …

another solution would be a manually update to the Database:

update the saved array in the table xx_usermeta -> key: ‘metaboxhidden_nav-menus’

Hello,

yes… thats right…
the function wp_nav_menu_setup() calls the method add_meta_box() for my new custom post type and its in the final list. But…

the subsequent call of the function wp_initial_nav_menu_meta_boxes() markes this box as hidden (!), because the new type is not in the fixed defined initial_meta_boxes array.

I could workaround this problem by using the filter-hook ‘hidden_meta_boxes’. The filter removes the new Custom Post Type Meta Box (add-post-type-product) from the hidden meta boxes array…

It works but it’s just a workaround. The box will be created, marked as hidden and the filter remarks it as unhidden…

I cannot see the meaning in that Logic. All new Posttypes will be set from the add_meta_box() function but marked as hidden so that it is never ever possible to add an archive of this post type to the menu…

Is there a better solution ?

• This reply was modified 6 years, 6 months ago by Jürgen.

Hello,

yes… thats right…
the function wp_nav_menu_setup() calls the method add_meta_box() for my new custom post type and its in the final list. But…

the subsequent call of the function wp_initial_nav_menu_meta_boxes() makes this list entry hidden (!), because the new type is not in the fixed defined initial_meta_boxes array.

I do not understand the logic, but the result is not what I want:

$initial_meta_boxes = array( 'add-post-type-page', 'add-post-type-post', 'add-custom-links', 'add-category' );
$hidden_meta_boxes = array();

foreach ( array_keys($wp_meta_boxes['nav-menus']) as $context ) {
	foreach ( array_keys($wp_meta_boxes['nav-menus'][$context]) as $priority ) {
		foreach ( $wp_meta_boxes['nav-menus'][$context][$priority] as $box ) {
			if ( in_array( $box['id'], $initial_meta_boxes ) ) {
				unset( $box['id'] );
			} else {
				$hidden_meta_boxes[] = $box['id']; // !!!
			}
		}
	}
}

$user = wp_get_current_user();
update_user_option( $user->ID, 'metaboxhidden_nav-menus', $hidden_meta_boxes, true );

• This reply was modified 6 years, 6 months ago by Jürgen.
• This reply was modified 6 years, 6 months ago by Jürgen.

SOLVED ! Mistake of mine !

The Problem was, the Webserver-Config’s Security Settings for “hot-link prevention”. There still worked a RewriteRule against the Development-Server’s URL.

Thanx all…
This was a really great monologue ??

but maybe helpful for someone reading this.

I found out, that the Links in the final HTML Page are korrekt and the URL’s are reachable, when I put them directly into the Browser’s Address Line.

The whole site is running under SSL (HTTPS) and all the (internal) links use https-urls, also the media-files. When I change the media-URL to http: directly within the Browser’s Development Tools, the images will be displayed.

I do not understand this very exotic behaviour, because this works at the other (dev) system very well…

Anybody any idea ?

Using WP 4.4 !!
home and siteurl options set to https://local.test.url

this is not a public url. its a local url within the local private network. I installed a virtualbox server to test the new developed theme. the public site is still a static site, which should be replaced later with the new wordpress installation.

My problem is the initital moving from the development server (local vm) to the testing (staging) server which is another local vm and later to the production server which is a real dedicated server.

to solve the problem is primary to understand, how wordpress handles the media files both, within the media library and the template processing.

the configuration moved works fine on the development server, therefore I cannot understand, why the copied installation is not working on the destination server. I changed all the url’s (except the guid’s) in the database but it seems that this is not enough.

I have to compare again the dev working installation with the new test configuration and then I will try to analyze the code to understand how it works to find the problem.

I’d be very happy about any kind of helpful information about the technical process to handle the media files.

The Plugin just implements the functionality to make a Custom Post ‘sticky’. It handles custom-post-stickies the same way like normal post stickies. Therefore it does not affect the query, but just put the custom-stickies in the options-list.

I do not know, why this query worked before. The post__in filters the resultlist and accepts only posts contined in the list. Your query above filters the result list against the sticky-options-list. I would guess, that this query only finds your ‘deal’ stickies. See the post: Sticky Posts and Pagination again
This should solve also your problem here.

There are lots of problems caused by the wrong sticky-design in wordpress-core. I hope that it will be fixed within the core on one of the next releases, then plugins like the ‘Seamless Sticky Custom Post Types’ will be unnecessary.

Another Tip: try to reinstall the plugin