ryan

There isn't a way to turn it off, as it would render PW's $session variable useless, and break anything that used $session. Though if using ProCache, it bypasses ProcessWire and sessions, on any cached pages.

Unless I'm missing something, randomBase64String should be bound to the same characters that an MD5 hash would be. Base 64 strings are compatible in GET vars or even URL segments. It's just ascii letters and numbers.

I'm not sure what the value of sorting by "id" is, but if it's for chronological reasons, consider using "created" instead as your sort field. That's going to be more reliable to achieve the same purpose.

No need to escape commas. Just make sure your string is wrapped in quotes (whether double or single quotes), and that it doesn't already have those quotes within it. Chances are wrapping it in double quotes will suit you better since a page title is more likely to have an single-quote style apostrophe than a double quote.

Your $modules->get('MarkupGoogleMap'); call failed. Chances are you don't have the MarkupGoogleMap module installed or are running an old version of FieldtypeMapMarker.

ProcessWire doesn't know anything about PDF files. And the file size is not large, so I think we can rule out a max_upload_size issue. If something is interfering with the upload, it would have to be lower level in the server (Apache mod_security maybe doesn't like the filename or something in the PDF file?)

Sounds good to me. But I haven't seen enough Hanna code snippets posted to make me think there would be much demand for a directory of them yet.

Joe, did you read the message above yours? You can set allowedContent with a radio button in the field settings. These's no reason to add config.allowedContent (unless you've taken over the config.js completely).

Just replied to another message from you that is almost the same as this. But I think this message maybe points to the Thumbnails module as being the one that is calling upon JqueryFancyBox. Probably the Thumbnails module should only call upon JqueryFancyBox when in admin/page editing mode, rather than in API usage.

JqueryFancyBox is not an autoload module, so there is very likely some other module you have installed that is calling upon JqueryFancyBox. You could tell which one by putting your site in debug mode and then adding this to the init() or __construct() method in /wire/modules/Jquery/JqueryFancyBox/JqueryFancyBox.module file: throw new WireException('gotcha!'); That should give you a backtrace dump indicating which module loaded JqueryFancyBox for you. (very likely an autoload module) Remember to delete that exception afterwards.

Yes, the current version of FormBuilder (0.2.2) is compatible with both dev and stable. When using the dev branch on a live site, understand that stuff gets pushed to the branch that has only been tested by myself and in my environment. So you'll want to test upgrades on a staging server (like your own computer) before migrating to live. Test that all key functionality in your site still works the way you intend. I also recommend giving yourself a way to step back a minor version if you ever need to. I do this by moving the previous version's /wire/ dir to a versioned one, like ".wire-2.3.3a". You want to precede it with a period just so that the directory is not web accessible. But that gives you a way to step back to the previous version, just in case (though can't say I've ever had to).

This is great, thanks Teppo! This is something I have wanted but just didn't know how to do. I will definitely be using this.

The way Soma mentioned is correct. Double check that you are up-to-date on the PW dev branch and that you have the LanguageSupportPageNames module installed (I'm assuming you do, but just double checking). Next, is $english your default language? If so, then you should set it with the 'name' property (without any language appended to it). Your code doesn't indicate it's setting the values for the default language, and that would be a requirement for a new page. setLanguageValue() is a function of custom multi-language fields, and it's what is returned by FieldtypeTextLanguage, FieldtypeTextareaLanguage, FieldtypePageTitleLanguage. You'll only use this with multi-language fields of those types you would see in your admin under Setup > Fields. Both 'name' and 'status' are not fields -- they are properties native to all pages an they are simple types: name is a string and status is an integer. Any multi-language properties like this are set by appending the language ID to the property name, i.e. $page->set("name$spanish", "la-latina"); But if you are just setting the default language value, then no need to append the language, as you would just do $page->set("name", "something");

Btw, most objects in ProcessWire can also just be typecast to strings, which usually gives you the intended value. This would be the case for a LanguagePageFieldValue object too. $value = (string) $object;

I'm not exactly sure how those retina clients are testing for the existence of the @2x version, but if it's doing it by seeing if the request results in a 404 or not (which is what I'm assuming), then you should be able to accomplish this with an Apache rewrite rule in your .htaccess file: RewriteRule ^(site/assets/files/[0-9]+/.+)@(2x\.[a-z]+)$ $1_$2 That would convert a request for /site/assets/files/123/filename@2x.jpg to /site/assets/files/filename_2x.jpg

ProcessWire 1 had built-in live drafts and versioning. I was particularly proud of these features, but I was always surprised at how little they were used. It turns out that most end-users don't actually write content in the CMS. They tend to go to the CMS when we are ready to publish something. This doesn't define everybody, but I think it defines most CMS end-users. At least that was my experience, repeatedly. As people building sites and applications, I think we tend to assign more importance to these things than they deserve because we ourselves are much more likely to use the CMS as a composition tool than our clients are. This is why live drafts (drafts of already published pages) have not been high priorities as yet in PW2. But there is that small group of clients that these features are actually quite important. That's why this is something that I think belongs on the roadmap. the strategy I'd planned to take was to clone the live page to a new but unpublished page that would become the live draft. It would have an extra field (behind the scenes) indicating that it's a variation of another page. When the editor wants to publish it to be the live page, it would push the unpublished page's data to the live page's data, and then delete the unpublished page. This is important because the original page ID needs to remain in tact. That pushing of data gets a little tricky when it comes to some fieldtypes (like repeaters and files) but that's where the fun will be. Side note, but protected methods are still hookable. The only methods that aren't hookable are those that aren't preceded by 3 underscores.

Adrian, the Pagefile::install hook should be triggered so long as the file doesn't already exist in the destination. Is it possible that the files are already in /site/assets/files/.../? If so, the file doesn't technically need to be installed, so the hook is never called. As for getting the field belong to a Pagefile, this morning I've committed an update (to dev) that makes that possible. You can now retrieve the Field object that is part of the Pagefiles/Pagefile in the same way you can retrieve the $pagefile->page, by accessing $pagefile->field (accessible from the pagefile or from the pagefiles array).

I agree with Pete that it'd be good to use different templates for your different types of products, as this fits the definition of a template. But if this is going to lead you to creating dozens of very similar templates, then I'd be less enthusiastic about that. If that's the case you may want to delegate your product options to a tree of page references (using PageListSelectMultiple inputfield maybe). If the options are very simple, you could always just identify them with each product in a textarea field (one per line). Textarea fields can be quite useful, as you can explode("\n", $page->textareaField) to convert it to an array and generate select options/radio buttons, etc. But you'd only take this path if the options were generally unique per product.

This probably doesn't cover all that you are talking about, but you might find this post interesting, as it gets into how to build simple custom workflows with ProcessWire.

Not sure I follow. Can you post a screenshot of what you are talking about?

ProcessWire originally used ui-widget-content (and ui-widget-header) classes so that it could be themeable with the jQuery UI themeroller. But that was never as popular as I thought it might be, so I'd rather just get away from using those classes for PW's Inputfields and instead leave them just for jQuery UI widgets--this simplifies the CSS quite a lot. I also want to use jQuery UI more consistently with what it was meant for (actual input widgets). So what you see in the new admin theme is replacing ui-widget-header with InputfieldHeader and ui-widget-content with InputfieldContent. This is done by the /site/templates-admin/init.php file, which tells PW's core to use a different markup than what's in the core. The core will switch to these classes as well, but the current default admin theme will continue to use them, as will FormBuilder (where jQuery UI theming is more relevant there). If you've got some jQuery selector that is referring to a ".ui-widget-content" you might want to replace it with ".ui-widget-content, .InputfieldContent" so that you are covering both old and new admin theme. This is better than just replacing ui-widget-content with InputfieldContent. Same goes with ui-widget-header and InputfieldHeader. This is what I've done with any core modules that needed to refer to these wrapper classes in the JS or CSS. Unrelated question: for folks that are complaining about jQuery UI--what alternative do you propose? I'm not aware of any other jQuery based library that can do the same things better or faster than jQuery UI. jQuery UI also brings us a lot of great input types (current and future) that we would not have otherwise. Now that we are moving towards using jQuery UI more consistently with how it's intended to be used, I think it's quite a good long term solution. But if you guys have found something better (that's not extJS or bootstrap) then please share it.

@mackski, thanks for your module, please add to the modules directory when you get the chance. To be honest, I can't tell the difference here on my desktop, but then just tried on my notebook and it did seem faster (maybe) but cutting out the animation. I went ahead and added it as a module configuration option for ProcessPageList (Modules > Process > PageList), now available on the dev branch. Try changing it from 200 to 50 ms (or even 0 ms) and see if it makes a difference? It might. I think we just need more people to test it.

The LanguageSupportPageNames on dev core (2.3.5) is much farther along (and more stable) than the one on stable core (2.3.0). If you want multi-language support, you would benefit a lot from using dev. There are still bugs being worked out here, but most of them are ones that only affect Soma and his advanced usages but they are all issues that will be fixed before dev becomes the stable 2.4.

Thanks Diogo! That did the trick. I've posted the latest update to the admin theme on dev and this includes the bundled Arimo fonts. I'm curious if this makes it look better for you guys on Windows? This update also includes several other tweaks and minor fixes.

Adam, the LanguageSupport modules can't be pulled from dev and put into another version. There are many upgrades to the dev core in order to support the features of LanguageSupport. The LanguageSupport modules wouldn't work if you tried to take them from the dev version and use them in an older version of PW. If you want the features provided by the latest LanguageSupport modules, the best route is just to use dev. If you find it to be stable for your site's needs, then you should feel comfortable that it'll be as stable as the actual 'stable' branch. Just test thoroughly. The main thing you have to pay more attention with on dev is when upgrading from stable to dev or from dev to dev–you just want to test a little more than if you were upgrading from stable to stable. But once you have it up and running, you can generally expect the stability to be the same as the stable branch.