zapappa

I have narrowed it down to it only being a problem whenthe Ultimate Member plugin is active. I will contact them but can you tell me if this situation has been previously reported yto you?

cancel that, it’s working ok.

I used 2022% at first because your documentation contains this example:

YOUR-URL/?wpda_search_column_title=Last%

but in the initial post you can see that I also tried %25:

I tried 2020%25 to see if that would work and there was no error but nothing rendered.

I re-ran the same tests on the main issue (accessing the calendar) that actually needs the %25 I have the same problems as before

https://fridayharborsailing.com/wp/view-calendar/?wpda_search_column_date=2020%25

However, I think I have found the cause of the problem. The calendar table is setup with the Data Publisher/Advanced Settings/WHERE Clause containing YEAR(date)=”YEAR(CURDATE())” and I guess I was expecting the?URL parameter to override the Where clause if necessary but that appears to be not the case. If I remove the YEAR(date)=”YEAR(CURDATE())” from the WHERE clause and use the %25 it works perfectly. This means there is no configured default year but that’s an easy change.

So, if you agree that this conclusion makes sense I thank you for your time and your patience.  You have a great plugin here!

Sorry Peter I checked in my sent and it appears I replied to your email which had a no-reply destination! Here it is:

Thanks for getting back.? I have another table (officers) that is simpler and doesn’t actually need a wild card because this table has a ‘year’ column, which is a text type. Here is the columns list:

Again, if I use your Query Builder it works fine, both with and without the % character:

SELECT * FROM wpws_fhsc_officers WHERE year LIKE “2021%”

SELECT * FROM wpws_fhsc_officers WHERE year LIKE “2021”

SELECT * FROM wpws_fhsc_officers WHERE year = “2021”In WPDA the default WHERE clause is year=YEAR(CURDATE()) and it displays the officers for the current year with no problem.  The shortcode is [wpdataaccess pub_name=”fhsc_officers”]

When I add the URL parameter without the % I see “No matching records found” but no console error.

https://fridayharborsailing.com/wp/view-officers/?wpda_search_column_year=2020

If I add the % character I see the console error (URIError: URI malformed)

https://fridayharborsailing.com/wp/view-officers/?wpda_search_column_year=2020%

Note: the “/wp” folder is a separate WordPress system for my testing.

Thanks, Les

I exchanged a few emails with Peter and I’m still waiting for a reply to the last email?

Resolved. I had to set the “Can access wp-admin”. Sounds dumb on my part but it never occurred to me that UM would override the standard WordPress users, like Editor!

Anyway, this might help others in the future. Again, thanks for such a great, highly featured plugin.

Hi, great, great plugin! I’m having the same issue with REQUEST_METHOD. Do you have an ETA for the next release?

So, what I’m seeing is exactly what it is supposed to be. Thanks for clarifying that Jeff

However I’m still a little confused about classic vs block editing. To edit a submitted post you say “that means editing submitted posts is done via the Edit Post screen” but doesn’t that imply it has to be done on the back end and not the front end which is what we are trying to do? btw block mode editing a post on the backend works fine

Going back to creating a post with USP, I have only been able to create a post with the classic editor and not the block editor. To do this I have to check “Enable RTE/Visual Editor for the Post Content field” and then I see the classic editor. If I leave this unchecked then I only have a textarea without the Add Media button.

Am I missing something?

• This reply was modified 2 years ago by zapappa.

I’m now kicking myself for not doing this sooner. Because the USP page was not even loading the USP js files I tried simply re-installing USP. And now it looks and works just fine.

I installed a fresh, second, wordpress and installed USP. Of course it then worked just fine so I’m pleased to confirm that you don’t have a problem! I’ll pursue finding what the actual issue is and let you know.

I found this to be a very good plugin, just after a few days testing. A couple of suggestions that come to mind are:

• A dashboard to support editing of previously submitted posts
• The ability to choose classic or block editing

Many thanks for your help.

I should have mentioned that the “include js” setting is checked:

Include JavaScript X Include required JavaScript files (recommended)

.

Thanks for the explanation. So there is no difference between deleting manually and deleting with the Timeout Rule as both use wp_schedule_event? And preload will only run when there is user input which means at random intervals greater than 5 minutes?

In Clear Cache via URL you say “you can clear cache via cron job (type=clearcache)”. I presume that it will also kick off preload after deleting the cache, is that right?

And the final question: is there any difference between clearing the cache with a Timeout Rule and setting up a cron job to clear the cache (apart from being able to specify the times to run the cron)?

Yes, I know I can do that but that wasn’t my question. My question was why does preload run every 5 minutes after I delete the cache manually but runs at random intervals when I delete the cache with a configured Timeout Rule?

I am quite content with the preload running every 5 minutes but why does it not run every 5 minutes when it is started by the Timeout Rule? Putting it another way, can you confirm that it should be running every 5 minutes?