Greetings again Andrei,
just to add to my previous post - we propose the same modification to the new Consent elements on the Register page, too.
Kind Regards,
Valentin.
nopCommerce 4.10 - Bug fixes and improvements
Team Member
- 16611
- 155790
- 10/22/2008
- Armenia
Nop-Templates.com wrote:
Hi Valentin,
Thanks! I think we can also do the same for "Accept privacy terms" checkbox as well. Here is a work item
we have a suggestion concerning the new Consents field at the bottom of the Customer info page
Hi Valentin,
Thanks! I think we can also do the same for "Accept privacy terms" checkbox as well. Here is a work item
Team Member
- 16611
- 155790
- 10/22/2008
- Armenia
Nop-Templates.com wrote:
Hi Hristo,
Sure. Done. Thanks a lot!
it seems the new "pre-order availability date" element is not having a class name...
Hi Hristo,
Sure. Done. Thanks a lot!
Team Member
- 16611
- 155790
- 10/22/2008
- Armenia
Nop-Templates.com wrote:
Stoyan,
I missed your comment. Here is a work item. Thank s a lot for pointing out!
Hi Andrei,
There is a problem with the images when they are saved in the database.
The "ValidatePicture" method is resizing the images to the configured Maximum image size in the administration.
For example if you upload a product image with 200 px x 200 px resolution it is resized to 1920px x 1920px (default max size). If we get the image without resizing (original size) the image is with bad quality and is very large. This has two drawbacks:
- The image size is bigger than the original one making the database huge
- The image is stretched and the quality is bad
Regards,
Stoyan
There is a problem with the images when they are saved in the database.
The "ValidatePicture" method is resizing the images to the configured Maximum image size in the administration.
For example if you upload a product image with 200 px x 200 px resolution it is resized to 1920px x 1920px (default max size). If we get the image without resizing (original size) the image is with bad quality and is very large. This has two drawbacks:
- The image size is bigger than the original one making the database huge
- The image is stretched and the quality is bad
Regards,
Stoyan
Stoyan,
I missed your comment. Here is a work item. Thank s a lot for pointing out!
Team Member
- 879
- 9286
- 1/11/2016
Nop-Templates.com wrote:
The "ValidatePicture" method is resizing the images to the configured Maximum image size in the administration.
For example if you upload a product image with 200 px x 200 px resolution it is resized to 1920px x 1920px (default max size). If we get the image without resizing (original size) the image is with bad quality and is very large. This has two drawbacks:
- The image size is bigger than the original one making the database huge
- The image is stretched and the quality is bad
Fixed. You can see the changes in this commit.
Thanks for pointing out the bug.
The "ValidatePicture" method is resizing the images to the configured Maximum image size in the administration.
For example if you upload a product image with 200 px x 200 px resolution it is resized to 1920px x 1920px (default max size). If we get the image without resizing (original size) the image is with bad quality and is very large. This has two drawbacks:
- The image size is bigger than the original one making the database huge
- The image is stretched and the quality is bad
Fixed. You can see the changes in this commit.
Thanks for pointing out the bug.
MVP
Silver Solution Partner
Certified Developer
- 2639
- 42712
- 1/21/2010
- United States
a.m. wrote:
This would work when you edit an existing entity (loaded as proxy type) but does not work when you create a new entity and it is a POCO object (not a proxy) and you end up with the actual base type which is "BaseEntity" instead.
Also fixed
Hi Andrei,
Regarding the previous commit as well as this one.
The way this is implemented (see code below) is limiting us to not being able to use it with our own entities that are not part of the default nopCommerce context as it throws a null reference exception as they are missing in the Model of the default context.
We have entities in our plugins for which we would like to keep some generic attributes but we are now not able to use the GetAttribute method from the GenericAttributeExtensions and the SaveAttribute method of the GenericAttributeService as both use GetUnproxiedEntityType() method which will not work for us.
Please note that since the generic attributes allows us to save settings per store they are quite useful for the plugin vendors and we often use them in our plugins. Sometimes we even use types that inherit from the BaseEntity type just to be able to use the generic attributes functionality for them. Please also note that such "fake" base entities are not even registered in any DbContext so relying on any DbContext won't work for us.
Maybe you can add some method that we could override in our own classes inheriting from BaseEntity and thus being able to specify the type name for each entity.
Thanks,
Boyko
This would work when you edit an existing entity (loaded as proxy type) but does not work when you create a new entity and it is a POCO object (not a proxy) and you end up with the actual base type which is "BaseEntity" instead.
Also fixed
Hi Andrei,
Regarding the previous commit as well as this one.
The way this is implemented (see code below) is limiting us to not being able to use it with our own entities that are not part of the default nopCommerce context as it throws a null reference exception as they are missing in the Model of the default context.
var dbContext = EngineContext.Current.Resolve<IDbContext>() as DbContext;
var type = dbContext?.Model.FindRuntimeEntityType(entity.GetType()).ClrType;
We have entities in our plugins for which we would like to keep some generic attributes but we are now not able to use the GetAttribute method from the GenericAttributeExtensions and the SaveAttribute method of the GenericAttributeService as both use GetUnproxiedEntityType() method which will not work for us.
var keyGroup = entity.GetUnproxiedEntityType().Name;
Please note that since the generic attributes allows us to save settings per store they are quite useful for the plugin vendors and we often use them in our plugins. Sometimes we even use types that inherit from the BaseEntity type just to be able to use the generic attributes functionality for them. Please also note that such "fake" base entities are not even registered in any DbContext so relying on any DbContext won't work for us.
Maybe you can add some method that we could override in our own classes inheriting from BaseEntity and thus being able to specify the type name for each entity.
protected virtual string GetUnproxiedEntityTypeName()
{
// some default implementation of your choice that will work for the default entities
}
Thanks,
Boyko
MVP
Silver Solution Partner
Certified Developer
- 2639
- 42712
- 1/21/2010
- United States
Hi Andrei,
In addition to the above post.
For the same reason explained above (current implementation of the GetUnproxiedEntityType()) we could not use the PrepareModelStores method from the StoreMappingSupportedModelFactory for any of our entities.
Thanks,
Boyko
In addition to the above post.
For the same reason explained above (current implementation of the GetUnproxiedEntityType()) we could not use the PrepareModelStores method from the StoreMappingSupportedModelFactory for any of our entities.
Thanks,
Boyko
- 976
- 11658
- 11/30/2012
- Angola
Nop-Templates.com wrote:
Hey Valentin!
The issue has been fixed. Please check this out: https://github.com/nopSolutions/nopCommerce/commit/adc1f213fd37e32d3a8e9b55760b6dc2745dcae4
We also made appropriate changes on the registration page.
Greetings Andrei,
we have a suggestion concerning the new Consents field at the bottom of the Customer info page.
If we leave it like it is, we would need to write additional styling for all of the themes and for each resolution.
Instead, we propose we change the markup, so that it corresponds to all other fields and this way it will automatically get the styling from each theme.
This is our proposition:
We have also added a check if there are consents at all, and if there aren't any, then the additional markup would not be rendered.
Kind Regards,
Valentin.
we have a suggestion concerning the new Consents field at the bottom of the Customer info page.
If we leave it like it is, we would need to write additional styling for all of the themes and for each resolution.
Instead, we propose we change the markup, so that it corresponds to all other fields and this way it will automatically get the styling from each theme.
This is our proposition:
@if (Model.GdprConsents.Count > 0)
{
<div class="fieldset">
<div class="form-fields">
@foreach (var consent in Model.GdprConsents)
{
if (consent.IsRequired)
{
<script asp-location="Footer">
$(document).ready(function() {
$('#save-info-button').click(function() {
if ($('#consent@(consent.Id)').is(':checked')) {
//do some stuff
return true;
} else {
//just show validation errors, don't post
alert('@Html.Raw(JavaScriptEncoder.Default.Encode(consent.RequiredMessage))');
return false;
}
});
});
</script>
}
<div class="inputs accept-consent">
<input id="consent@(consent.Id)" type="checkbox" name="consent@(consent.Id)" checked="@consent.Accepted" />
<label for="consent@(consent.Id)">@consent.Message</label>
</div>
}
</div>
</div>
}
We have also added a check if there are consents at all, and if there aren't any, then the additional markup would not be rendered.
Kind Regards,
Valentin.
Hey Valentin!
The issue has been fixed. Please check this out: https://github.com/nopSolutions/nopCommerce/commit/adc1f213fd37e32d3a8e9b55760b6dc2745dcae4
We also made appropriate changes on the registration page.