ryan

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); }

I'm very enthusiastic about composer support. The dev branch (PW 2.4) has already switched to PDO. Though it still supports mysqli for the 3rd party modules that use it. The $database API variable refers to WireDatabasePDO connection and the $db API variable continues to refer to the mysqli connection (which is now lazy loaded–no connection made unless a module or one's site asks for the $db variable). 2.3 dev/2.4 includes a module installer/updater from the admin. It's essentially a bare essentials version of Soma's ModulesManager (using much the same code actually). I do like the idea of providing another module installation option via composer. All 3rd party PW modules are inside /site/modules/ whereas all core modules are installed in /wire/modules/. So I think the answer to your question is /site/modules/, though am not sure how that works or is compatible with Composer? I noticed this issue several times when converting from mysqli to PDO. Good thinking on your solution there! Another shortcoming I noticed of native PDO is that there's no way to bind table names like you would parameters. Hold the image in that first spot for a second and the sorting should realize what you are trying to do. If the behavior is still not there, try editing your image field (Setup > Fields > your image field) and changing the default layout to be the grid rather than the list. Does it make any difference with the behavior? I've not experienced this behavior. Anyone else run into this? I hadn't run into this issue yet, but just confirmed it now. Glad you know what was causing it! I would have probably spent hours trying to figure that one out. I think the best bet is just to remove the 'overflow-y: scroll' or make it conditional. The jumping on the menus is only a minor annoyance, whereas the lack of ability to drag beyond the visible portion of the screen is a big problem. What if we just added the 'overflow-y: scroll' conditionally, when the height of the window's content area is greater than the height of the window?

That sounds really unusual. I'd probably be looking at the webhost to see if they are stripping it out before ProcessWire gets to it. Just because some other fields work (or it works in language mode), doesn't necessarily mean they aren't doing it... mod_security rules can be triggered by combinations of things that don't always make much sense from our context. Just as a test, try adding this to the top of your /site/templates/admin.php: wire()->addHookBefore('InputfieldTextarea::processInput', function($event) { $textarea = $event->object; $name = $textarea->name; if($name != 'your_field_name') return; $value = wire('sanitizer')->entities($_POST[$name]); $textarea->message($value); }); Try saving a page with that textarea field on it containing some text. Does the green message at the top of the screen contain HTML? If not, it's probably being stripped out by the server before PW gets to it. The hook above is looking at that field before anything else in PW touches it.

Yeah I haven't figured out how to resolve that one just yet. Luckily core module additions are fairly rare, and in this particular case, that module will install itself. It sounds like you just made it to the modules screen before the page editor (with an image field), otherwise that module would have been already found and installed. Magnific Popup has replaced Fancybox for InputfieldImage. But FancyBox will remain in the core for now, as I know some modules (and sites) still use it. I'm also in OS X, though Safari 5.1.9. I haven't been able to duplicate that issue. It sounds like a javascript error though–check to see if anything appears in your JS console? In Safari that's: Develop > Error Console. Glad to hear the new font size renders better with Arimo and Windows/Chrome. I've not put much attention towards translation of this particular module since it is largely a tool for translating from English to other languages. I think those are translated with the field names. Some may be under the "show system fields" filter. Though to be honest, I'm not positive we're pulling the translated versions here or not. I'll check on that, as I've got some other related updates to cover. Thanks–I can see that here too. That button probably shouldn't be showing up at all. I'll add code to skip the button cloning when in modal view. I've used superfish before, and did like it. But kind of wanted to stick with jQuery UI here since we're already including it. We might as well use the tools that it provides when possible because there's no extra overhead in doing so. I'd be okay with pw-* (even if not as clear in code) but just wanted to have an expected/standard set of icons that modules know is always there. If something happens with font-awesome down the road, or we find a set we like better, I like the idea of being able to substitute the existing icon-* rules with another set, without everyone having to go in and change their class names. Just the term "icon" is a lot of clarity for code and seems like a good standard in our environment. I'm not really worried about collisions here since the admin is a more isolated environment. We aren't telling people what they have to use in their websites. Just telling Process module or admin theme developers that they can rely upon an icon-* set being available, regardless of what that may point to. But I don't really feel that strongly about this, and it doesn't matter much to me either way. The old admin theme will remain as a core-bundled option for IE8 support. Though admittedly I don't do any testing with IE8 and PW, so am not sure to what extent even that is compatible with IE8. This was a bug that was there for a day or two, but should be fixed in 2.3.7.

Are you sure (on 3 digits)? We didn't have to do that on the CMSCritic site, though I think we had to setup a custom news feed.

You can use fieldsets, but not tabs.

I made the logo. Its just mahalia and avenir (which I licensed through myfonts.com). Its totally fine with me to have the logo font (i love it!), so long as it's ok with the fonts/license (?). I would think it would be, but maybe somebody else knows more about this.

Sideshows and rate tables are examples of good use cases. Anything naturally bound by scale that produces in-page components, rather than groups of data that need to be represented by their own URLs. This sounds like another good use case example. Who said anything about phasing out repeaters? That is definitely not the plan. I currently have a big to-do list of items to improve repeaters, which I'm slowly working through. But just wanted to clarify that we're not trying to follow the path that Craft has taken.

Thanks Roope, I'll take a look at this and see if I can duplicate and find a solution.

Regardless of whether it would be useful in this instance or not, if it'd be useful to have this type of hook for anyone, I'd be happy to add it. Though rather than having the code in Database.php (now WireDatabasePDO).php it would instead be added as a hook that a module could monitor and take action when desired. I did get a preview of mindplay.dk's module and it's very nice. Rasmus I hope you get the time to finish and release it sometime, you always do great work. You are right on that from a portability standpoint, as the IDs may not probably won't be the same between systems, so could never be relied upon. But I suppose the queries could always be altered to reference the name rather than the ID. I'm not sure that I necessarily understand on this point or if it's something that can't be worked around, though you've obviously spent more time coding towards this need than I have. But just to help me understand, can you give an example of what you mean?

It doesn't matter. Either width() or width can be used in that scenario. When using the non-function version, $page->image->width then you are just retrieving the width. When using the function version you can retrieve or set set the width. $width = $page->image->width; // get the width $width = $page->image->width(); // get the width, same $thumb = $page->image->width(100); // get image having width 100 Same goes for the height.

I also share Mike's opinion, that forums are best left to dedicated software and we've already got a lot of great options. Part of this is that I think the huge scope of forums and the potential needs are not apparent until you run one. A CMS dedicated purely to community generated content (forum software) is a completely different animal than another type of CMS. The focus of features needs a very different slant, especially on the administrative side. What I'd be more interested in is bridges between ProcessWire and forum software, so that one can more easily communicate between the two. I know that Pete has been working on and off on this stuff for awhile with IP.Board and ProcessWire. Hopefully we'll be using some of those solutions on this site eventually too.

Actually this is very applicable stuff and I think everyone here is interested. I know I am. Thank you for posting! please keep doing so.

Or you could go in the opposite direction and minify all your output, and never again worry about what it looks like to others because... it's all on 1 line and you are doing it in the name of saving bytes! I'm actually using this in my latest project and quite happy with the result. Though I've made some modifications to it (to account for removal of Javascript comments and leaving textarea fields alone), which I still need to submit as a PR to michamichamicha.