ryan

I'm not aware of all the considerations that may be necessary for using the blog profile with Chinese characters (not had a chance to try that yet), but you may be able to resolve the issue you mentioned by changing that substr() to an mb_substr(). I'm not sure I fully understand the question or what you mean about a bootstrap-based template? But this blog profile demonstrates that tags are nothing more than just page references, and it's really more a matter of terminology (calling it "tags") and implementation on the front-end than anything else. So the means by which tags are implemented in the blog profile translates to any PW installation, and doesn't matter what CSS framework (or lack of one) is being used. You can think of the "Page" fieldtype as a tags fieldtype where it makes sense.

I think what you want is to hook after ProcessPageAdd::buildForm. That returns an InputfieldForm object, that you could manipulate with an 'after' hook. The only problem is that method isn't currently hookable. But you can make it hookable by editing the file and prepending 3 underscores to it, i.e. "buildForm" => "___buildForm". I will make this same change in the core source and you'll see it in the next batch of dev commits.

You can treat it as a placeholder if you want to. There isn't anything that says you have to make it part of your site. But it generally makes sense to consider the default language the one that is most common and most populated in your site. The nature of your statement makes me wonder if you might really be looking for a multi-tree language approach instead of multi-language pages? Using separate trees for each language is a fine way to go, and in fact the recommended way to go when you have different structural needs for each language. It's also the simplest one to develop, as it requires no multi-language modules to be installed. But it does mean maintaining each of your languages independently. Unfortunately I don't have enough experience with the LanguageLocalizedURL module to offer any advice on it. I've not developed a site that uses it. I'm not sure if this module is still in active development?

Or in this case, just PHP

I don't personally exclude anything when migrating a site from dev to live. While it might make sense to exclude things like /site/assets/cache/ and /site/assets/sessions/, it's also not entirely necessary as those things are already under automatic garbage collection/clearing. You do need to make sure that those directories exist though. So if you exclude them from the copy, double check that the directory still gets created. I see no problem with excluding those directories (and /site/assets/logs/ if you want to) as long as you make sure they get re-created in the destination and are writable to PW.

You are performing a text query, and that is only going to match the pages that contain that text in the field you are searching. it sounds like you want it to pull other pages that don't contain the text, but that are somehow related to the ballard page? In that case, you probably want to take the page result matching your text query (the one from the people category) and then, with that in hand, find the related event pages. I'm assuming you are using page reference fields for all of this stuff. Lets say your event template contains a field called "people" that references the people related to the event. Since your search results page has the person, but not the events, you could find the events like this: // find any page referencing this person // $page is the 'person' Page $related = $pages->find("people=$page, sort=title"); // or find just events referencing this person $events = $pages->find("people=$page, template=event, sort=-date");

Okay I understand now. I think I can safely move the call to JqueryFancybox to the render() method, which should fix this issue.

The case would no doubt be entity encoding. It sounds like maybe double entity encoding? I did just try adding quotes to the summary for Helloworld.module, and am not seeing double entity encoding though.

That's correct, PW will delete install.php if it can. I'm also in MAMP, and install.php gets deleted for me after installing.

Arcturus, Go to Modules > Process > Users. It should let you select what fields you want to be shown in the listing, and in what order. As for changing the name of the "name", I don't think you can do that short of going through a hook or using the multi-language translation system (and translating the default language value). If you want to do that, the file where it is located is /wire/modules/Process/ProcessPageType/ProcessPageType.module in the renderList() method. Of course, you could just change it directly in that file, but your change would get overwritten during upgrades, so you'd need to remember to change it again.

I agree, it sounds useful. Maybe in the short term, we should just add a new board here called "Code Snippets" and perhaps have a few categories under it? Once there's a good supply of stuff in there, we could make a more dedicated platform for it.

Thank you Soma!! Adding width: 100%; fixed it here. This will also appear in the next update.

I'm not seeing that here. Can you post a screenshot? Thanks, I was wondering how to correct that. Your solutions works well here. I'll include it in the next update. This has been driving me nuts too. I just don't know how to fix it yet. If you guys figure it out please let me know as I'd love to fix this one. Thanks, I'll correct that in the next update.

Nice module you've put together there Yannick. Only thing I want to mention is that ProcessWire already has a $log API variable (see here) in the dev branch. The syntax of the PW $log API variable is very similar to yours, though it also supports writing to custom logs, but lacks the render() method that you have.

This is a great post–these all seem like excellent practices Peter, thanks for posting them. I'm not sure you necessarily need the extra Apache authentication, but it certainly can't hurt to have that extra layer. I'm also glad to see how that's implemented, as I didn't realize how. As an extra layer, you can also enable the SessionLoginThrottle module (that comes with the core) if it's not installed already.

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.