=SOLVED= Meta search fields showing last ad posted meta values (custom fields)

[SmaRTeY]

Hi all,

I have ran into an issue with custom fields after having published a new ad in a category with custom fields.
Using Osclass 3.5.6 and issue is occurring in Bender theme as well as my Boxer theme (permalinks = on ie. rewrites of url's).
Not sure if it would make any difference but here's how I have setup the custom fields:
1 category is having custom fields
All custom field types have been added once to the category (all having a unique id)
All custom fields were made 'searchable'.
1 custom field was made required.

To reproduce the issue I do the following:
- Publish a new ad
- Chose the category I have added the custom fields to
- Simply fill in some values, there's no difference in either filling in all custom fields or only a couple
- Save the ad

No problems here, all goes well and the ad gets saved.
In my setup I have also payment plugin installed so I get redirected to the form to chose to make the new ad premium.
I do not make it premium but simply click on the logo to get back to the homepage
Next I click on search without any keywords and I get redirected to the search form showing me all the ads of page1
Next I select the category where I added the custom fields to and then Advanced Search is showing me the extra custom search fields, perfect. The problem is that these new search fields already contain the values I used when publishing the new ad just before and even when clearing them in advanced search and renew the search the values does not seem to work, the values used when publishing the ad seem to be 'sticky' somehow.

Hoping others are able to reproduce/confirm this behaviour and maybe a fix for clearing the values of the custom fields after a new ad is published with these custom fields. Any help will be appreciated.

Once this is fixed I will focus on the search with the CF itself since I noticed they are throwing errors (404's) in certain cases which need fixing as well ofcourse!
1 Step at a time should hopefully give us a good working CF functionality. 


Regards,
Eric

[SmaRTeY]

  FirstWorldProblem in Osclass, it IS the Payment Plugin which is causing this, seems that the redirect used in this plugin does not 'clear' the custom fields array which IS done with 'normal' posting of a new ad.... sigh!

SOLVED!

[teseo]

Hi Eric,

To avoid all those problems, keepForm session variable should be reset after successful Ad posting/editing:

Code: [Select]

<?php
function cust_drop_keepform($item) {
    Session::newInstance()->_dropKeepForm();
}

osc_add_hook('posted_item', 'cust_drop_keepform', 10);
osc_add_hook('edited_item', 'cust_drop_keepform', 10);
?>
Regards

[SmaRTeY]

Hi teseo,

Thank you, I was getting there but got stuck ofcourse.... 

I was trying the following code as used in controller/item.php:

Code: [Select]

                        $meta = ....
                        if(is_array($meta)) {
                            foreach( $meta as $key => $value ) {
                                Session::newInstance()->_dropKeepForm('meta_'.$key);
                            }
                        }
                        Session::newInstance()->_clearVariables();

...in the Payment plugin's function that is hooked to "posted_item" but it didn't work.
I also tried "Session::newInstance()->_clearVariables();" but also didn't work and I was about to give up on this!

Now I simply used the "Session::newInstance()->_dropKeepForm();" and that's working, thank's!
I guess this is a valuable piece of information for all plugins that hook into the "posted_item" since new functions like the Payment plugin using this hook and prevent the core code from following regular process will skip this variable reset, correct?

So wouldn't it be better if core variable reset is created using the hook including a priority of 1 ? Any plugin/theme hooking in will in that case have no trouble with the variable reset or is that wishfull thinking

Your solution will work just fine, the only thing I wonder about is the case of a regular post which will always result in resetting the vars twice unless I see this wrong? I prefer code that only runs when needed for performance reasons so therefor my thought above about a core modification using the hook with prio 1.

Ohwell....


Regards,
Eric

[teseo]

Priority 1 means that function (A) will be executed before any other function called by the same hook (B,C...), so given that the objective here is to have KeepForm clean for the next page, and B,C... might need the data in the form, the logical thing would be setting Priority 10.

Regarding a possible duplication, that is unavoidable, but it is just a quick write operation on a very small file (.sess), negligible.

Regards

[SmaRTeY]

  Yes that would make more sense, my thought was about clearing the vars asap but once it is set on the hook cue it will be reset anyway so no need for setting it to 1.


Thanks,
Eric