Solved bug after update 10.0.14

input date missing END

Hi I found a bug and have a solution I think.
The calendar didnt word correctly after the update with the input date. The template FORM_SCREEN_INPUT_DATE.tpl has a fault. I changed it to the old template and noticed there is an {+END} missing on the end
That solved my problem!

Correct template from the old version 10.0.13 is: https://thepasteb.in/p/O7h5XgAQpj6Sq
Thanks for the great website!

Hi kreek,

Thanks for posting that.

I think this may have been a file corruption issue, as I couldn't reproduce or see a problem in the file. We did change the file, likely it corrupted when extracting to your site.

Chris Graham said

Hi kreek,

Thanks for posting that.

I think this may have been a file corruption issue, as I couldn't reproduce or see a problem in the file. We did change the file, likely it corrupted when extracting to your site.

From “Post #4,219”, 28th March 2018, 12:52 am

Hi Chris,

Thanks for your quick respons,
It happende actually on two community websites. Do you have an idea where I can find the corrupted file?
Also I lost a few categories in a a catalogue.
And in the Member boxes all custom profile fields are missing.
When I try to change a members profile the custom fields are empty. I see this warning:
Is it maybe the same corrupted file?


An error occurred when loading this screen onto the web browser. You are being notified of this as you are staff. If you believe this is a bug in Composr, please contact the developers with full details. More details are available in your browser's error console. The error was:

3: Uncaught TypeError: $(…).inputDate is not a function

Ergh, that's an assortment of issues .

You can always find the original files in the manual installer, available from the download page. You can just copy them (individually) out of there. And the integrity checker feature in the upgrader will indicate if a file is not correct.

Categories should definitely not disappear during an upgrade, especially just a patch release. I'm not sure I can speak to what would cause that, it's not something I've heard of.

If you'd like me to look directly on the server to see what is wrong, email access details to chris@ocproducts.com.

All I can think is if perhaps you upgraded manually by uploading changed files by FTP and selected 'resume' rather than 'overwrite' in the FTP program, which would fail for any files we've made smaller (the FORM_SCREEN_INPUT_DATE.tpl got smaller). But that seems like a long shot, I'd be surprised if you did an upgrade like that.

Hi,

This is mainly for anyone else reading…

I'm working with kreek on this.

There is a bug, not really related to anything discussed above. The fix is:
https://github.com/ocproducts/composr/commit/5c2c6c00e0cda17df0acd782736061a090a8bd27

I think it only affects users with the self-learning cache not enabled.

The problem is that we preload some JavaScript files used by the profile editing when opening the initial profile view tab. This is in case something goes wrong dynamically loading them later when switching tabs. However, some of these files depend on jQuery and will fail to load without it, and we were not preloading jQuery. Then when the tabs do try and load their JS files the files that already failed to load don't reinitiate.

With the self-learning cache the system would learn on it's own that the tabs will use jQuery and adapt. I think so anyway, I think that's why I could not reproduce an issue before.