ryan

The term "repeater" in our context means repeating the same type. What's being described above is essentially ProcessWire's pages system, and repeaters aren't meant to replace creation of page structures or groups of different pages. If there were a repeater type field that did that, there would have to be a different name for it.

I'm guessing he thought it was running under the same software as this forum (IP.Board) since it uses the same usernames and often the same avatars. But yes the modules dir is powered by ProcessWire and I can't imagine using anything else for it.

Page Inputfileds have to have directions on what pages should be selectable. Only you can know what pages you want to be selectable. The most common scenario is all pages having a certain parent. In that case, you'd set the parent_id property to be the ID of the parent page having those children. Another common scenario is all pages using a certain template, in which case template_id would be the property you'd want to set. There are also other options, like findPagesSelector where you specify a selector string to find the pages that should be selectable. If you'd like you can create+configure the field how you want it in Setup > Fields, then view the entry in PhpMyAdmin in table fields column data to see what options it stored.

There have been some good threads in the past getting into WireUpload usage, though not sure any of them were ajax specific. But it'd be worth browsing through some of these just in case. ProcessWire's InputfieldFile.module also uses WireUpload with AJAX so that might be good to look at as well. Using $_FILES[tmp_name] probably is not ideal because that's just the temporary PHP name and not the actual filename. Also, your code above is taking values from $_REQUEST without sanitizing them. In that particular case, I'd recommend pulling from $_POST (or better yet $input->post) rather than $_REQUEST, and running them through the $sanitizer->text(); function before populating to the page's title. Also, make sure you are validating the files that get uploaded, especially if only using $_FILES.

Are you sure that /stats/ is readable and that you are using it with a trailing slash, i.e. /stats/ not /stats ? ProcessWire should not take over unless Apache tells it to. There is a directive in our .htaccess that says "don't give control to ProcessWire unless the file or directory doesn't exist": RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d As a result, you shouldn't have to do anything else. But perhaps there are some other factors, like another .htaccess file somewhere or permissions on the /stats/ directory not being quite right. You shouldn't have to do this, but you could always add this to your .htaccess file to specifically say "stop processing these rewrite rules if the URL is /stats/": RewriteCond %{REQUEST_URI} !^stats You'd add that right above the other two mentioned above.

Based on your code, from what I can tell, you need to pass $features to the $map->render() rather than $placepage.

Since you are using language support, I think it'd be worthwhile to use the dev branch (2.3.7) either way. This also sounds familiar, like a bug that's already been fixed in dev. Though please let me know if you find it's not.

Any rich text editor is going to add a lot of overhead. I would probably limit your rich text editors to the admin rather than inline. Though there may be some combination of factors in your case that increases the overhead? What is dropzone.min.js?

Good idea, I'll add that. I agree. It could be problematic with some scripts. Perhaps it should be a configurable option as to whether scripts should be minified or not. Or better yet, an extra attribute on the script tag: <script minify> so it knows it's fair game. True, but we're talking about inline scripts in this case. I'm too lazy to go and re-minify inline scripts every time I need to change something.

You can use repeaters for smallish tables of data. In my own projects I usually create a custom Fieldtype/Inputfield for managing highly custom tables of data like rate tables and such. This is the most efficient way to do it, though not the simplest. But it may be simpler than you'd think. Most inline editing tools are 3rd party javascript plugins. It is possible to use just about any of these with ProcessWire, especially for text-based fields. But as ProcessWire does not get involved with the markup on the front-end of your site, it's something that you would need to implement. ProcessWire's API makes it a relatively simple job, but it's still development. You might also want to take a look at the Fredi module, a nice approach to front-end editing, even if not inline editing.

I'm not familiar with this. Is this something that there is broad demand for among other users here? Pete (forum administrator): if you are reading this, are you familiar with this and whether it's worthwhile to implement for this forum?

I haven't tried it, but you might be able to get this module to output in different languages by combining it with the LanguageSupportPageNames module.

Nice, thanks Pete. I just submitted it as an issue in the InputfieldCKEditor module, so hopefully the author will add it in soon.

FormBuilder is also a good way to go for contact forms, especially if you want to set one up without doing any development and have a lot of pre-bundled options as to where the submitted data goes.

If there was a way for us to make PW automatically reassign the $user variable after login, we'd do it. It's not technically possible for PW to do that (it's a matter of variable scope). That's why you'd have to do what Adrian suggested and assign the $user variable yourself from the result of login(). However, what Soma was getting at before he gave up was even better because it wouldn't trash the $user variable if the login failed. So something like this might be ideal: $u = $session->login($username, $pass); if($u) { $user = $u; echo "logged in"; }

What Wanze mentioned is the way to fix it. It sounds like the page just lost connection the Process, which can be easily fixed by editing the page and selecting the right Process for it. This can happen of you use the site profile exporter and don't include the 3rd party module files in your profile (that's the only way I've seen it happen), though maybe there are other ways it can occur too. It also sounds to me like you may need to increase the memory available to PHP. If a limit of 100 modules in ModulesManager works, but 350 doesn't, then it sounds like you are running out of memory. I usually give my PHP installs 128m or 258m for memory (depending on how big of images it needs to deal with).

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.