ldwp
Forum Replies Created
-
Forum: Plugins
In reply to: [Easy Contact Forms] Account suspended?The message seems to originate from the suspended hosting account – the text is the same. Doesn’t affect plugin functionality as far as I can tell.
There are two requests I found in the source which have something to do with this – one that looks likely is to get a video tutorial, obviously this would fail and instead print the ‘This account has been suspended’ text rather than the video the request was looking for.
I’ve forked the plugin and am going to remove the callbacks to avoid confusing users, I’ll post a link when done.
If the author is in any way active, please would you consider either pulling my fork once done or publishing your own update? One of my clients uses this plugin on 3 sites and was worried about this, thinking that her own account (with us) was suspended.
Thanks and sorry to see the authors are having trouble 🙂
I’m seeing the same thing if I turn on full error reporting in PHP, using PHP 5.3 and wordpress 3.4.2.
In my case I’m using feed.php and simplepie to parse an RSS feed, the error seems to be thrown 20 or 30 times, perhaps once for each property of each RSS entry?
As far as I can see not everyone will be seeing it unless they have error reporting turned on, but a compatibility fix would be a good idea as just because the errors aren’t visible doesn’t mean they don’t need to be fixed. At the very least it will be filling up alot of log files…
Thanks for the replies guys.
Permalink collisions are post-type specific.
That’s interesting, why is it that WP only checks the current post-type for slug collisions? Does it only become a problem if the slug collision happens for posts with the same post-type?
I’ve also seen it happen with attachments.
Well spotted – I haven’t seen this yet but I’ll keep prodding it to see if I can get a better test case written up.
I’m still not clear on whether or not this actually causes an issue, in the first instance what happened was that I would get the page content rather than the post content associated with a collided slug. Not an error as such but certainly undesired behaviour.
It could be a pain to spot and sort out if you didn’t know what to look for.Think I should post a bug report?
OK I missed something the first time around – it’s actually much simpler than I thought.
Change permalinks to %postname%
Create a post called ‘thepost’.
Create a page called ‘thepost’.This page and the post will both have the same slug.
Can anyone confirm this, and if it is intended or buggy?
So something happened there. And I can repeat that every single time.
Yeah, that’s what I see too.
It seems to be when you change permalinks that things can slip through – in my case I changed from the default (?postId=postId) to postname, and doing the trashing / untrashing as above, got the same result.Although I think you found a different way than me, I could recreate it with the first method. I’ll try this again today & post results.
Thanks
I think we might be getting our wires crossed here – I already know WP will append a number to a slug if you make a duplicate (under most circumstances), I’m not suggesting that changes.
However if you change the permalinks *after* creating the first trashed post, make a new one with the same name, then untrash the first post, you WILL get a slug name collision, hard cheese.
I think there should be a check for this, in order to avoid them. Yes a workaround might be to empty the trash, great – but a better solution would be to programatically check slugs for collisions when permalinks are changed, which would avoid the need for a workaround.
If you are in any doubt about this please see the first post, follow instructions to re-create and post results – even if you get different results I’d be interested to know.
If this is documented, can you point me to it?
You have to empty the trash.
what for?
the point is that if you DON’T empty the trash, and instead untrash an article that has the same name as one you’ve made since trashing the first, you will get a name collision.I don’t need to know how to avoid this, I’m suggesting that this behaviour be changed in a later version.
Forum: Fixing WordPress
In reply to: Add Link, Stay on this page@simmessa:
Thanks for that, this helped me pin down a big I was having with galleries and the image uploader when adding or editing a post.The cause was this error being thrown in firebug, which was caused by two different versions of jQuery being used.
WP itself was using 1.6.2, whereas one of my plugins (Calendar Posts) was using 1.4.2.Editing the calendar plugin to remove the import for the 1.4.2 jQuery script fixed all issues I was having, disabling the plugin also worked.
Looks like perhaps WP should have a more formalised way for plugins to use whatever version of jQuery that WP itself has already imported and used (on the editor / admin side)? This kind of thing is easy to do if you code your plugin to use a specific version of jQuery, and hard to fix when it conflicts with another version.