ryan

ProcessWire 2.4 (2.3 dev) also has the ability to install modules, check for updates, and and update modules individually, pulling from the modules directory. It uses the same method as ModulesManager (actually Soma's code for the most part). But ModulesManager has a nice advantage in that it can check for updates on all your installed modules at once.

Great article Felix! I had to use Google translate to read it, and German is one of the languages it doesn't translate to English particularly well, but I think I caught most of it and thought it was really fantastic. Thanks for writing it! It sounds like you are going to do more and I look forward to it.

Wow, awesome update Teppo! The diff feature looks fantastic. Can't wait to try this one out.

Actually it looks like 15px (0.9375em in our case) is a good route. This seems to render nicely in the Arimo screenshots above, and looks about the same as 14px in OS X. The 16px size I tested just seems way too big, but 15px seems like a nice balance. Is there something special about 15.245 or are you just being silly? You know I'm actually going to go test it out now. Just tried but I can't reproduce that one yet. My version of the admin theme here is a little newer so maybe that's the difference. I'll get these files together and commit them shortly just in case that's it. Thanks, I found the problem and fixed it. It will appear in the next commit. Yes it may come to that. I have no problem with Arial, but I've also become very attached to Arimo and so want to exhaust all options before giving up on it.

It looks like data rows are under category rows. What are data rows? Do these represents the pages having that category or something else? If they are the pages having that category, consider using page references and moving the pages to their own container. That way your pages can have multiple categories, if they need it. Though if multiple categories aren't ever needed, then the structure is just fine. Also your questions relate very closely to what the Blog profile does, so I'd suggest looking at that too.

Sorry, I wasn't thinking about the fact that your module actually extends ProcessLanguageTranslator. What you'd need to do instead is include the ProcessLanguageTranslator.module file somewhere outside of your class. I would put this before the class definition. require(wire("config")->paths->modules . "LanguageSupport/ProcessLanguageTranslator.module"); You may also be able to do this (below) instead, but it would have the effect of installing the ProcessLanguageTranslator module, which you may not want or need to do in this case. wire("modules")->get("ProcessLanguageTranslator");

Is this dev branch? None of those line numbers in the errors line up with the line numbers in the file. Also, I don't see any of those warnings and I've pretty much got debug mode on all the time locally. I also tried to duplicate this but couldn't. Here's the code I used: $img = $page->images->first(); $img2 = $img->size($img->width, 0); echo "<img src='$img2->url'>"; Is it possible you've got a different ImageSizer.php somehow? EDIT: Soma never mind–I'm the one that's got a different ImageSizer.php not sure how this has gone uncommitted for so long, committing now...

Nevermind about 12px–it's just too small, at least in OS X. 16px too big, but renders ok.

Your simplest best would be to just extend ProcessWire most basic starting point, which is Wire. This enables your class to have access to API variables (through $this), enables any of your methods to be hookable (that you precede with 3 underscores), and makes the file possible to translate with language support. Another option is to extend WireData. This is the same as Wire, except that you gain $this->set() and $this->get() methods that are accessible both in and outside of the class. It essentially means your class can function as a shared data container. The set() and get() can also be accessed by $this->key = 'value'; and $value = $this->key. The last utility class to mention would be WireArray, which is meant for storing an array of objects. This one is a little more complex than the other two (though it's still quite simple), and I'm guessing it's not what you need in this case, so won't go into detail unless you want me to. You don't necessarily have to extend any of PW's classes. But if you want $this->property; access to the API variables, you'd want to implement your own __get() method in your class: public function __get($property) { return wire($property); // or Wire::getFuel($property); }

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.