joevansteen

Thank you!

Thank you very much!

Thanks! I mainly wanted to ensure it was on your list. It looks to be a simple fix. You have a check for null a few lines away, along with a check for empty, but don’t take any action to change the null to empty which would eliminate the message. I prefer code which doesn’t generate error (or warning) messages, so will look forward to your update.

I am currently running PHP 8.3 but the errors first appeared when I upgraded thru the 8.2 level. In the dashboard if your PRO module is activated I get the following errors (note display errors must be activated). When I deactivate your module the errors disappear. What I get is the following:

Deprecated: Creation of dynamic property ACF::$fields is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/fields.php on line 138

Deprecated: Creation of dynamic property acf_loop::$loops is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/loop.php on line 28

Deprecated: Creation of dynamic property ACF::$loop is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/loop.php on line 269

Deprecated: Creation of dynamic property ACF::$revisions is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/revisions.php on line 387

Deprecated: Creation of dynamic property acf_validation::$errors is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/validation.php on line 28

Deprecated: Creation of dynamic property ACF::$validation is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/validation.php on line 215

Deprecated: Creation of dynamic property acf_form_customizer::$preview_values is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-customizer.php on line 28

Deprecated: Creation of dynamic property acf_form_customizer::$preview_fields is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-customizer.php on line 29

Deprecated: Creation of dynamic property acf_form_customizer::$preview_errors is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-customizer.php on line 30

Deprecated: Creation of dynamic property ACF::$form_front is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-front.php on line 600

Deprecated: Creation of dynamic property acf_form_widget::$preview_values is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-widget.php on line 34

Deprecated: Creation of dynamic property acf_form_widget::$preview_reference is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-widget.php on line 35

Deprecated: Creation of dynamic property acf_form_widget::$preview_errors is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/forms/form-widget.php on line 36

Deprecated: Creation of dynamic property ACF::$admin_tools is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/admin/admin-tools.php on line 282

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/core/Libraries/Plugin_Update_Warning/Plugin_Update_Warning.php on line 12

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Container.php on line 36

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Datastore/Datastore.php on line 79

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Field.php on line 56

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Container.php on line 36

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Datastore/Datastore.php on line 79

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Field.php on line 56

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Container.php on line 36

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Datastore/Datastore.php on line 79

Deprecated: Calling get_class() without arguments is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/carbon-fields/vendor/htmlburger/carbon-fields/core/Field.php on line 56

Deprecated: Creation of dynamic property acf_field_oembed::$width is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/fields/class-acf-field-oembed.php on line 31

Deprecated: Creation of dynamic property acf_field_oembed::$height is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/fields/class-acf-field-oembed.php on line 32

Deprecated: Creation of dynamic property acf_field_google_map::$default_values is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/fields/class-acf-field-google-map.php on line 33

Deprecated: Creation of dynamic property acf_field__group::$have_rows is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf/includes/fields/class-acf-field-group.php on line 31

Deprecated: Creation of dynamic property mapster_acf_field_map::$settings is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf-mapster-map/fields/class-mapster-acf-field-map-v5.php on line 75

Deprecated: Creation of dynamic property acf_field_photo_gallery::$settings is deprecated in /www/…/public/wp-content/plugins/mapster-wp-maps-premium/includes/acf-photo-gallery-field/includes/__construct.php on line 22

Yes, 1.2.39. I believe it worked when I upgraded to 8.1, but produced diagnostics at 8.2. I did this with a site at Kinsta.com using their site management tools.

Your message about using a UTC timezone offset such as “America/Los_Angeles”. might want to actually show a UTC timezone as the “do not use this format” rather than using a geographic timezone two times, which is confusing and ends up saying nothing to the reader.

“Support” seemed to me to be the most logical place to put a suggestion to update the code which produces the message.

Sorry if that wasn’t clear. I thought you would recognize the display message coming from your own code.

• This reply was modified 1 year, 8 months ago by joevansteen.

@dglingren On re-reading of your last comment you seem to be implying that any mime type added by another program dynamically will be incorporated into your own table. At some point perhaps I’ll try to find the time to test that.

I appreciate your plugin and your attempt to make this right; but spending more time on it isn’t my highest priority.

@dglingren I apologize and stand corrected on the correct mime type for GEDCOM files, it is text/plain.

I’m also going to close this because it is using too much of my time. I’m caught here in the middle of a problem between two plugins which I’ve tried to use, neither of which is mine. Trying to reproduce errors that emanate from an attempt to artificially re-create problems in not an effective use of my time, or yours.

When looking at your new code, you still appear to be registering your mime_types filter with the highest priority making it the last filter used by WP. (Something which should be unnecessary unless you have a very real need to do so.) And, you (still) seem to be replacing rather than appending the mime types array supplied as an input parameter to the filter. (Possibly related to why you found it necessary to use the high priority.) Am I wrong on these points? If so, again, I apologize for misreading your code.

If I am not wrong, that coding strategy, IMHO, is a problem for anyone attempting to use their own use of the filter to supply a mime type of a variety unknown to your program. That, IMHO, would be a problem with integrating MLA with a program that might want to dynamically define those other types unknown to MLA. Such as ‘atom’, ‘ecma’, epub’, ‘json’ or a host of others.

Thanks for bearing with me, but I really do have other fish to fry.

@dglingren

Using your new version, which includes a ‘ged’ entry in your internal tables, the GedShow program seemed to work for me. However,

• trying to override your ged encoding with my own, making the mime type ?application/octet–stream (potentially the correct encoding) I again get a fail.
• making your ‘ged’ type inactive, since I could not delete it, to mimic the case where a mime-type unknown to your program is attempted to be added by someone other than you, again fails.

Just changing your coding from plain text to octet isn’t really the issue for me. I don’t know how or why you think that is the right way to go. You should allow any other program to handle any mime-type they want, and still be able to use the WP filters in the manner the GedShow plugin was trying to do. I have other mime-types unknown to you in my media library and you ignore them just fine, but the code for those types is accomplished in plugins which don’t use the same WP filters and hooks. I haven’t tried to debug every one of them, but just as I mentioned to the GedShow author, RootsPersona had no trouble with ‘ged’ as a filetype to upload because they simply didn’t depend on WP filter handling to process the file. For anyone that does, like GedShow, your plugin breaks their code. That second case above, IMHO, is the bigger problem.

Why did you think you needed to add a ‘ged’ type? You are taking over the responsibility as the authority for any and all mime-type that utilize the WP mime filters. That ain’t friendly, and it isn’t the way I understand WP is supposed to work.

I would assume that if you remove the ‘ged’ type from your own internal tables your test should fail the same as mine. That should be your test to see if you’ve made your code accommodating for others.

@dglingren?You are welcome. At first I thought some of the behavior was random based on the order in which co-equal upload_mimes filters were executed. However, I also see that you have set a maximum high priority on your filter, making almost always assured to be the last filter executed, thus ensuring the behavior specified above. I seriously doubt many other plugins specify as high a priority as yours. I don’t know why you coded it this way, but in this form, if my analysis is correct, your plugin will conflict with every other plugin dependent on the upload_mimes filter that tries to register and use a file extension which you do not have in your own tables.

@colinsp You are welcome, and I apologize for pinning the blame on you in my opening salvo. I’m looking forward to v2.0.18 and will be happy to upgrade my rating on arrival.

I sincerely appreciate your response to the concern about defensive programming whenever possible and listening to the concerns of your users.

@colinsp I appreciate your patience with me. I am now of the opinion that your code is probably technically correct, although using the parameters on the calls instead of depending on the filter would probably bypass the problem with MLA, and anyone else who might have a conflict. You force the use of the upload_mimes filter twice in your logic, which should be okay, but it exposes the following.

@dglingren I have also looked at your code and see that you also apply the same upload_mimes filter to inject the mime-types which have been identified as per your instructions. However, in class-mla-mime-types.php in the mla_upload_mimes_filter (367-424) function you have a set of logic which appears to function on a “first-time” basis, and on subsequent calls it simply returns the mime-type array which was provided on the call, rather than adding supplementary items, again, to the list provided as the input array. This first time type behavior seems to match the results which I get when I execute GedShow logic with a ‘ged‘ mime-type specified as an MLA override type as you described in your solution linked above.

From my inspection of this same code, you also, on the first call, seem to ignore the mime-types provided as an input parameter and instead return a new mime-type array built to match your own extended list. That would also match the behavior where if a new mime-type (not identified to MLA but added by others, GedShow, or the File Upload Types plugin, gets ignored, assuming my reading of your code is correct. This would identify the problem behavior I’ve documented as well as problems previously identified by others regarding incompatibility between the two programs.

• If MLA is not present, the ‘ged’ type supplied via another plugin’s upload_mimes filter (GedShow, File Upload Types, etc.) works.
• When ‘ged’ is identified as a mime-type by others, but not MLA, the first check fails.
• When ‘ged’ is identified to MLA the first check works, the second check fails
• Bypassing the requirement and providing the ‘ged’ mime on the two calls should also work, but shouldn’t be required since WP defined practice provided for either as a programming choice. Defensive programming might suggest whether GedShow should be changed or not.
• Bypassing some of the WP functions and using PHP directly to open the file also works.

I really don’t have the time of patience to do a lot more of this, but changes to the code don’t seem too big for either, or both, of you to try; and from the GedShow trouble ticket history I don’t seem to be the only one affected who desires to use both plugins.

I hate WordPress. It’s programming in a totally chaotic environment. Yet, it seems to be a bit like democracy, the best of a bad lot of choices; and it seems such an appropriate tool from the other side of the screen. Yin/Yang.

• This reply was modified 1 year, 8 months ago by joevansteen. Reason: "Best" not "Beast" of bad choices

Again, the problem, IMHO does not belong to MLA, although there may be some aspect where they might improve their own code too.

Your code in GedShow rejects first with the error “You must upload a gedcom file with an extension of ged (in lowercase). If your WordPress install is multisite please see the Gedshow FAQ.” based on your use of

$file_type = wp_check_filetype($ged);
 	if (($file_type['ext'] !== 'ged')) 

on lines 337-338 of csgen.php because you do not supply the (second) mimes parameter, leaving the mime type processing to become WordPress default processes. WordPress does not have a ‘ged’ type, so somebody else needs to provide it, since you don’t do it yourself. This requires some other facility to do it for you. MLA is one such facility as described by David Lingren, above. File Upload Types is another such plugin facility. Disabling MLA and using File Upload Types is one answer, but then I lose MLA and have the hassle I identified in my OP.

Adding ‘ged’ as a MLA filetype still has problems because your next action on line 344 is

$uploaded = media_handle_upload('ged_upload', 0);

If I add it to MLA as David identifies, I get past the first error (which was, I believe, previously addressed in https://www.ads-software.com/support/topic/trouble-with-a-ged-upload/) and I get the new error ‘Error uploading file: Sorry, you are not allowed to upload this file type.‘ from line 344. The reason for this is that media_handle_upload() calls wp_handle_upload() which again checks for a valid mime type, but differently since MLA with a ged mime-type gets past the 337/338 check but not the 344 line.

The other reason for this is that again an opportunity exists to supply an override parameter to allow for the ‘ged’ mime-type which you chose not to supply on 344. (You supply a 0, taken as ‘false’, in place of an overrides array which could (should) include a mimes override. [See https://developer.www.ads-software.com/reference/functions/wp_handle_upload/%5D)

If your code were to simply supply the overrides using parameters which you are not using I suspect that not only would the conflict go away, but the need for external plugins to supply a ‘ged’ mime-type for your use would not exist.

Re: MLA, a note to David Lingren, I suggest you may want to look at the detail docs for _wp_handle_upload to see if you are hooking all of the mime-type verification hooks. But I also suggest that GedShow should have supplied the mime overrides to begin with and there would be no need for users to work around the problem.

Another alternative, which works, is to bypass some of the WP build in functions and read the file yourself with fopen(), but that is another whole strategy which you’ve obviously chosen not to follow. As is, with both GedShow and MLA in play, I have to disable MLA every time I want to upload a new, or updated, GEDCOM file for processing. Not cool.

Whose problem is it? Right now it belongs to anyone who wants to use both plugins.

• This reply was modified 1 year, 9 months ago by joevansteen.
• This reply was modified 1 year, 9 months ago by joevansteen.

If you are going to operate in a mixed environment such as what exists in the world of WordPress plugins, and you can code such that others cause problems for what you are doing, or if it is possible to code such that you can co-exists, and you chose to simple take the approach that it’s the other plugins problem, you are doing a great disservice to anyone who might benefit from your plugin. Clearly, as I have indicated and it is demonstrated by another plugin which processes the exact same GEDCOM file which your plugin does not, it is not really the problem of MLA, I for one, (who have been doing IT since 1970 an a wide variety of environments) consider the issue yours, not theirs.

Regarding the double quote, single quote comment I had your shortcode coded with double quotes on the parameters and failed to get it to function (after getting past the MLA problem by de-activating MLA). I changed the shortcode to use single quotes and obtained a proper display. I won’t swear to the problem, I’m just reporting, honestly, what I experienced.

Not everything I said about your plugin was negative, or I wouldn’t have given it a 3, it would have been lower. Compatibility in WordPress requires giving grace to others and not just saying it’s their problem not mine. If it doesn’t have to be anyone’s problem, why leave your code the way it is and make the problem an issue for the user?

MLA doesn’t prevent RootsPersona on the same install from uploading the same file; that, to me, makes the problem more yours than theirs. Why don’t you research their code (also open-source) and fix the problem in your plugin so the conflict doesn’t exist?

I have shortcode issues of my own from old code which I am trying to clean up ??