ryan

Also want to add: 1. Same goes for ui-widget-header => InputfieldHeader 2. Most of the time your CSS or JS selectors would not be referring to just "ui-widget-content" or "ui-widget-header", instead it would be a selector string that includes that somewhere, like this selector string ".Inputfields > .Inputfield > .ui-widget-header". 3. That kind of selector string above isn't really necessary with the new classes, as they are single purpose rather than the jQuery UI ones. Meaning, you could just specify "InputfieldHeader" rather than a stack leading up to .ui-widget-header. But for backwards compatibility, you'd specify both the old and the new, separated by a comma, like Pete mentioned. 4. The old way required some annoyingly specific selectors: .InputfieldHeader is the same as: .Inputfield > .ui-widget-header and this: .Inputfield > .ui-widget-header + .ui-widget-content is the same as .InputfieldContent Definitely one of the reasons why we're getting away from those jQuery UI class names. Not jQuery UI's fault, but we were just using them in a way to make PW fields theme-able (something jQuery UI's CSS framework wasn't really meant for). After some time, the only place that's really been worthwhile has been in FormBuilder (we'll keep using it there).

That particular line (when uncommented) would only fix the issue when the page is saved. Meaning, you wouldn't see the effects of it until after you'd pasted in your text, saved it, then viewed it again. Are you still seeing div's even after that? It'd be nice if there was a way to prevent CKEditor from creating these DIVs in the first place. There probably is a way, but I don't yet know what it is. I'm not sure why I commented the DIV replacement, guess I was assuming some might have legitimate uses for the divs or something... but they seem out of place in an RTE. You'd want to set ACF to be enabled (as it is by default) and that allows all tags/attributes that are specified by the set of the plugins installed to CKEditor. Then the extra allowed content lets you go beyond that with your own rules. Be sure to see the CKEditor documentation for this option, as there are quite a few capabilities you can specify in that string. The default ACF rules should restrict the tags to the basics. If you find it allowing something you don't want, then you may need to reduce your plugin set. I'm not sure if you'll be able to force specific attributes like you mentioned (short of using hooks to add them afterwards). As far as I know the allowed content rules are there to allow what gets through, but not to add attributes automatically.

Just wanted to make sure you guys had seen this section in the docs and especially this page. Chances are you have, but just double checking. If you are using multi-language features, you'll want to be running the dev branch (currently 2.3.5), not 2.3.0.

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.