Empty Custom Field Price populates automaticaly

This topic contains 6 replies, has 4 voices, and was last updated by  Stiofan O’Connor 5 years, 4 months ago.

We have moved to a support ticketing system and our forums are now closed.

Open Support Ticket
  • Author
    Posts
  • #462692

    Pepita Bos
    Full Member
    Post count: 78

    From another thread:

    I have two custom fields with price in one CPT. One is price in $ other is in €. They are both not required.

    With a new listing I have filled out a price in Euro, and left the Dollar one blank. When I update the listing, 0.00 is automatically added to the Dollar Price Custom Field. As a result, it shows a price of zero dollars in the Details page Sidebar.

    Alex answered (in the other thread): If you don’t want the zero to show then use a text field with the setting for CHARACTER instead of number. Different issue. https://wpgeodirectory.com/support/topic/cpt-details-page-sidebar-oddities/#post-462690

    My answer to that was: But if it is a text can it be searched for, or sorted on? I would not think so. I think that if a field is blank, it should not be populated automatically.

    Isn´t there an option to change this. If one works with two custom price fields, and one is set to zero because it is not used (dollars and euros like in the example), then not populating it would be the better solution. For other custom fields the rule is – if I understand correctly – that if not populated, it is not shown. Why should it be different for price? If developers want to set the price to zero they can do that manually. I do not have the option to change it, which means that my listing give incorrect information.

    Could this be changed in GD, please?

    #462761

    Paolo
    Site Admin
    Post count: 31206

    Developers alerted. They’ll reply asap.

    Thanks

    #462774

    Alex Rollin
    Moderator
    Post count: 27815

    I spoke with the developers about this. The field is not blank by default. By default the value for a text->number field is 0, and the default or a price field is 0, also, with formatting for price. This is specifically because there is no qualitative difference at the database level between 0 and 0. For example, the case, what if the user wants to enter that the price is 0 (free)?

    The workaround is to use a text-> character field which does not deal with absolute values like 1 and 0 in the database.

    If the field is not being used, then it will also not be useful in search. If it is being used then every item should have a price (0 or more).

    A customization could hide the field if the price is 0, but, again, this would be a customization to attempt on your own because some users would want to set a price of 0 (free).

    The developers will let us know if they have any other ideas for workarounds.

    #463110

    Pepita Bos
    Full Member
    Post count: 78

    Hello Alex,

    Thank you for your explanation. I totally understand it, but I think the working fails when you are using a second price field (character field) if the price of the listing is in another currency. Then it looks rather strange if the listing shows a price in Dollars that is 0 by default and for instance, € 30 if the product is available in Euro only. It is confusing to people.

    I would think that if something is free, the owner of the directory would use a text field with the text FREE. If they would want to set the price to ZERO, it could be added manually by those directory owners.

    I am curious as to the work around, if any.

    Thanks for all your efforts.

    #463113

    Alex Rollin
    Moderator
    Post count: 27815

    The workaround is to use a text field set to character. Unless you are comparing prices, and you only need it to display the price of something, then it should not be a problem.

    #463122

    Pepita Bos
    Full Member
    Post count: 78

    The comparing then isn´t possible, I will think of a solution.

    thx

    #463218

    Stiofan O’Connor
    Site Admin
    Post count: 22956

    This has been fixed and will be in the next release (targeted Wednesday)

    Thanks,

    Stiofan

Viewing 7 posts - 1 through 7 (of 7 total)

We have moved to a support ticketing system and our forums are now closed.

Open Support Ticket