ryan

Looking nice Harmster–thanks for sharing this with us and keep up the good work.

You will probably have to make edits to several files in there to adjust the paths it references to be consistent with the paths in your site. For instance, if you see a $config->urls->root . "archives/"; then you'd change that to $config->urls->root . "blog/archives/"; and if you see a $pages->get('/posts/'); you'd change that to a $pages->get('/blog/posts/'); And so on. I'm guessing most of these updates can be to the files in /site/templates/markup/ and /site/templates/blog.inc, but you may need to look at all the template files used by the blog profile.

I don't know on the multi-site module side (haven't yet used it). But in your case I'm not sure you necessarily need or want the LanguageSupportPageNames module. All you need to do is detect the language from the hostname in your head.inc or $config->prependTemplateFile. The fact that the hostnames select the language makes everything simpler. if($config->httpHost == 'www.website.nl') { $user->language = $languages->get('nl'); } if($config->httpHost == 'www.website.de') { $user->language = $languages->get('de'); } else { $user->language = $languages->get('en'); }

Beyond what Dragan mentioned, it'd also be good to look at what 3rd party modules you have installed, just in case any of them are interfering. For instance, 2.2.9 is now an older version of PW, so you may have a module that was meant for 2.3+.

Page numbers are runtime directives like URL segments, not part of the actual page's path. Consider what you see in the tree in the admin–those are the pages. As a result, you shouldn't try to retrieve a page with a page number in it–leave that part off. Next thing is that I'm not positive about the ~= operator in this context. You might need to use %= or *=.

Thomas, I'm finding this block of code really difficult to follow. There may be issues here that we can't be certain of without stepping through it live. I think there might be benefit in refactoring it. Beyond that, I suggest doing a wire('sanitizer')->entities('text'); on the output you are sending through $this->message(), as that seems to be vulnerable to XSS injection (though maybe you are just using that for debugging). I also have some concerns about this method of presenting different language content on a site because it uses the http_accept_language header rather than a defined URL. That could create some potential SEO issues. Though if search indexing is not a concern here, then it should be ok. But the other disadvantage is that it's relying on session variables to determine output, preventing it from being cachable (whether with the built in template cache or ProCache). Regardless of which direction you go, you may want to use the dev branch just because it has better multi language support.

Glad to see Foundation5 out. I've spent some time there and like what I see. Though I tried to install the SCSS version and can't seem to get my computer to meet all the dependencies (I'm running an old OS X), so looks like I'll have to use the regular non-sass version. But other than that Foundation5 really looks great. I'll plan to upgrade the Foundation profile in January when my schedule starts to clear up a bit here. I want to get PW 2.4 released stable before that. As for how to use the interchange plugin (whether in or out of PW), I think that Foundation's docs will probably be the better place for that. But if I see any good opportunities to use it in the profile update I will.

That's a good observation. That must have started when I added the version checking code to GitHub. It now updates each module page with the date of the last time it checked the version. The problem here is that it's also updating the 'modified' timestamp of those pages, which is in turn appearing in the feed that ModulesManager uses. The good news is that an option was recently added to the core (on dev) that can prevent this: $pages->save($page, array('quiet' => true)); That 'quiet' option tells it not to update the modified date or user, which will be perfect for this particular situation. I'll plan to get the modules directory updated with this option soon.

I think WillyC is correct on that one. The term "font" means an entire character set. As for the resulting logo: Whether in an SVG, font-set, PNG, GIF, JPG, EPS, etc. the logo is a flat image (whether vector or bitmap). The file format means little. I don't see any difference between a font-set with the PW logo in it and a PNG or EPS file of the logo.

If a page is unpublished, PW won't let you publish it until you can save it error free (meeting required fields, etc.). If the page is already published, then ProcessWire is not going to prevent you from saving it, but will warn you that the field is required.

I am thinking that Google News provides some other options here. We had to setup a custom XML news feed that adhered to Google's sitemap-news format. In addition, the feed could only show news articles posted within the last 48 hours. There were no requirements about 3 digit numbers.

What Soma said. ProcessWire promises the Fieldtype interface that it will have an actual Page to work with (one that has an ID and a place to store files, etc.). It could be reduced to 1 step by automatically creating that page whenever you click "new", but you'd likely have plenty of accidental pages as a result. Also, as a best practice, GET requests should not make changes to database or disk, so it's always preferable to submit a form before creating a new asset.

That's because the "page10" portion is not part of the page's path in the system. It's just an extra instruction to the page, like a URL segment, telling it to use the 10th pagination. In this case, you'd want to trim off that "page[n]" portion. There's any number of ways to do that, but I'd probably just use a regex: $title = 'http://host/gallery/page3'; $title = preg_replace('{page[\d+]/?$}', '', $title); echo $title; // should output "http://host/gallery/"

Your best bet is to do something like this: if(!is_writable(wire('config')->paths->templates)) { $this->error("Please make your /site/templates/ dir writable to use this module."); }

I'm not aware of anything related between that setting and users or passwords. Is it possible that a PHP version downgrade (into a version 5.3.8 or before) happened at a similar time (whether by migration or on the same server)? That could potentially account for the behavior you described.

If the issue is showing up in Chrome and not Safari, is it possibly just a browser cache issue? Have you tried clearing the cache, quitting the browser, etc.? I had Chrome pull a similar trick on me recently.

Sounds like a bug, but could very well be one that's already been fixed in dev. What version of ProcessWire are you running?

I think that this change should be okay, I can't think of any potential side effects here. I make the same change here–thanks!

If you are getting a redeclare error, then you'd just use require_once() rather than require(). That tells PHP to include the file only if it hasn't already been included. That should accommodate either situation.

That's interesting about the language rules there and I probably should have realized a space was not universal. If there simply is no word separator, then I suppose there's no need for that 2nd mb_substr() that truncates to the last space ... I'm guessing you can remove that entirely. Depending on the length you need to truncate to, trying to locate the last "。" and truncate to that might sometimes result in a non-match, but otherwise seems like a safe bet (for reasonably long truncations).

Have a look at mindplay.dk's Template Decorator module. It's a good example of doing this by hooking into ProcessTemplate::buildEditForm and ProcessTemplate::executeSave.

I've got my version of the Minify module set to minify only when $config->debug == false. This is one of the updates I was going to submit a PR for.

In this case, I'm not sure that it would matter whether precision was set in construct or init. They will both be called before a sanitizeValue(), render() or processInput. Are you seeing a different behavior by moving it? Also, for lat/lng coordinates, I recommend setting the precision to 6. If you don't need to make calculations on the values in queries, then I'd just use a text field (rather than float field) to store your coordinates. You might also want to look at the FieldtypeMapMarker module, which bundles in all the map data into an easy-to-use field. Though not sure you could import to that with ImportPagesCSV, though API imports to it are an easy matter.

In this particular case, the users don't get to directly edit a page they just created. That's because when they submit a form, it doesn't go straight to a page. The admin sees the form submission in the FormBuilder entries queue, and then they decide whether it gets sent to a page (by checking a box and clicking 'send to page'). Subsequent edits work the same way. This was specific to the needs of this client. The reality is most of the logic of how you want it to work is using traditional PW API code rather than anything FormBuilder related. Though in this case much of that code is placed inside of FormBuilder hooks. On it's own, FormBuilder is basically a contact form generator with lots of options about where the data goes, and it's not necessarily going to be the right tool for implementing more complex application logic forms. Though it can be used for that, but I think most are better off sticking to PW API when it comes to these kinds of needs. That's because using the PW API, you can make it do exactly what you want without considering too many other factors.

I fixed the issue referred to in Nik's GitHub issue report (thanks Nik). As for sorting the items in the repeater, I think the situation you are trying to accommodate here is a little unusual. Wouldn't the date field be associated with the 'event' rather than for some repeatable field within the repeater? It can't sort on eventdetails.date because it's not referring to any single date, but rather any number of potential dates. What I'd suggest is adding an 'date' field to your 'event' template that represents the event starting date. But if you want it to work with what you've already got, then I suppose you could query the repeaters rather than the events (though I've not yet tried this): $events = new PageArray(); $items = $pages->find("template=repeater_eventdetails, date>0, sort=date, include=all"); foreach($items as $item) { $event = $item->getForPage(); if($item->isPublic() && !$events->has($event)) $events->add($event); }