Forum Replies Created
-
Posts
-
@Dimitiri – FYI – Pages requires WordPress 4.4 with the REST API enabled. If you disable the REST API your pages will not pull data properly which means no location details and not map. On one of the URLs above it appears the wpjson REST interface is disabled or has been relocated.
Yes, you can force your own map on any page using code like that you posted her but it will NOT update if you ever change your location data. That lat/long is fixed at the position you set.
The other issue is that you are now loading a script “inline” versus using the WordPress enqueue commands. This is not recommended and can have all kinds of side effects as WordPress has zero information about the script and how it may impact others.
This technique works but mileage may vary and future updates can be problematic for WordPress, Store Locator Plus, your WordPress Theme and other plugins.
The reason your Pages map was not loading normally is because your WordPress theme (or another plugin) is loading the Google Maps JavaScript on EVERY PAGE versus just the pages it needs to render a map on. That is also against WordPress best practices; however I understand that some themes are just too cool to pass up regardless of what bad habits they may bring with them.
@wselwood – try selecting a small subset of pages first. Start setting manage locations to display 100 locations, check the “select all” box and permanently delete pages. Those 100 locations should no longer show a linked page in the pages column.
Then select the same 100 locations and use the bulk action create page.
If that works try a larger subset of locations.
It is very possible that trying to do 9,000 pages at once is overloading your WordPress server. It SHOULD do SOME of the pages even if it crashes due to resource issues, but try 100 locations at a time first.
Also make sure you try first with the default template. I’m not sure what WordPress 4.4+ will do with extra quotes in shortcodes. They really buggered up the shortcode processor in the name of “security”.
Are you editing each individual page and not the Page Template under the Pages tab?
You need to go to the Store Locator Plus / Pages tab and set your template there, then go to the Locations / Manage subtab and create/recreate your pages. Keep in mind any edits you made on each individual page is overwritten.
Read this article for assistance:
Generating Store PagesAlso, in Pages 4.4 there are specific shortcodes for setting the email hyperlink automatically, as well as one for a location map and website link. It is part of the default template. You may want to copy out whatever your existing template code is now to save it and then delete it (set the field completely blank) and save settings. The default page template for Pages 4.4 should be restored. It will likely have a lot of elements you want it will certainly have WordPress 4 friendly shortcode formatting without quotes.
Rest API support is built into the base SLP plugin and WordPress 4.4.
To use any data modification endpoints you will need to use a WordPress REST API compatible authentication plugin. They are listed on the WordPress REST API version 2 doc pages. I recommend the oAuth plugin over the Basic Auth plugin for security reasons.
All of the SLP REST API endpoints are listed in the include/class.handler.rest.php file. The endpoints and methods are self explanatory.
If you provide your actual locator URL we might be able to provide more insight.
Your Experience add-on is out-of-date. I’ve emailed the latest 4.4.07 version which is available under My Account here.
Use your site management login (cPanel or FTP) and remove the wp-content/plugins/slp-experience directory.
Login to admin and upload/activate the 4.4.07 version of Experience that I emailed (or you downloaded).
Something on your site is forcing jQuery 1.5.
Store Locator Plus requires the WordPress standard jQuery , or at least version 1.7 or higher.
One of the core contributors, a member of the plugin review team, and a very talented plugin developer describes the issue better than I can here:
https://pippinsplugins.com/why-loading-your-own-jquery-is-irresponsible/
In short, the other developers are doing something that is very much frowned upon and not a good idea when building WordPress apps.
This is not possible at this time using the built-in options. It has been added to the requested features list for future consideration.
Appears you now have an issue with Store Pages, so we are on a completely different topic here.
You have an issue with how your Pages template is constructed.
Please paste the full page template you have crafted here. It is not parsing properly.
Also be advised that WordPress changed how shortcodes handle quotes. It cannot handle shortcodes with quotes for attributes within an HTML element that has quotes. There has been a lot of controversy over this move by WordPress but they refuse to change their position citing security concerns. It may require some creative templates to do what you want, but let’s start with pasting your Page template setting here.
Provide your public site URL and I can tell you what is wrong with your WP setup. Without that I cannot venture a guess as to what may be interfering.
99% of the time it is another plugin or something in your theme that has messed up their JavaScript implementation.
Mostly likely the theme is mangling the built-in WordPress jQuery that ships with WordPress core. Very likely forcing a specific release of jQuery and running in conflict mode ($ shorthands in jQuery) vs. the WordPress-suggested no conflicts mode (always using long-form jQuery instead). None of these things are good and do not follow WordPress best practices. Having ad-hoc versions of jQuery running in an interdependent application framework like WordPress is not a good idea.
If I had to venture I guess I would be that somewhere buried deep in that theme, is a piece of code logic that is short-circuiting and loading the older-incorrect jQuery and/or conflicts (shorthand) mode whenever Pretty Photo is not in place.
Of course this is all just conjecture, but we run SLP on many of our own sites as well as multisite installs and there are 18,000 other sites running it today with an estimated 500+ on multisite. I’ve not seen any other reports of conflicts with a JavaScript-centric image library including PrettyPhoto.
If you can get me access to a site I can look at from here & possibly log into with admin and play with (activate/deactivate stuff) I can look more closely. However very single time I’ve seen a $() reference on jQuery in an error or log it is exactly as prescribed above. In short, bad themes/plugins not following WP best practices.