ryan

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.

Felix, it'd be great to find a way to get your articles in English versions too, perhaps published on your own site or here. I think there's a big audience that could benefit that might otherwise miss it due to not knowing German (and the imperfect Google translations). Though the same could be said for translating to any other language too, but I perceive ability to read English is a common element among most of our users. Though it does seem like most of our audience reads German too... I think I may be one of the few here that doesn't.

Good to hear about the new version of Foundation! I will plan to update this profile for Foundation 5 (and add any other necessary description files) as soon as there's time to do it.

I've recently built out a site that does exactly what you are describing. Users can create an account. Once approved as an editor, they have the opportunity to "submit new product" or "edit this product" (appears when viewing a product page). The submissions go into a FormBuilder queue, where the site managers review and approve them. When approved, they go straight into a page (whether new or existing), and the entry gets automatically deleted. The edit product form essentially looks like this (even though this is technically the search page). I would link to it directly, except they wanted the add or edit form submissions to be limited to registered users. All the forms on this site, including user registration, login, search and edit/add products are all done through FormBuilder. Though FormBuilder is not a turn-key solution for this stuff, as some development was still involved (primarily via FormBuilder hooks). But this site had to be developed in a very short period of time (a few days) so FormBuilder and the Foundation profile came in handy.

If that works, I think it should be fine. Another way to do it is to enable $config->advanced=true; in your /site/config.php temporarily, and you'll see a new "system" tab appear when editing a template. There is a checkbox there to disable the settings tab. But note that applies for everyone, not just a single role. If you use this, remember to change $config->advanced=false; as it's not intended to be something you leave on and some settings it offers are irreversible (thus can be dangerous).

You could always create an XML file in multiple stages and keep appending to it. If you are filling up memory even while using the $pages->uncacheAll(); as described in the original post, then you are probably filling up memory as a result of the output you are generating. In this case, it does make sense to write to a file and do it in chunks rather than all at once. What i mean by write to a file is fwrite($fp, $data); rather than echo $data; Whenever you fopen() a file, you can choose "a" as an "append" write mode, which means anything you write to it will simply be appended to what is already there. Chances are it'll take some time to write out 10k+ pages, so you'll need to ini_set('max_execution_time', 60*5); // 5 minutes or however long you need. Lastly, consider whether you really need a sitemap.xml and if it's worth the effort. My experience has been that so long as the site has good internal links, a sitemap.xml doesn't provide any perceptible benefit other than adding some fun to the webmaster tools screen. Though maybe others have a different experience.

You should be able to remove these files and it will immediately re-create them. One represents the list of modules in /wire/modules/ and the other in /site/modules/. You shouldn't ever have to manually edit them (at least I never have). If you got an error after removing the file, that sounds like your file system is not writable (and it was unable to create a new one). This would also explain why it was unable to see new modules. Try enabling debug mode and doing it again, as I'm guessing you'll see an error message about file permissions. You most likely have to do a chmod -R (or the recursive equivalent through your FTP client) to add write access for your web server on /site/assets/. Note that lack of write permission to anything in your /site/assets/ could create any number of other problems too. When ProcessWire creates files in there, it makes sure they are writable. But if you transfer files yourself (via FTP or something else that doesn't include permissions) then you would have to restore such permissions.