ryan

That kind of selector could yield wrong results. If you are finding by ID, then you should really be using page references, not text fields. If you were searching for id "123" the selector above would also match "2123", "1234", "9912399", etc. That's why it could be problematic. If for some reason you needed to search this way (using text fields rather than page references) you'd be better off using the "~=" operator, which matches whole words and should provide more accurate results for that scenario. But this is a situation that really calls for page references (FieldtypePage).

I'm confused, why are carts pages? The way I usually think of carts is something that would be a session variable specific to a user browsing your site, not a permanent fixture in your page tree. I'm not sure storing user carts in this way would be a sustainable. Carts are something that you'd usually want to store in a session or cookie, and not convert it to any permanent server-side storage until it's a completed order that you have to fulfill.

You should be able to specify whatever you want the option labels to be in the field's settings (input tab). If you want to specify multiple fields, get the FieldtypeConcat module, which helps to accomplish this. Of course, this is the way that page references work by default. ProcessWire only stores references to a page (by ID). The title is just a label for selection purposes, nothing more.

Pete, I've really been enjoying this module. For the new admin theme, I had to make a small adjustment (margin-left: 0) to the last part in the CSS: #Inputfield_admin_column_left > div, #Inputfield_admin_column_right > div { background: none; border: none; padding: 0; margin-left: 0; /* ryan added this */ } That change doesn't appear to cause any issues with the old admin theme either.

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.