Accueil › Toolset Professional Support › [Résolu] Post Form Inside View
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Aucun de nos assistants n'est disponible aujourd'hui sur le forum Jeu d'outils. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
- | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
Marqué : Content-submission forms, Toolset Forms, Views plugin
Documentation connexe :
Ce sujet contient 17 réponses, a 2 voix.
Dernière mise à jour par julieP Il y a 6 années.
Assisté par: Nigel.
I'm trying to create a page which displays custom post content using a View which also contains the post form (create new post) to create more of the same post type (so the User stays on the same page and can see their latest post has been added to the list). However, I'm getting this in my debug log:-
PHP Warning: urlencode() expects parameter 1 to be string, array given in /home/my-domain/public_html/wp-includes/formatting.php on line 4790
If I move the post form to a different page and set it to redirect to the page containing the View, the error doesn't occur.
Question: is this error expected behaviour when the post form is on the same page as the View displaying the results?
Here's the View I've used (the content has been simplified to demonstrate the set up):-
[wpv-layout-start] [wpv-items-found] <p> <em>You've created the following posts</em> </p> [cred_form form="create-new-post"] <!-- wpv-loop-start --> <wpv-loop> <ul> <li> [wpv-post-title] </li> <li> [wpv-post-taxonomy type="service" format="description"] </li> <li> [wpv-post-taxonomy type="county" format="name"] </li> <li> [toolset-edit-post-link content_template_slug="post-edit-link" class="btn btn-primary"]update[/toolset-edit-post-link] </li> </ul> </div> </wpv-loop> <!-- wpv-loop-end --> [/wpv-items-found] [wpv-no-items-found] <p> <em>Create your first post</em> </p> [cred_form form="create-new-post"] [/wpv-no-items-found] [wpv-layout-end]
Thanks
Les langues: Anglais (English ) Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
There isn't any reason why you shouldn't do what you've done, and, indeed, I set up a test locally and it worked fine, without warnings.
(I assume the View has a Query Filter to show only the logged-in author's posts, and the only differences between my Loop Output and yours are trivial markup differences.)
So, first, can you check plugin versions are all up-to-date.
Then can you try the usual basic debug steps of disabling non-Toolset plugins and switching to twentyseventeen to see if you still get the warning.
Let me know what you find.
Hi Nigel
Thanks for testing this. Your assumptions about the View set up are correct.
I've run through the usual debug processes and the issue still exists although I would point out that currently I'm using CRED 2.1.1.2 due to an email notification issue with CRED 2.1.2 which Christian is currently looking into for me. Nevertheless, for this exercise, I did upgrade to CRED 2.1.2 and now the debug.log contains more entries (!):-
PHP Warning: urlencode() expects parameter 1 to be string, array given in /home/my-domain/public_html/wp-includes/formatting.php on line 4790
PHP Warning: urlencode() expects parameter 1 to be string, array given in /home/my-domain/public_html/wp-includes/formatting.php on line 4790
PHP Notice: Trying to get property 'taxonomy' of non-object in /home/my-domain/public_html/wp-content/plugins/cred-frontend-editor/vendor/toolset/toolset-common/user-editors/medium/screen/content-template/frontend.php on line 60
PHP Notice: Trying to get property 'taxonomy' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 2739
PHP Notice: Trying to get property 'name' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 2740
PHP Notice: Trying to get property 'labels' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 2740
PHP Notice: Trying to get property 'singular_name' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 2740
PHP Notice: Trying to get property 'term_id' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 2741
PHP Notice: Trying to get property 'taxonomy' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 2741
PHP Notice: Trying to get property 'taxonomy' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 1508
PHP Notice: Trying to get property 'labels' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 1510
PHP Notice: Trying to get property 'singular_name' of non-object in /home/my-domain/public_html/wp-includes/general-template.php on line 1510
The taxonomy notice was there with CRED 2.1.1.2 I just failed to include it. Digressing slightly I see someone else had the taxonomy notice too a short while ago https://toolset.com/forums/topic/wp_debug-php-notice-trying-to-get-property-taxonomy-of-non-object/ (I tried the solution but it didn't change anything for me).
Where the taxonomy is concerned, I've double checked there are descriptions for the 'service' taxonomy (called for in the View).
Any ideas please?
Les langues: Anglais (English ) Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
I added taxonomies to my View to more closely match your scenario, but still see no warnings.
In that case I'll need an up-to-date copy of your site for debugging.
Can you provide a duplicate (exclude the media uploads directory)?
lien caché
Hi Nigel
I haven't provided a site dump!
I did a bit more troubleshooting yesterday and ascertained that these entries are only happening on a blog site (this is a multi site install). I wanted to give you a copy of a minimal install from my dev site but when I spun one up this morning from afresh with all latest plugins with a sample page, post form & view on the main site and the blog (just slightly different names for clarity) and the taxonomies on both, I couldn't replicate the issue!!
There must be something somewhere but I'm struggling to know what especially when I deactivated all plugins during my earlier testing. I think it's only fair that i do some more digging around myself first before taking more of your time. Before I close this ticket (for now anyway!), can you point me in the right direction as to what sort of thing normally triggers these types of entries? Thanks
A quick update; I've now deactivated all plugins except Toolset Forms, Views, Access & Types, reverted to 2017 theme and removed all JS code from editor sections in a few forms & views on all sites and still the entries appear! Any ideas as to why this might be?
Les langues: Anglais (English ) Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
This last update refers to the original site, right?
So on a particular multisite installation you see the PHP warnings, but on a single site copy of this same installation you do not see the warnings, is that right? The second site is a duplicate of the first, the only difference being that it is a single site install?
Hi Nigel
Sorry for the delay - I'm having multiple issues with the latest version of CRED that are taking a lot of time to troubleshoot and to be honest I've lost track of what is happening in which set up. I can get round this issue for the time being by moving the form outside the View and onto a different page. For the other issues there isn't a workaround i can implement so I need to get them sorted first.
Do you mind if I close this one for now and re-open it when I can re-visit the problem?
Les langues: Anglais (English ) Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
We don't have the ability to turn off then turn back on the threads, so if you can't work on this for the time being you can close it and then open a new thread when you are ready. (You can assign the thread to me and link to this one.)
Note that we have a slew of plugin updates soon, you might want to wait until next week, update the plugins, and then test again, the issue could solve itself (maybe).
Hi Nigel
Sorry poor turn of phrase on my part; I did mean open a new one and refer back to this one! How to I assign you to the new one? Not seen anything to enable that.
Thanks for the heads up about the updates - that's really useful to know.
Les langues: Anglais (English ) Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
If you have ever marked a thread I was handling as resolved then when you create a new thread you should have the option to assign it to me, other users do it all the time so hopefully it shouldn't be too buried.
Hi Nigel
Mmm that's interesting; I'm given options about preferences regarding support staff but I can only select the randomly offered support staff (one) or choose from a couple of other options. I've just partially created a new ticket to check I haven't missed anything; the uploaded image shows what I'm given to choose from. I believe everyone has handled a ticket for me at one time or another. Even when I've specifically (in the past) requested the support person offered, the system stills allocates the ticket to whoever! Is this not how it's supposed to be??
Les langues: Anglais (English ) Espagnol (Español )
Fuseau horaire: Europe/London (GMT+00:00)
Hi Julie
You are supposed to be able to assign the thread to the supporter of your choice (the only requirement is that at some point you have marked a previous thread handled by them as resolve).
I suggest you mark this thread as resolved, then open a new ticket, and see if it is any different.
If not, just leave a message at the top to say "please assign to Nigel".
I've asked our systems team to look into this and shared your screenshot with them.
OK thanks - will do
closing ticket