← Back to Field Masking Support
Root composer.json requires albrightlabs/fieldmasking-plugin ^1.0, found albrightlabs/fieldmasking-plugin[dev-main] but it does not match the constraint.
It appears the repo does not have a version tagged.?
Last updated
I was able to install from cli using: php artisan plugin:install AlbrightLabs.FieldMasking --want=dev-main
But ran into more issues...
-
The included js file 'plugins/albrightlabs/fieldmasking/vendor/igorescobar/jquery-mask-plugin/dist/jquery.mask.min.js' results in a 404 error though the path is correct. Symlinking the file from the plugin assets/js directory and updating the corresponding addJs line in the plugin's boot method appropriately fixed that.
-
Added "cssClass: mask-phone_us" to one of my form fields, and it doesn't appear to be doing anything. No warnings on chrome console. I did doublecheck that the source 'jquery.mask.min.js' is loaded.
Not sure where to go from here. Any ideas?
Last updated
Ok... Realized I've encountered a similar problem before. October's new 'turbo-router' feature means that much of the backend works as an SPA and so using Document.onload to initialize is no longer appropriate. This can be fixed by modifying mask.js like so:
//
// Add 'cssClass: X' to field config in a fields.yaml to apply masking
// Example: to mask a phone number input add new line cssClass: mask-phone_us
//
function initMask() {
$('.mask-date .form-control').mask('00/00/0000');
$('.mask-time .form-control').mask('00:00:00');
$('.mask-hours .form-control').mask('00.0', {reverse: true});
$('.mask-date_time .form-control').mask('00/00/0000 00:00:00');
$('.mask-cep .form-control').mask('00000-000');
$('.mask-phone .form-control').mask('0000-0000');
$('.mask-phone_with_ddd .form-control').mask('(00) 0000-0000');
$('.mask-phone_us .form-control').mask('(000) 000-0000 x0000');
$('.mask-mixed .form-control').mask('AAA 000-S0S');
$('.mask-cpf .form-control').mask('000.000.000-00', {reverse: true});
$('.mask-cnpj .form-control').mask('00.000.000/0000-00', {reverse: true});
$('.mask-money .form-control').mask('000.000.000.000.000,00', {reverse: true});
$('.mask-money2 .form-control').mask("#.##0,00", {reverse: true});
$('.mask-zip_code .form-control').mask("00000-0000");
$('.mask-ip_address .form-control').mask('0ZZ.0ZZ.0ZZ.0ZZ', {
translation: {
'Z': {
pattern: /[0-9]/, optional: true
}
}
});
$('.mask-ip_address .form-control').mask('099.099.099.099');
$('.mask-percent .form-control').mask('##0,00%', {reverse: true});
$('.mask-clear-if-not-match .form-control').mask("00/00/0000", {clearIfNotMatch: true});
$('.mask-placeholder .form-control').mask("00/00/0000", {placeholder: "__/__/____"});
$('.mask-fallback .form-control').mask("00r00r0000", {
translation: {
'r': {
pattern: /[\/]/,
fallback: '/'
},
placeholder: "__/__/____"
}
});
$('.mask-selectonfocus .form-control').mask("00/00/0000", {selectOnFocus: true});
};
if (oc.useTurbo && oc.useTurbo()) {
addEventListener('page:loaded', function() {
initMask();
});
} else {
$(window).on("load", function() {
initMask();
});
}
Last updated
Thank you @josh70033, an updated version of the plugin should be available. The oc.useTurbo
portion was causing an error in earlier versions of October in my testing so I've eliminated that. Running initMask()
using both addEventListener('page:loaded', function()
and $(window).on('load', function()
seemed to work for both October v2 & v3, so that's what the v1.0.2 of the plugin is using now. Appreciate the help!
Perfect! I hadn't actually tested on < October 3, but makes sense... would have to do a null safe test I suppose but adding both seems a perfectly reasonable approach as well. Thanks for the quick update!
Just updated, and the 404 issue loading 'plugins/albrightlabs/fieldmasking/vendor/igorescobar/jquery-mask-plugin/dist/jquery.mask.min.js' persists. I'm not sure if October v3 is more restrictive about file system access or if something else is going on, but I applied the same workaround mentioned in my second comment.
FYI, I did post the question of FS Access changes on Discord. It appears that this did not change in v3 and that devs have suggested that there may have been some configuration that allowed it to work on your environment. While I have not tested, there is a strong possibility that this will not work correctly on pre-v3 either. Here's the conversation...
On October v3 I'm using a plugin that includes (addJs) a file that is below the plugin's vendor folder. This results in a 404 (though the link path is correct). I can work around this by copying the js file to the plugin's assets/js folder and adjusting the boot method's addJs line. I have checked all file/folder permissions along the path and they are correct. Note that this is not an issue in < October v3. Is v3 more restrictive about FS access or is something else going on? The ability to include css/js below a plugin's vendor folder seems like desirable behavior for plugins which use composer to manage external dependancies. Any ideas?
daft — Today at 1:08 PM Generally speaking, vendor folders should not be accessible. It would make sense to copy / publish to the asset directory
josh208 — Today at 1:55 PM @daft fair enough. So my assumption that v3 has more restrictive FS access is correct.?
daft — Today at 2:00 PM Design wise it was never possible to access vendor assets. Perhaps there was an exception added to your site that was lost during the upgrade
Last updated
1-7 of 7