obrian7

I have several ideas in mind for directory-based websites, and came across ProcessWire in my search for a starting point about a year ago. There are several good WordPress themes that are commercially available, but all the ones I've seen have various limitations that would preclude their use for what I have in mind. As a starting point for experimenting with ProcessWire, I had access to a list of churches and used that to develop a map-based directory here: Baptist Blue Book. The central issue for me was the map interface, and how to handle a reasonably large number of listings (~6,000) in that view (Most of the WordPress themes I had come across restricted the map view to a certain city, which I suspect was to limit the number of markers that had to be loaded.) A few notes: I'm using Ryan's Form Builder to accept suggestions for new listings. I liked having the packed solution for this, and the ability to control what happened to those submissions on the back end (e.g., the ability to hold them in a queue for review rather than posting immediately to the site). The church pages are subdivided by state (e.g., Directory > Texas > [church name]) by using a script to push a new listing to the proper sub-directory once it's approved. In hindsight, this may be an overly limiting approach, particularly for adapting it to international use, but once I had started on that path I needed to stick with it and focus on other issues. For the map view, a separate script pulls the latitude, longitude, and page-id from all listings and caches that in a JSON file. When the Map page is viewed, that file is retrieved and used to generate the markers. The content for the popups is only loaded as needed to minimize bandwidth. (Side note: I'm using MapBox for this, along with Leaflet and the MarkerCluster add-in.) All in all, I've been very pleased with the flexibility of ProcessWire, as well as the helpfulness of the community. I've also noticed several directory-type sites listed in the showcase, so I'm wondering if it might be useful to develop a module tailored to that application (or is each one so unique that this would not be feasible)? Any comments or feedback would be welcome. Brian

Ryan, I just upgraded to 2.4.0 and was able to duplicate the issue. A couple of clues from watching the MySQL tables: 1. When I added a new field of type 'float', it shows up in the 'fields' table but with the 'data' value empty. 2. If I immediately try to use that field in a page (without adjusting the precision, etc.) the saved values round/truncate (didn't test enough to know which) to an integer (I'm using the term loosely... there's no decimal point or trailing digits in the stored value). 3. If I then go back to the field settings > Details and just click 'Save' (the precision reads '2' by default --- I didn't change it), the MySQL 'data' column in the 'fields' table now reads, {"precision":2,"inputType":"text"} 4. If I then go back to the page I had previously edited and enter in a float value, it now properly saves to 2 decimal places. It appears the precision isn't getting properly stored in the 'fields' table on creation of the field, and that ProcessWire is defaulting to a precision of 0 in the absence of that information. Subsequent changes to the field settings cause that parameter to be set, and things work as expected.

Ryan, thank you for the tips. Unfortunately, I haven't taken the time to experiment any further to try to isolate the issue. I had looked into the MapMarker module, but need to use the lat/lot with Form Builder, which doesn't accept that field type (or at least didn't appear to when I initially set up the form). It appears I have a workable solution for now by manually resetting the precision, but if I can get a few other items checked off my list, I'll try to revisit it in more detail and let you know if I find anything of note.

I encountered an issue trying to import a table that has float values that were being rounded to integers using the ImportPagesCSV module. The csv table has a latitude and longitude column which I was attempting to import into separate float fields in ProcessWire. The 'number of decimal digits to round to' had been left to the default value of '2' for both of these. When I imported my table, however, the numbers got rounded to the nearest whole number. I then tried changing the decimal places to '4' for the latitude field and re-importing, and that appeared to work correctly (numbers for that field retained four digits after the decimal). I then reset that parameter in the field type back to '2' and re-ran the import, and again it appeared to work correctly, rounding to 2 decimal places instead of 0. The longitude field, which I left alone, always rounded to the nearest whole number. It would seem that the float types aren't seeing the 'default' decimal digits of '2' but instead are using a value of '0' (or null?) unless it is manually set. Digging around in the code a bit, does it make sense that this section of InputfieldFloat.module... public function __construct() { $this->set('precision', 2); parent::__construct(); } public function init() { parent::init(); $this->attr('step', 'any'); // HTML5 attr required to support decimals with 'number' types } ...should be replaced with... public function init() { parent::init(); $this->attr('step', 'any'); // HTML5 attr required to support decimals with 'number' types $this->attr('precision', 2); } Still trying to get my bearings with ProcessWire, so any general insights would be much appreciated.