I read through your post and there is nothing there I see that might explain the problem.
Deleting the post meta for the CRED post expiration should be sufficient and shouldn't have any unintended side-effects. Your understanding of how it works is the same as mine.
Also, I cannot see, either, why your custom trash function would affect anything, because you are simply hooking into wp_trash_post and are not replacing the trash function.
The form I was using in testing throughout was the Ny Bokning form.
I created a new test page and simply inserted that form onto the page.
If you re-create your site by exporting/importing the settings and content, you might want to try with some simpler versions of your posts that don't use your custom code for testing, and then re-introduce your customisations and keep testing as you go along. I don't believe from what you have described that they are responsible, but you might find something.
A bit nervous now.
I deleted my site, and now I'm importing views.
Get an error "Failed to import Content Template attachment - organizer-exhibitor-header-row, default-category-organizer-compr.jpg"
How do I get around it?
This is really messy.
I'm used to moving my site with duplicator, never manually.
I exported everything with wp export and toolset export
delete the site
reimported everything.
I lost
all media files
all users
all pages
some custom posts (toolset created) didn't get imported
most "belongs-to" data is lost
Please tell me you made a backup before starting with this.
Exporting and re-importing the settings and content should cover most aspects of your site, but it won't make a 100% authentic clone—if it did it would likely clone the problem too—and you may need to do some work joining the dots again when the import is complete. It's not supposed to be a substitute for duplicator.
Toolset export works by individual plugin, so you will need to export your Types content separate to your Views content and your CRED content etc., then import each of these separately into the new site.
I didn't have any problems importing the Toolset settings for each of the plugins, but I hit an error when I ran WP Importer to import the content itself, and I re-ran it simplifying things by, for example, assigning all the posts to the same admin author.
All my users were imported, and a great deal of media was imported, but I only tested the CRED form issue, not the site generally.
I'd be happy to bundle it up in a duplicator package if you like, let me know.
I'm only aware of one current issue with Toolset export/import, which is that the setting for where to display custom field groups (e.g. only on certain post types) is missing and would need re-setting manually.
I'm sorry but I don't think this will work.
When I import the CRED forms, they get new ID's meaning that all views, pages, content templates and custom functions doesn't work any more.
Can you get anyone on your end to help find out what is preventing post expiry form working on my installtion så I can go back to the way it was.
I cannot just perform a search'n'replace on the form id's in db tables because I might change zipcodes or phone numbers or whatever.
In my new clean installation: if I manually change post expiry time on a post - it is not updated in db!
On my "new clean" site.
My Bokamarknad-master theme and only Toolset, Access, Layouts, Types, Maps, Views and WordPress importer activated.
I imported posts and all Toolset files.
Nothing else installed.
------test one
My site is set to timezone Stockholm (CET+1)
I used form "ny bokning" with a setting to expire in 3 hours.
Now that the form ID was changed during import no custom functions in my theme are running thus not interfering with post expiration settings.
The post was created 17.00 (my time)
Expiry time shows 21.00 in post edit. (+ 4 hours instead of 3)
Expiry time is 18.00 in DB (+ 1 hour instead of 3) Result:
3 hours after creation, post is not trashed.
at 21:00, post is not trashed.
------test two
I created another post with form "ny bokning" to test how edit post expiry time manually behaves.
Post is created 20:28
Try to set expiry to 21.00, post saves but shows expiry to 00.00 the next day.
When checking in DB the time is set to 21.00 Result:
at 21:00, post is not trashed.
------test three
I searched for the word "expiration" in my entire db and found something strange.
In table wp_options there is a field called "cred_post_expiration_settings"
The value of this field looks like it has set CRED cron to check the site "monthly"
I double checked both the "clean" install and my existing and they both have the same value:
If this is what it looks like it's not strange that nothing is trashed when it should.
From where does this setting originate?
What are the values of this field on your installation where you manage to get expiry trash to work?
Things I think worth noting with import/export of a toolset site instead of using duplicator:
Pages get new ID's - all CRED redirect urls stop working
CRED forms get new ID's, forms in views and content templates aren't loaded. I know that the syntax has changed in the latest version of toolset, but anyone with a site built before this release will have problems.
Views and Content templates get new ID's, all API calls in templates stops working.
I am reverting back to the installation I had because this didn't solve the issue and it is to much work to solve all the ID problems.
The schedule for the CRED cron job is set at Toolset > Settings > Forms, and is visible when you check the box to enable post expiration. By default it is hourly (I'm pretty sure it is, I just looked at a new site to confirm), so you would need to change this to monthly.
On the duplicate of your site I have the setting is hourly, please double-check this for yourself.
If you haven't already reverted and still have the new test site available, please change the setting to hourly, and re-test. If the setting was monthly, then, no, the posts would not have been sent to trash, and we can't draw any conclusions from the test.
As you can see from the image I have five "every-5-minute" options.
These are the values I get in db (option 1st-5th are the 5-minute options):
1st = wp_ewwwio_media_optimize_cron_interval
2nd = wp_ewwwio_image_optimize_cron_interval
3rd = wp_ewwwio_flag_optimize_cron_interval
4th = wp_ewwwio_ngg_optimize_cron_interval
5th = wp_ewwwio_ngg2_optimize_cron_interval
once hourly = hourly
twice daily = twicedaily
once dialy = daily
Notable:
1. There is no "monthly" option.
The existing value, in my duplicator from yesterday, was 'monthly'.
2. There is no minute setting.
How can it ever be possible to set post expiration to less than an hour? To me the setting in CRED form to less than an hour has no effect?
I checked again on my local copy of your site, and my options look normal (see screenshot) and the CRON job is set to daily. But, checking in wp_options, it says monthly.
I changed the setting (on the settings page) to daily and then back to hourly, and it updated wp_options correctly. So I'm now expecting the post expirations to work.
I don't know, can't account for, what you are seeing on your screen. The only options are hourly, twice daily, and daily. (A colleague said you must have added custom expiration options but I said I didn't think so.)
But if you try changing the option to hourly (and double-check wp_options was updated) can you then re-test the post expiration?
I edited my previous post at the same time you were replying. Please read again. I posted links to the conflicting plugin and a ticket.
I never created any cron settings myself. I believe it is a plugin conflict - agree?
Do you have EWWW enabled on your copy of my site, where the menu looks normal?
