Forum Replies Created
-
Posts
-
Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!
OK, sorry for all the confusion!
So possibly Pippin did indeed misunderstand – maybe you could return and ask him about customizing the checkout form itself? That is in fact wholly controlled by Easy Digital Downloads and the template you’d want to interact with is an EDD one (templates/checkout_cart.php).
You might also be interested in this resource from the easydigitaldownloads.com website:
https://easydigitaldownloads.com/docs/custom-checkout-fields/
Does that help here?
Hi – I’m sorry you’re experiencing difficulties.
The snippet you referenced is not actually intended to impact on search results, rather it specifically targets the main blog loop.
if ( $query->is_main_query() && is_home() ) /* ... */It actually tests to see if a number of conditions are true – the first being a check to see if we’re in the main query and the second to detect if it is a home page request. Those may not be true in a search query, but you could certainly tailor this further if you need to.
Have you checked out the WP_Query docs? They go into more detail about how to interact with these sorts of properties:
- http://codex.wordpress.org/Class_Reference/WP_Query
- http://developer.wordpress.org/reference/classes/wp_query/
Does that help?
Is it possible some confusion arose from the way you described things? In this context I’m taking the “event registration form” to be a reference to the EDD checkout page, but perhaps Pippin thought you were referring to a form that our plugin generates.
Can you clarify which form you are wishing to target?
I would think that the best solution is to have the dates still searchable as they are, but to just not have it return a 404. Why can’t this date search show a webpage that doesn’t have an event, but that does NOT mean a 404 error. That doesn’t seem to complicated.
For us to implement that isn’t a complicated step at all and we certainly considered it.
Our impression though, based on our own testing with Google Webmaster Tools and by reading through their own advice on the topic is that this would result in an equivalent number of so-called “soft 404s” where they detect what is basically a large number of pages that should return a 404 status but do not.
This seems to potentially incur more of a penalty than returning a true or “hard” 404 and for that reason we avoided such a strategy (a 404 after all is not inherently evil in any way, it’s just a way of concisely communicating that no results were found).
Also, I think there should be some controls to set some loose parameters on the overall dates. For instance, I noticed dates 50-60 years in the future being 404 as well as some 20 years in the past. I would make a setting that has a “start date” that allows us to select the absolute date of when the site calendar should go back to.
We made a very recent set of changes and don’t for instance link to months, weeks, days etc outside of the populated date range.
So if your earliest event happened to be in February 2014 and you view that month, you will not (or should not) find a link to January 2014 … the same thing applies in reverse to your furthest out future event. That doesn’t stop a visitor (or a searchbot) from actually trying to access January 2014, though, and as before a 404 seems the only applicable response to such a request – but again we’re open to ideas on this front.
That said, I titled this with Yoast in the the title because as per the last thread, I was told that “it was Yoast’s fault” this happens. I was just trying to make the title as relevant as possible, even though I’m not sold that it is there fault. I have no way of knowing first hand though because I’m not a developer.
OK, no problem.
Certainly what we’re discussing here in this topic doesn’t on the face of it seem to have any connection to Yoast and possibly there was a misunderstanding in the other thread you referenced as it does seem like the snippet Brook provided was doing its job without interference.
Apologies for the confusion on that front and if you have any further thoughts on the points I raised we’re definitely interested.
Great minds think alike – you raise some valid points there and we were quite literally just discussing the same thing within the team.
We’ll definitely have a further think and consider making a change on our end, thanks again!
Pleasure 🙂
I’ll go ahead and close the thread but if we can help with anything else please don’t hesitate to create new threads as needed and one of the team will be only too happy to help.
Also, if you have a moment to spare, we’re always interested in hearing our user’s thoughts over on the plugin review page – thanks again!
Hi Massound,
No particular recommendations – it’s just something you might want to investigate (there are certainly lots of addons available – you can check just some of them out here).
Thanks again – and as I don’t think there’s too much more we can do here right now I’ll go ahead and close the thread, but please don’t hesitate to create new threads as needed if we can help with anything else 🙂
OK – well Pippin is really the subject matter expert there as the checkout form is generated by EDD rather than by EDD Tickets.
I don’t quite understand why you cannot add additional fields there and put in place some logic to record the submitted values – but he’s definitely the best person to seek advice from on that count.
Certainly if you do add some extra fields, there’s no reason you couldn’t store them in a suitable manner as post meta data.
OK – I’ll go ahead and close the thread in that case but please don’t hesitate to create new threads as needed if we can help with anything else 🙂
So you mean your custom community/edit-event.php template was the problem? Could you simply replace it with the default one and – just as in your custom version – find the following line:
<?php tribe_get_template_part( 'community/modules/image' ); ?>Then comment it out by doing this?
<?php // tribe_get_template_part( 'community/modules/image' ); ?>Would that work?
(As an aside, it’s often best to share larger chunks of code by using a service like Pastebin or Gist … simply because the forum currently is not well equipped to handle code and periodically sections of pasted code are stripped out, which can confuse things a little at times 😉 )
Awesome, glad that helped 🙂
I’ll go ahead and close this thread in that case – but if we can help with anything else please don’t hesitate to create new threads and one of the team will be happy to help.
Also, if you have a moment to spare, we’d love to hear your thoughts on The Events Calendar over on the plugin review page – thanks again!
Generally speaking simply placing it in a sidebar (and you could of course register additional sidebars if the existing locations are unsuitable) or else programmatically inserting it via a call to the_widget() works.
Additionally this (unofficial) plugin provides a shortcode letting you add widgets within posts. That said, we do know that it doesn’t always work – particularly with some “page builder” type themes.
Does that help?
Our recurring events implementation recently changed, so perhaps that caused this to surface (ie, at the point when you upgraded to Events Calendar PRO 3.5)?
As Kevin found in this topic Series Engine changes the timezone setting and that seems to be behind this problem. You could potentially follow the steps he described to fix this – but I’m afraid I don’t really recommend it simply because it involves modifying core code.
Right now I’d tend to see this as a bug in Series Engine – WordPress sets the default timezone to UTC and our plugin quite reasonably expects that to remain true, however it is subsequently being modified by Series Engine to something else.
So, ideally, I think the best approach would be to approach the Series Engine authors and ask if they could avoid this sort of setting change.
Hi – glad you you figured things out 🙂
Yes, our documentation can be sparse in places and we’re actively working to address that – so hopefully we’ll see a continual improvement going forward.
At this point I’ll go ahead and close the thread but please don’t hesitate to create new threads as needed if anything else crops up and one of the team will be only too happy to help.
Thanks again!
