mbsharp

A bit more on this.
EntryWizard now requires php7.4. As far as I can see from other plugins, this is unusually high. If EntryWizard is active and the site tries to run under an earlier php version, the site crashes because of a version check in EntryWizard. If EntryWizard is inactive under eg, php7.3, EntryWizard cannot be activated.
My hosting provider only certifies its php installation up to php7.3 but they have an uncertified version of php7.4. I have to provide an AddHandler directive in .htaccess to use php7.4.
Running php7.4, I then had a critical error with the WordPress update to 5.8.3 which the provider admits is probably down to its php7.4 configuration.
My workaround was: Under php7.4, deactivate EntryWizard; revert to php7.3; update WordPress to 5.8.3; set the site back to php7.4; reactivate EntryWizard. A long way round, but does EntryWizard actually require php7.4 ?

closed

It looks like downstream s/w is variable in how it handles a field which might look like a date. I only logged this for the record so that others can recognise the problem if they meet it.

That’s odd. As noted the fault appeared as soon as I added the Conditional Fields plugin to a site which had not used it before. It may be an interaction with another plugin. But, as the warning is irrelevant and can be ignored I will just live with it.
Regards

Thank you for responding.
On the affected site I have two forms both using the same conditional fields settings. One group field is displayed if a particular string is typed in an earlier field. The particular string may be any of 15 possibilities so there are 15 rows in the conditions.
I added conditional-fields to my other site and created a new CF7 form with one group field to be displayed if one possible string is typed in an earlier field.
The Unsaved Warning now appears on this other site after adding conditional-fields.
The warning appears even if you just open a form for editing and do nothing before navigating away elsewhere within the dashboard.
Operationally this warning can be ignored as it has no effect on the use of the forms. It is just that presumably some flag is not being set correctly when the CF7 form is saved.

PS. To be clear the warning message is in the backend editor and not in operational use.

It may be easier to set the upload limit in your php.ini file. A bit easier to see and edit than .htaccess

You are right that a very big zip file may fail for either size or timing. There are two ways round this.
One is to log onto your hosting account and use FTP to recover the files.
The other is to use the list of filenames in the download spreadsheet to automate file copying from the website to a local folder. The web folder is always the WP root folder followed by /wp-content/uploads/ewz_img_uploads/ followed by a folder named as the event code (available via the download spreadsheet) followed by the image filename (available via the download spreadsheet).

See my reply to your separate query.
Don’t expect EntryWizard to do everything for you. If you need files named in a specific way, create those filenames by renaming after download using data from fields you can include in the downloaded spreadsheet.
I also translate the WP user account to be a preferred version of the entrant’s name.

There are a number of favourite systems used in the UK. DiCentra; Film Free Projection; ImageCompPro; PhotoComp. Their usage clusters geographically due to local recommendations. There are others, and some Clubs have written their own bespoke systems which does worry me about support and handover.
The best camera is the one you have with you. The best competition software is the one you are used to using (especially when that is in the dark). My club uses ImageCompPro which I think has enough functionality without being overcomplex.
I would far rather have multiple software products used in series with each separately modifiable, than try to cram every requirement into one system. For me, EntryWizard and ImageCompPro are just some of my systems. I also have several using Excel VBA including entries collation, a scoring machine, and post-competition analysis.

I have found another way to remove that line of HTML.
Long ago I had a conflict between the LCP option content=full and any gallery on the same page using NextGen Galleries. Ever since then I have used the combination of excerpt=yes excerpt_size=999 excerpt_strip=no is my LCP shortcodes.
Just gone back to trying content=full instead of the excerpt workaround. The conflict with NextGen is not there any more; the stray Continue Reading line isn’t generated and a couple of other empty paragraphs have been removed too.
So, I will reconfigure my site to use content=full throughout.

Using LCP v0.81, WP 5.4, PHP 7.2
This problem has just arisen on one of my sites after updating Weaver Extreme theme, but is not seen on another using Nirvana theme. It may therefore be a theme interaction.
The ‘Continue Reading’ line with its link is generated on only my Weaver site as an anchor element using the ‘more-link’ class and the link text within a span element with the ‘more-msg’ class.
Although I cannot currently prevent the line being generated, I can hide it by adding this line to my theme’s custom css:
span.more-msg {visiblity:hidden;}
Don’t confuse this issue with the morelink, morelink_class and morelink_tag options provided in LCP which generate yet another line of HTML.

Progress report.
When I saw the two messages during the attempt to replace a zip file, I was reluctant to proceed.
I have now tried actually replacing a zip file (same filetype and name), and the replacement does work despite the two messages.
I have not tried replacing a zip file with a differently named zip file.

A further thought.
The workaround shown above will not work for many installations.
The media library is commonly filed by year and month. Deleting the zip file in the media library and then reloading it as a new file will change the upload folder where the zip file is stored, and break any links. It is why ‘EMR’ is so useful, and why it is very inconvenient if it doesn’t work.

Can I say that this issue is not resolved.
I can upload a zip file to the media library. Contrary to a number of available comments, zip is a permitted file type for media in WordPress.
However, if I try to replace a zip file in the library using ‘EMR’ then there are two messages. One that the file type is different (which it is not) and the other that the file type is not allowed (which it should be).

Using EMR version 3.3.11 on WP5.4, PHP 7.2

I agree that there is the workaround described above, but I suggest EMR should respect the permitted file types.