Forum Replies Created
-
Posts
-
The shortcode “ifset” attribute is not designed as a full programming/logic block manager. A div needs an opening and closing tag and cannot be managed by a single ifset.
Instead considering using the location data as part of a class declaration and use custom CSS to show/hide a div.
<div class=”[slp_location data.***]”>…</div>
Fix coming in SLP 4.8.4. The beta (prerelease) is out. DO NOT use beta on a live server.
https://wp.storelocatorplus.com/wp-content/uploads/2017/08/slp4.zip
This is the beta-3 release and has not been fully tested. Please test on a non-production site.
As an aside… if you ever see /sensor= in your Google Maps URL that is NOT coming from a Store Locator Plus component.
Google deprecated that argument more than 2 years ago and we’ve not employed it in over 18 months in any of our product implementations.
Something else is trying to load the map and is doing it incorrectly both by not honoring the native protocol request (http or https) but is also sending deprecated parameters to Google.
The “missing layout” settings was something we just discovered on multisite installs. I’m curious if you are seeing it on a standard WP install.
The following updates available now for Premier users may resolve the issue. These are NOT production files. Please test on a staging site. We are in the midst of a full test cycle before releasing this patch to production.
SLP 4.8.2-beta-3
Experience 4.8.2-beta-2
Premier 4.8.2-beta-2
Power 4.8.2-beta-2Premier members can find the files under the Products | Downloads menu. or on the Slack Channel.
Power 4.7.10-beta-1 is undergoing testing. It should resolve the issue. You can get to it from the downloads page on this website. To test it you will need to download the prerelease copy of Power from the website, deactivate/delete the Power add on, add new plugin via the upload process in WordPress and activate it.
Please keep in mind this is a beta release and not fully tested. You should have a full site backup before testing and should test, if possible, on a staging copy of your live site.
Once testing is complete we will release Power 4.7.10 into production. Hopefully before close of business on Friday.
If you are able to test Power 4.7.10-beta-1 on your site please report your results here.
For future reference you can use the Email Us contact form on this page to send login credentials which goes to the support team (they will assign the email to me). Premier customers can also request access to our Slack channel which includes group chats for multiple SLP channels as well as direct 1:1 communication with myself and our support lead.
We are chasing a categorization issue that we have been unable to reproduce on our servers. If we can reproduce the problem we can track down and patch the bug. This is now only the 2nd report we have (we’ve had 4 but 2 others were server configuration issue and not enough PHP Memory assigned) of a problem so I may be asking for more details, an admin login if possible, and possibly even a dump of the SLP (or entire WP) tables for debugging.
The one customer that reported the issue was working with the 4.7.9 beta releases for a while. We have that data an still have not be successful reproducing the problem.
Did you have to roll back Experience to fix the issue or was that precautionary?
The CSV meta should be enabled automatically via the Power file import module. If it is not able to do so it is likely due to a restriction in the server PHP environment.
If you are looking to show the categories on some pages where you are show the map and results that is not going to be easy without some custom CSS work.
You can create a custom SLP Plugin Style CSS sheet. This is a CSS file that goes in the ./css/ directory of the Store Locator Plus plugin. The header of that file is very specific and can contain rules for the various layout fields including the Results Layout.
You could, in theory, create a custom CSS file for use on that page only where you set the Results Layout shortcode in the header and do not include the output for the Power-assigned categories for the locations.
You can then use [slplus theme=’my-custom-css-name-without-the-dot-css’] to get SLP to use that plugin style file versus the new Style Gallery.
You’ll want to make sure you retain a copy of that custom file in case you lose it during SLP upgrades. SLP should store any theme file you’ve activated from the SLP Experience/View tab (that new file should appear on the drop down View selection after you put it in the right place) but if you are only using it for custom modification of per-page results layouts it will not auto-save/auto-restore.
Separate the category slugs with a comma (,).
Are you installing SLP 4.7.7 or an older version? There was a bug fixed with 4.7.7 that appeared on some sites that have case sensitive configurations on PHP object/class names.
You should NOT be having that issue with SLP 4.7.7
You may also have an issue if you have a very old (> 15 months) versions of an add on and jump more than two minor versions of SLP (4.5 to 4.7+ for example). Newer versions of add ons and the base plugin self-check version compatibility and disable add ons that may cause an issue to prevent fatal errors, something older add ons could not do.
Emilie – can you email your CSV file or attach it here so I can play with this and see if there are import issues? support@storelocatorplus.com will go to our support mailbox.
You can import multiple categories, you should be able to upload without doing the geocoding immediately. With Premier you can also upload the entire file without geocoding and now set a recurring scheduled job to geocode all uncoded locations. I can go over all of that with you in a future post, but I’d like to have your data first. I’d also like to get a copy of the data with the multiple categories you’d like… list them in the category column as “Category-Parent::Category-child, Category-Parent2::Category-Child2” … the quotes do not need to be in the CSV cell, when you export as CSV it should add those automatically.
Those two lines you cited have NOTHING to do with the permalink URL.
Those settings are based on the custom page type we use to register locations with WordPress. In fact we should probably change those lines to use the SLPlus::locationPostType constant but since it is not broken, not reason to modify it.
The SLPPower_Pages class in SLPPower_Pages.php is what determines the permalink structure via the modify_storepage_attributes method. You can set it to any fixed string using the Pages admin tab “Permalink Starts With” setting.
This is hooked to Store Locator Plus via the SLP slp_storepage_attributes filter. That filter changes the page attributes registered to WordPress core when the SLPlus::locationPostType (store_page) custom page type is registered. It does this by modifying the page attributes array.
This changes the permalink in WordPress by changing the page attributes before it is registered to WordPress core with the register_post_type() function. That function is part of WordPress core and sets up custom page types and determines how they interact with the rest of the WordPress architecture.
What you are asking is to change a core attribute of a registered WordPress post type on a per-page basis. You CANNOT do this by manipulating the register_post_type attribute array. The proper way to handle this is by intercepting the rewrite rules built into WordPress OR by going “higher up the chain” and creating your own URL rewrite rules either via Apache mod_rewrite or the equivalent in other web servers such as nginx.
Getting into how to modify the WordPress Permalink interfaces or how to configure and modify the web server rewrite rules is out of the scope of support for Store Locator Plus. It is possible but it is an extensive topic that requires in-depth coding knowledge and is an entire instructional lesson in-and-of-itself.
You need to be looking outside of the Store Locator Plus application stack and start looking at building your own plugin with Permalink interfaces. Without spending a day or two digging into this I can only come up with some theory on architecture options. I’d start by using the custom taxonomy for Store Locator Plus registered as SLPlus::locationPostType and use WP Core functions to query for all categories registered to that post type. Then run through that array and register permalinks for all those post types and link directly to the WordPress URL for displaying that category list. By doing this you can let the WordPress theme take over from there and avoid building custom pages in code and let the WordPress template system handle it.
This is not a feature built into Store Locator Plus by default and I strongly advise either crafting your own plugin to do this or hiring us to lay out the customization and make it a standard product. In essence we’d be doing the same thing but extending an existing plugin to provide that code.
To give you an idea on cost, this is likely a 3 or 4 code-day project with a $1500-$2000 budget.
You are asking for help in hacking the production code of Store Locator Plus, so yes, this is way outside of normal support channels. For Premier Members we do give some latitude on what we answer and helping “bend the product”. I’ll take a look at the code in question but keep in mind that when you change this you will NOT be able to perform updates of the Power add on in the future and that there may be versions of the base plugin that will not be compatible with the current 4.7.6 release of Power. You’ll need to decide if you want to take this on.
Also , since you know about Permalinks, you also know you will need to flush the entire permalinks table every time you update, change, or delete a category. You’ll also risk having issues with caching plugins and web crawlers if you do not flush the permalinks table every time you update locations in a way that impacts categories in any way (add a location to a category, remove one from a category, etc.). Since Permalinks are cached and they impact the entire site this flush and rebuilding of the index can be a major performance impact on the site during the time the rebuild is going on.
Just some things to keep in mind.
I’ll take a look at the code soon and provide some hints, but if the site you are deploying is planning to stay on production cycle Store Locator Plus this is something you should consider having customized and added as a production feature as part of our Premier plugin.
Chris – CiCi forwarded this post to me.
There are a couple of “hackish” ways to do this , but I’m playing with some other more elegant methods and think a better way to deal with this sort of thing is needed for future releases. Maybe I’ll add something as a new feature in the Premier Plugin for active subscribers.
I’ll shoot a video and add a post after I play with this a bit more, but this may get you started. I also updated the Results Layout documentation which may help you:
https://docs.storelocatorplus.com/blog/results-layout-shortcodes-and-attributes/Hackish Way #1 – Per Location Marking
– Use Extended Data Manager to add a new “phone icon” field.
– For each location you’ll need to set that new field to the URL to your phone icon.
– Results layout to show the icon when phone is present…
[slp_location data.web_icon wrap=img ifset phone]
<span class=”slp_result_address slp_result_phone”>[slp_location phone]</span>I do NOT like this option as you are having to add and store data for every location for a single recurring HTML element (the image URL). Yuck.Hackish Way #2 – Commandeer An OptionHere you only have a single consistent entry for the phone icon image URL. Problem is you are storing it in an SLP setting that you (hopefully) will never need. For example, most people never use popup email forms. I take over the Experience Add On’s Popup Email Title option and put my phone icon URL in there.I like this better as you have one less plugin (EDM) loading and taking up overhead and memory. You also store a lot less data making location request payloads smaller. You also don’t have to enter 3,973 image URLs if you have 3,973 locations. I don’t like this because… well, it’s just wrong. What if you need ALL of your options? What if the way the Popup Email Title is processed or stored ever changes (it hasn’t in 3 years but you never know). This is probably the safest option to get your layout online ASAP without waiting for some new SLP patches/features.[slp_option popup_email_title wrap=img ifset phone]
<span class=”slp_result_address slp_result_phone”>[slp_location phone]</span>
There are other interesting ways to do this if you decide to hijack an option including using a CLASS NAME instead of putting the full URL in that popup email title setting. For example, just put the word “phone_icon” in there instead and use that as part of the class for the span. Assuming you know some basic CSS you can then set a CSS rule for span.slp_result_phone.phone_icon that renders the icon via CSS and the rule span.slp_result_phone (without the .phone_icon) does NOT render the icon.<span class=”slp_result_address slp_result_phone [slp_option popup_email_title ifset phone]”>[slp_location phone]</span>Notice I dropped wrap=img from the shortcode in this case.So … some “hackish” ways to get there. I’m thinking about other options but I don’t have a “clean and right” way to do this. yet.
The template is only used when the pages are first built. This allows you to modify the page content and have those changes remain permanent. Re-create your pages from the SLP Locations / Manage tab.
If the Turn Off SLP Maps is not checked then something else in your WordPress themes or plugins is forcing the Google Maps API to be removed from the WordPress script list.
I’ve checked your site URL and it is definitely NOT loading Google Maps JavaScript and our plugin will NOT render that locator interface and skip the “load Google Maps JavaScript” step unless that box is checked. That means something else took the instruction to load the JavaScript out of the list or decided they own the ‘google_maps’ handle for scripts in WordPress. I’d look at any Google-centric plugins first.
Try disabling plugins one-at-a-time and see if the map loads.
https://docs.storelocatorplus.com/blog/user-interface-settings/
@Sandra – What do you mean you’re not “eligible” for the Pro Pack? You can buy Pro Pack and it will work with SLP 4.7.4 giving you exports. So no, you are not correct in your assumption.
As for “may not work past version 4.4” , that is true. But CiCi already told you it DOES WORK with version 4.7.4.
I put that note on all legacy products over a year ago when I knew I was going to be changing the base architecture of the core plugin to be more efficient AND reduce the number of plugins we offered. I don’t have a specific drop-dead date for the add ons. If I can keep them working with a quick 2-minute edit then I make that patch (like I just did with Enhanced Map for 4.7.5).
I know that someday a change in SLP will break something in the legacy add ons and I made the business decision over a year ago to not spend 3 months patching 16 plugins in an effort to improve something in the base product. That is why the notice is on all the legacy add ons. If you are worried it will break DO NOT upgrade.
Keep in mind you NEVER are forced to upgrade the base plugin. EVER. It will work exactly as it did the day you made your add on purchase. If you’re worried it will stop working then DO NOT upgrade the base plugin. It is that simple.
As a side note to all of this… you are running a business site, correct? It is kind of important to keep it up and running, right? You DO have a professional backup service like VaultPress, right? So you can easily roll back any changes that break your site (like WordPress 4.5 did to thousands of sites)… it is kind of important. Also it is only $40 PER YEAR for VaultPress. Seriously, if you don’t have it already you really should.
In addition – you should also ALWAYS have a way to test upgrades on a STAGING site before “going live”. Nearly every single half-decent WordPress hosting service provides 1-click testing/staging services these days. If you’re worried an update to SLP base plugin will break Pro Pack, click that “create test/staging” site button, update SLP, and check.
@Elizabeth – Read the above statements. You are not “expected to pay 3x that” just to export. Pro Pack Legacy still works and exports.Extortion? How is that?
Do we FORCE you to upgrade to the latest FREE base plugin? No.
Do we FORCE you to upgrade to one of the newer add ons or your previous add on will break? No. That one time Pro Pack purchase that you paid $50 for and got dozens of FREE updates for stopped workign? Nope. No, it will still work just fine.
Have data held ransom? We do NOTHING to lock up your data. It is not encrypted. It is readily available via STANDARD WORDPRESS EXPORTS. In addition the PRO PACK export still works.
SLP is now ransomware? I don’t think you know what that word means.
Have to downgrade to use Pro Pack? Have you been reading ANYTHING CiCi has written or are you just here to vent? That statement is completely false.
Can no longer do your month-end export and backup of your client’s database? You’re not really relying solely on the Pro Pack export as a back up are you? That’s great, but if you are managing client sites you really need to have a real backup service. Something like Backup Buddy or VaultPress. (side note: you can transfer locations between sites with VaultPress too, did you know that???) You CAN still do your Pro Pack exports. You do NOT have to downgrade to do so. Also… you are providing your clients monthly maintenance? Are you charging them a monthly fee or did they pay you once and you give them lifetime support and service for free?
How do you justify the price increase? You do know that Power is NOT the same product as experience, right? It includes FIVE different add ons. Read above and you can find out the reason why I made that change.
Yes it means fewer sales, but as a single man operation I will gladly take 3x fewer customers with 3x fewer support inquiries for the same revenue. I also find that those customers that don’t mind paying the higher fee tend to be higher caliber clients. They are the type that sees value in paying $250 or even $700 for a product that they turn around and resell to multiple clients as part of their $5,000 or even $50,000 web presence packages. Even those that are “only” charging $1k for that sort of thing have realized that paying $250 for something they’ve re-sold and re-installed dozens of times is still a good deal. I guess they realized that they don’t expect to go back to the local pub and get free beer every week for the rest of their life because they bought a burger there 3 years ago.
I’m not trying to be all things to all people. I’m not looking to be the most-installed locator package on WordPress. I’m trying to build a great product that works better than most and is continually improved and refined to be the best locator you can get “out of the box” and save weeks of time when you purchase an add-on or subscription because I’ve made it easy for developers to tailor the User Experience to their client’s needs without wasting weeks writing code or hacking CSS. Building THAT product comes at a price.
At the end of the day if my “supporters” come with as much vitriol and venom as you have shown here, I’d rather keep that crowd to a minimum.
WPML is not designed to put different map center addresses in when you switch the main language of the site.
We’ve also been trying to work with WPML for over a year now on language switching of strings stored in option labels. For the most part they’ve been less-than-helpful. We have gone over the architecture and how we interface with WPML and they only say “it should work, read this documentation and try again”. After spending 3 months trying to get it working we are back to waiting on the WPML dev team to either tell us what we’ve done wrong or provide a fix so that the language switching works in a object oriented app like Store Locator Plus.
If you post your live site URL I may be able to see what is running that is blocking your JavaScript controls on the admin panel. Without a site URL we can only guess.
You cannot put slp_directory shortcodes in page titles.
By default the built-in WordPress shortcode processor only works in page content per the WordPress Codex.
https://codex.wordpress.org/Function_Reference/add_shortcodeWhat you are trying to do is build dynamic WordPress page titles on the fly. This is going to break a lot of internal stuff in WordPress including the permalink system, many SEO plugins, and other attributes of WordPress Core.
Is it possible. Maybe. But not without a lot of overhead to manage the changing titles.
Store Locator Plus is designed to use the standard WordPress Core shortcode processor and as such will not let you do what you are attempting in your screen shot.
You need to take a different approach.
What do you mean “massive amount of space”? The graphic you are showing has nothing to do with space.
If you are talking about the PHP run time that depends a LOT on how you have the plugin configured, how many locations you have, and many other factors.
Is that screen shot from an admin page load? From the user experience? If admin page, which tab? Manage locations? What is the number of locations you are displaying on the manage locations tab? If you have 10,000 locations and want to display all 10,000 records, 1.47 seconds of runtime for that much data I/O is excellent performance.
You need to put this in context.
If you are using this tool to figure out why SLP “suddenly stopped working”, define “suddenly stopped working”. Also – what changed. Did you update WordPress? Update any themes? Plugins? You don’t happen to have auto-update enabled on your site either directly, via JetPack, or the WordPress.com dashboard do you?
The more accurate you can be in your description of the problem and your environment the better we can help. A screen shot of a graph with no context doesn’t provide much to go on.
That screen shot indicates your MySQL server is overloaded, your network is misconfigured, or your router is compromised/overloaded.
The reason you cannot restrict the browser key on Google is that you have NO CLUE where your users are going to be coming from and what their IP address is.
The main map on the website is using JavaScript to get the user’s location they type in (or from GPS if you have Power and Location Sensor on). JavaScript runs in the browser = on the user’s device = from any IP address/location/browser type there is. The script sends the address directly to Google which then returns the latitude/longitude. That communication requires you have a Google Browser Key and no restrictions. The fact that it is in cleartext and not pre-encrypted is a design/architecture decision by Google. In theory, why should they care? They get paid for usage of a registered key so someone snarfing that is not a huge priority for them.
Could we use a more secure server based key to do this work? Sure. It is a lot more overhead and a lot more things to break. It adds several layers of complexity and data I/O requests for the same process. That also means a performance hit which can be notable for your site visitors. User enters address – send network request from browser to your server – your server re-packages that request and sends request to Google – wait for Google response back to your server – your server packages this and sends it back to the user’s browser. This all must happen before a browser timeout, typically 60 seconds or less. If ANYTHING has to be retried, a connection is down, etc. the requests will fail to return any results and the locator will appear to be broken. The current architecture of SLP is user enters address – send request to Google – Google replies back to browser.
Given the large number of sites we hear about that cannot properly geocode 2,000 locations in under 5 minutes on their servers it is obvious that many people are running their WordPress sites on underpowered servers. That significantly increases the risk of putting your server in the middle of the front-end geocoding process and causing a WORSE user experience.
In my opinion the real problem is Google’s blatant lack of security and using even basic encrypted keys on front-end browser based requests. There are a number of methodologies they could use to deal with this including salts and time-based requests to encrypt the keys. That is an issue for Google to sort out.
In the meantime we’re considering adding the OPTION for a server-based versus browser-based Google Maps Key in the Premier Plugin for those customers that understand the risks of impact on the user experience and are certain they have a fast enough server to mitigate those risks. The base product, however, will not change as we feel it provides the simplest solution and best overall experience for the majority of the 15,000+ sites running our plugins.
Thank you for sharing your resolution in case others run into problems.
There are a lot of moving parts so depending what else you have set it can influence the starting state, zoom level, etc.
You are not showing Social Media Extender in your version list.
The latest release is 4.5.02 , which is the production version you should have installed.
or
DeBaat fixed that a while back and 4.5.02 was published to fix the DebugMP issue.