Alexander Kamburov
Forum Replies Created
-
Posts
-
Thanks, that’s a better solution and solves all the security problems with this part of the form.
Yes $geodir_is_widget_listing is working OK, thanks.
One last question – while geodir_before_listing() works well and inserts before the “view type” dropdown, it works for searches, but this actions is not executed at the main page (gd_home). Is there a different action for that page or there is no action to insert before everything there? Thanks
Thanks, but..
I already tried to use $widget_listings but it seems it is not a global variable – when used in functions.php it is not available which means it can’t be used to distinguish the cases. Is there any way to access it trough another global variable or object?
Thanks for the geodir_before_listing() suggestion. Which comes to the doc – I already know the provided link but this was the doc I mentioned in my previous question – havint 850 functions in a paginated format is really useless to find out something that we are looking for, unless we browse manually trough all the pages and click on every function to see what it does…..
Thanks geodir_before_listing_listview() may be will work with one exception – you are using it absolutely the same way in
– geodirectory-templates/listing-listview.php
– geodirectory-templates/widget-listing-listview.phpwhich means if we add something using that action it will appear where we would like and at the sime time at the sidebar where for example “Latest Places” appear. I don’t see an easy way to distinguish the two calls so to show something only at the page body.. any ideas?
Is there an action to add content only in the page body before the listings (preferably even BEFORE the dropdown to chose the view type – list/grid 2/grid 3 etc).
Do you have some kind of documentation/reference for the useful actions (I saw the full list of all functions in the php files which is not very useful). Thank you in advance for you help
Hello,
thanks for the shared code. It’s a really quick hack of the hack, however. I would recommend you to make it better in the official release:
1. wp_die() prints an error but the theme is broken, the error message should be handled better2. the code above looks for an empty entry but doesn’t handle incorrect ones. So for test I changed the package_id to a non existing value and as expected there was no error and the listing was accepted (with unpredicted results as there is no pricing plan). You SHOULD check for valid data against the available values for the plans and not to allow to continue if the chosen one is not in the list!
3. I haven’t tested further to see what would happen on the next step (after the verification) again with invalid data, I guess the check there should be added as well (the step right before the payment).
Thanks anyway. Our support is expiring and I guess I will not be able to get your reply, but since this is a security bug and I warned you in advance I expect to receive the correctly fixed plugin, you can contact us directly at the email, thank you in advance.
Thanks, can you send us the patch we will aply it. The problem is that the test site is not abailable anymore and the site went public. We will patch it and report if that fixes the problem.
– re: language problem – thank you for the idea, we missed to translate that page
– re: the bug/problem with the form submission with artificially tweaked form – wouldn’t you update the plugin so we can download the new fixed version?Any advice on my question above?
Thanks but can you point me to the right:
– the hook to insert above the search results for v2
– the two functions we need a) to retrieve all data for specific custom type and category and b) to catch the current category for the current page where the code is running. It’s kind of hard to locate these in the docs as they are pretty big (if one doesn’t know the exact function names it’s hard to guess what they should be)Is it OK to install v2 in a production site – is it stable enough?
We just found one more problem with this plugin, any advice if there is a quick fix (even in the coude) would be helpful as this is urgent:
when this plugin (payments) is enabled but the system is multilanguage (using WPML as you recommend) at the step of the first submit (to review and eventually pay after that) the language is lost (the form doesn’t send lang=XX to the next page). Is this possible to fix somehow?
This reply has been marked as private.This reply has been marked as private.OK I’m sending you the site/login in a separate message.
Just to confirm I was able ti fix the titles as per your instruction for the naming problem (sorry)
But it seems the second problem is still actual.
As I’ve said this is easy to replicate – fresh WP, fresh install of your main plugin, Invoices and pricing plugin. Why don’t you test it with your QA team I already did it it takes 2 minutes to reproduce it.
1. I didn’t understand your suggestion. While there is an option to EDIT the packages at Prices and Payment / Prices page, after such an edit nothing changes. The data is changed in the backend, including in the similar page of the Invoices plugin, but at the frontend it is not changed (I guess you keep the data cached somewhere) – this includes EVERYTHING – the title, the number of days, the price and so on. The only way to make a change now is to delete the entry and create a new one which is not acceptable.
2. This is clearly a bug as if the form receives something different than the predefined packages or nothing at all the server side should check and produce an error! Right now the administrator of the site can’t distinguish if someone tricked the system. Once again when one does what I described, the entry is being sent to the site successfully as it is paid (while there is no free option for the packages).
