Greg Mount
Forum Replies Created
-
Posts
-
@paolo +1 for this. An even better solution would be to remove the fields for front end users. I doubt they will ever need to enter lat/lon coordinates, so why present the fields?
@purpleedge Good point. Perhaps an option to hide for all but admin users would work. End users don’t need to see lat/lon coordinates in an otherwise pretty clean form.
+1
OK, here’s one hot off the press: http://torontomindbody.org/
We literally just launched this site today so there’s no content yet, but you’ll get the idea.
Host: WP Engine with CDN and object/transient cache enabled.
Theme: WooThemes Canvas custom child theme
Plugins:
- Akismet
- GeoDirectory
- GeoDirectory Advance Search Filters
- GeoDirectory Ajax Duplicate Alert
- GeoDirectory Autocompleter
- GeoDirectory Events
- GeoDirectory Location Manager
- GeoDirectory Marker Cluster
- GeoDirectory Payment Manager (unused, waiting for Stripe integration)
- NextScripts: Social Networks Auto-Poster (post new listings to our Facebook page and Twitter account
- Social Connect (social login integration)
- Social Media Feather (social sharing for blog posts)
- WordPress SEO
- wpMandrill (for transactional email delivery)
It appears that ga stats are only visible to users assigned to the author, editor or administrator role (not visible to subscriber and contributor roles). Since new users are assigned to the subscriber role by default, is this a bug?
Stiofan:: “Please suggest some ways for it to work and i will point out any problems.”
Me: “The solution seems clear: modify the display so that events only appear once in listings and search results, based on the first day of the event and regardless of the number of days it spans. Reasonable? Do-able?”
This could be toggled with a checkbox option in the back end: “Check to display multi-day events as a single listing.” Events could be ordered by start date. This wouldn’t apply to recurring events, but would be perfect for events that span multiple days, such as in the case of the OP (stroudsco).
So, is this a reasonable request and is it feasible with the existing code base?
A feature to delay publishing until X days before the event date would be a major convenience for our clients. This way they could post all their events for the year at one time and have them automatically appear in the listings one month, for example, before the event start date.
This gets important in the case of paid event listings, as the amount of time a listing is visible becomes part of the value proposition. It would be great, for example, to offer different packages to display an event 30, 60 or 90 days before the start date. Something to consider.
Three common event scenarios:
- A seminar that runs for one day from 9am to 5pm currently shows in listings and search results as an individual event listing.
- A weekend workshop that runs on Saturday from 9am to 5pm and Sunday from 9am to 2pm will show in listings and search results as two separate events.
- A 10-week course that runs on Thursdays from 6 to 9pm displays as 10 separate events!
I really like that the storage scheme deals with many date and time scenarios, but some work is required on the front end display. In my situation, for example, members pay to post event listings. With the current code, a person who buys a single-day event gets one listing, while a person with a two week event gets (the appearance of) 14 listings for the same price. I can just imagine the abuse and complaints this will cause!
The solution seems clear: modify the display so that events only appear once in listings and search results, based on the first day of the event and regardless of the number of days it spans. Reasonable? Do-able?
Thanks for the feedback, Paolo. First off, I didn’t write that WPEngine told me that “Varnish can’t handle sessions,” so careful with the attribution. They may very well have implemented (or plan to implement) memcached-based session storage. I don’t know enough yet about their configuration to say.
I’m sure the goal at WPEngine is to enable as many customers as possible to host their wp sites. I’m also sure that the goal for GeoDirectory is to get as many customers using this plugin and associated premium products as possible. My goal is to get sites built and hosted where they will work optimally to client expectations.
With that in mind, it’s in everyone’s best interest to collaborate on solutions. Your firm will likely make sell more product if you help clients find ways to make them work on any hosting platform. If you prefer to simply list links to articles that talk about why a certain platform sucks, well, I guess that’s another approach. 🙂
Anyway, I love GeoDirectory and I’m having a good ride so far with WPEngine. I’ll try to get them to play nice together and will share the results with others. If WPEngine doesn’t work out, I’ll move to one of the other 4 hosting platforms we use, including our own in-house hosting. In the end, I think it’s worth it for the knowledge gained.
For those looking for more background, here’s a support article from WP Engine that explains the issues with php sessions, cookies and caching:
http://wpengine.com/support/cookies-and-php-sessions/
<caching-lesson>In a nutshell, php sessions (e.g. $_SESSION or session_start()) store temporary data about a specific visitor (e.g. location). Varnish cache, the most common front-end caching solution for high-volume hosts like WP Engine, stores static copies of pages to serve subsequent visitors without having to hit the database again. This kills session data since the second visitor to the same page will be served a cached copy of the page and never set or read the session data that makes it unique to the visitor. The only way to use php session data with Varnish is to selectively bypass caching on those pages that use the session data.</caching-lesson>
That said, WP Engine has a pretty good reputation for support, so I decided to push the point. It turns out that they will disable caching on any page you wish, all you need to do is submit a support ticket. I’ll assume this includes wildcards.
To that end, it would be really helpful to have a list of URLs that require session data. I know this is relative to the install and configuration, but if we had a starter list or at least some indication of how the session data is used, then we could pass this on to support folks.
Why? The benefits of managed hosting are huge for some (my firm hosts some clients on our own servers and others on managed services like Pantheon, Media Temple and WP Engine). Also, I don’t want to bypass the incredible performance benefits of varnish on an entire site just because one plugin chose to use php (instead of javascript) to store session info. I think it’s totally possible to host this plugin on a managed service with aggressive caching enabled, as long as we can isolate those pages that need to bypass the cache. Can we (I’m looking at you, Paolo) help make this happen?
