ryan

One other thing to add: if you use the 'useHoverBox' option and either don't see the hover box working, or see it showing up in the wrong place, you'll want to put your map in a container that has position=relative or position=absolute echo "<div style='position: relative;'>" . $map->render($items, 'map', $options) . "</div>";

Some new $options have been added to MarkupGoogleMap: 'icon' => 'http://domain.com/path/to/icon.png', Full URL to icon file to use for markers. Blank=use default Google marker icon. 'useHoverBox' => false Use hover box? When true, shows a tooltip-type box when you hover the marker, that is populated with the markerTitleField. This is often more useful than the default presentation google maps uses. 'hoverBoxMarkup' => "<div> (see below) </div>" When useHoverBox is true, you can specify the markup used for it. Use the following (which is the default) as your starting point: <div data-top='-10' <!-- offset from top of marker (in pixels) --> data-left='15' <!-- offset from left of marker (in pixels) --> style=' <!-- inline styles, or specify your own class attribute --> background: #000; color: #fff; padding: 0.25em 0.5em; border-radius: 3px; '> </div>

You should give it a PageArray of pages that each have a 'map' field. Each of those pages (that has a 'map' field) will be considered a marker. You specify the name of your map field as the second argument. i.e. $places = $pages->find("template=bfd_places"); $options = array('width' => '100%', 'height' => '400px'); // "map" below is the name of the FieldtypeMapMarker field in PW echo $map->render($places, 'map', $options); Also wanted to mention I found a JS error in the last version that corresponds with the error you were seeing before where no marker would appear. In fact, a marker should have been appearing, but there was a small JS error in there, which has now been fixed. Grab the latest to see if it resolves the issue you were having before? I've actually not seen businesses show up on the map before? At least, we aren't specifying any options to make it do so. Can you post a screenshot, just in case I'm misunderstanding what you are talking about? I'm wondering if it might somehow be picking up some google-specific setting associated with your Google account.

Thanks for the screenshots Wayne. To my eyes, it looks like the 13px–15px range is problematic for Arimo and Windows, and the other fonts as well. With Arimo, both 12px and 16px look just fine to me (how about you guys?). Perhaps we can solve this by just using a smaller default size that corresponds with 12px. To me 16px just seems overly large for body readable text, like a large print book for visually impaired people. But it is typically the browser default, so not positive whether to default up or down on this one... learning towards down (12px), but going to experiment.

Did you install the modules manually, or via ModulesManager (or the new built-in installer?). Double check that the module files are named correctly. I have had this exact problem when I downloaded a couple of module files manually, and OS X felt the need to add an extra ".module" at the end of them, i.e. "MarkupHTMLPurifier.module.module". Of course, that's an invalid module name format and ProcessWire didn't recognize it. Took me a little while to realize they had an extra ".module" at the end of the filenames.

How did you hide the settings tab?

You could always install your own copy of CKEditor or TinyMCE (or Redactor might be worth a look) and install it according to the manufacturers instructions. When you get down to it, a rich text field is nothing more than a regular HTML textarea with some Javascript (from TinyMCE, etc.) being run on it. However, I think that non-administrative use of a rich text editor is asking for security issues. You are enabling the user to enter markup, and markup can be used to insert javascript, and it can sometimes be very difficult to identify. Well crafted javascript can be used to break into just about anything. At minimum, you'd want to run anything submitted through it with HTML Purifier before saving it. I think you may be better off using a restricted lightweight markup language like Textile Restricted, BBCode, or GitHub flavored Markdown (there's very good reasons why sites use these for front-end content input). But if you go the rich text route, just be certain to get HTML Purifier involved.

LazyCron – I bet you are right and that's it. Though LazyCron shouldn't get called multiple times for the same maintenance. What scale of traffic are you serving there?

Are you sure this is related to that particular block of code? Could it be coming from somewhere else? Does your saveStats() function make any modifications/saves to users or any other pages? Is it always the same user 10625 or different?

Nice work Radek! Looks like you are putting the new admin theme to good use too.

Sorry I really don't understand the question. But if you needed to sanitize one part and not another, I'd think you'd have to extract it before sanitizing it? You might also want to look into the HTML Purifier options as they do provide a lot of ways you can modify its behavior. For instance, you might be able to configure it to ignore some tags and not others, etc.

Something already sent some output before the header() call. View the source and be on the lookout for a PHP error message or notice at the very top of the output. It's even possible it may be some whitespace by a module that ends with ?> and a space (this is one reason why it's not good to end your PHP files with ?>). When you view the source, do a "select all" so that you can identify if any whitespace is present. This will prevent a header() call from being successful.

This module assumes that you have entity encoding turned on for your title field. (See Setup > Fields > title > details > Text formatters). This is something you should always have enabled when using ProcessWire for any kind of HTML-driven output. Changing the quote style in the JS would not be an alternative to entity encoding, because you'd run into the same exact problem if one of the page titles happened to have quotes in it. Though you could use something like Markdown or Textile too, but I'm honestly not sure if those entity encode apostrophes or not. If not, the only solution may be an str_replace(array("'", '"'), array('"', '&apos'), $page->title); ahead of time. This module can accept a single Page or a PageArray. If given a PageArray it'll map them all and fit the map to the markers. If given a single page, it should still map the marker and use the zoom setting from that marker. However, you may need to modify the module to suit your needs. In the instances where I'm using it, I typically modify it. Though the skyscrapers profile was made long before this module, so it is using something quite a bit older and not a module at all.

That's a good point. Actually what probably would be better here is an argument that lets you specify the max length. 500 is probably inappropriately long for many instances where you would use selectorValue, especially since this function's max length of 100 is referring to number of characters, not number of bytes. I'll go ahead and add that.

The way that ProcessWire does it is to take a path, explode it to an array with "/" as the delimiter and then construct a query that joins back the pages table for every segment of the path. The longer the path, the more joins, and I suppose the more potential for overhead. It sounds potentially slow, but I've found it's actually incredibly fast. While it's nice to have those paths cached in their own table as the PagePaths module does, I haven't seen it make a measurable difference from the uncached/joined version that ProcessWire uses by default. Though if you were having to deal with large numbers of such paths in a single request, it might make a measurable difference there. There's also a lot of potential overhead with renaming or moving a lower-level page with lots of descendants, as it requires re-building the cache for all of those pages. This is the primary reason PW does it dynamically with joins rather than keeping a cache of them like in the PagePaths module. You don't query MySQL directly. I suppose you could query the pages_paths table directly if you wanted to, but that's not the point of this module. An example of a real life query would be to find all pages that have "chicken/nuggets" as part of the URL: $pages->find("path%=chicken/nuggets");

If you are populating this data to a PW textarea field, then it's going to take care of ensuring the data is sanitized for storage in the DB. You don't need to do that. However, what you need to be concerned about is outputting that data. That data could contain stuff that may be perfectly safe for DB storage, but is full of XSS when presented to the user. If you need to allow markup from untrusted users, your best bet is to sanitize with HTML Purifier. We also have a MarkupHTMLPurifier module for ProcessWire. You would simply run it through HTML Purifier before populating to the PW page field, and that would have the effect of removing markup which could be considered problematic or insecure. Another alternative is to use a restricted LML, like Textile Restricted or BBCode. But of course your users would have to use that LML rather than HTML, which may or may not be desirable.

I like Dragan's approach if you don't mind mixing JS into the CMS side of things. Whether that's a good practice or not really depends on who's going to be using the admin. If you want to keep this on the development side rather than the content side, one approach I've used is to keep JS files named with the ID of the page. When a JS file existed that matched the ID of the page, it would be included in the <head> section. Example: <?php $file = "scripts/$page->id.js"; if(is_file($config->paths->templates . $file)) { echo "<script src='{$config->urls->templates}$file'></script>"; } More often, I use this approach with the template file, i.e. have a file named basic-page.js that gets included on any pages using the basic-page template.

Looks like a good one SteveB! I look forward to it.

Looks fine to me MarcC. My process here is pretty much identical to Horst's. Over the next couple weeks, I have to import 3000+ pages each with 10-50 photos. When doing large quantities, you may need to paginate it, or run it multiple times, if you run into any memory issues. Check if the page you are creating already exists and skip it if it does. Something you may also need at the top of your PHP file is: ini_set('max_execution_time', 60 * 60); // give it an hour.

If it requires ProcessLanguageSupport, wouldn't you want it to be "requires" => "ProcessLanguageSupport" ?

The new inputfields.js from the dev branch will attempt to maximize the row with the columns that are in it. If the total does not add up to 100%, it will expand the last visible column to fill the row. I'm guessing this is what you are seeing? This behaves well with the default admin themes (both old and new), but I've not tried Futura Remixed yet. It's possible that theme may need an update if it's not something we can work around. Dependencies are the field names are they are in the markup (id attributes). While I've not tried it, you may be able to get it to work just by using the parent field as it's named in the markup, which is "parent_id". However, you could only match the ID (number), you couldn't match something like parent_id.template=home.

In order to store a file, you need to associate it with a page. Each page has a dedicated location where it can store files. In your case, it may be better to accomplish the functionality you are after with a template (and a page using that template) rather than a module. Though if you wanted it to be a module, you could always create it as a Process module that can handle uploaded files. The ImportPagesCSV module is an example of that. But I honestly think the simplest path is to use a template.

The admin is intended for administrators or site editors, so it's not a place to send general users to. It sounds like you might be having these users modify a profile page? This is stuff you can easily code using the PW API on the front-end, and that's the recommended way to do it. There are some examples here in the forum, but let me know if you can't find them and I can track down some examples.

I think this particular one might be fixed on the dev branch, as I recall hitting the same issue a couple months ago. But the intention is that you shouldn't ever have to use trackChange() yourself unless you are writing a module or doing something out of the ordinary.

2.4 is not PHP name-spaced. I got started with it and realized it was going to create headaches for many web developers having to namespace all their template files (not to mention modules). This is extra baggage that most of our audience would not appreciate. So I've put it off to one of the next versions when I can find a way to do it that doesn't require gratuitous verbosity to people's template files. I think that's possible with a built-in template compiler, but that's a bit more work than I was looking to get into for 2.4. If for some reason that doesn't work out, then we'll pen the namespace change to PW 3.0 when a major version would be more amenable to an upgrade that may require changes to one's template files.