ryan

Sir Trevor definitely looks interesting and a great idea. It seems like this could solve a lot of the bad-markup-from-RTEs issue. Though I'm not yet convinced this is better than an RTE for most. At least in testing it out here I found it to be more of a hassle inputting content... though maybe it's just something to get used to. I'm also looking for how to input headlines and not seeing the option to do so--I'm assuming they'd do that with one of the "+" plugins. But it does call into question how clients would go about pasting content in a convenient manner (probably the most common input methods clients use). But this does seem like a good project to keep an eye on.

Not currently, but if there's enough demand for it perhaps we could add a checkbox to the FieldtypeImage field settings that amounts to the effect of "prevent this field from being used in textarea fields".

You may need to test to find out for sure. But if you find it's not exhibiting the behavior you need, I should be able to track down the line you'd need to change and suggest what to do.

Recent versions of the dev branch add some more classes in there (if I'm remembering correctly) to make more style options possible in the pagelist. The separator character is now added by CSS rather than being in the markup, which is probably why it started showing up there. If it turns out to be problematic, I can change it back to a non-css solution for that.

Most likely you are competing with a hook running from LanguageSupportPageNames. I'm guessing your hook is running and doing something, and the hook in LanguageSupportPageNames is undoing what you did. Since LanguageSupportPageNames is using "saveReady" rather than "save", by you switching to "save" I think that's why your results are more predictable. If you really needed to use saveReady, you may also be able to resolve the issue by setting a hook priority value or attaching your hook at a later point than LanguageSupportPageNames does (perhaps in a ready() rather than an init, or a render() rather than a ready(), etc.). But if the "save"hook accomplishes what you need, I'd stick with that solution.

The problem here is that you are outputting the same exact thumbnail 4 times. I'm guessing maybe something like this is what you wanted? <div id="portfolio_list"> <ul class='bxslider'> <?php $features = $pages->find("template=project, sort=-date"); foreach($features as $feature) { $thumb = $feature->thumbnail ? $feature->thumbnail->width(800)->url : "http://i.imgur.com/1zxfxMW.jpg"; echo "<li><img src='$thumb' /></li>"; } ?> </ul><div> Either that, or if you were wanting to output 4 images from each $feature page, then you'd want another foreach within that loop that iterates over the images in $feature.

Also make sure that you have writable and existing /site/assets/cache/ and /site/assets/sessions/ directories.

What address are you trying to geocode? I want to try it here just to see if there's something unique about it that might be confusing Google's geocoder. Also, when the JS geocoder runs, it should bypass the server side geocoder unless something changes about the address during the save. If that's not the behavior you are getting, let me know what browser and version you are using \.

While I agree that the ID appended fields may not be perfect, they turned out to be the best option after considering many others within the context of the entire system. The direction was chosen very carefully, and I have worked on multi-language databases setup exactly as you described for mass data conversions. There are a lot of considerations that go into the structure that was decided upon from selector engine findability to compatibility, ease of conversion from/to multi-language, eliminating potential overhead for non-multilanguage environments, support for different types of multi-language environments, overall efficiency/speed and much more. The longer term plan is to outsource the ID to a separate table and use predictable names for the current ID appended versions, but that's just a minor change as a matter of portability and not going to matter to most. I also want to mention that we already support any field being multi-language via Language Alternate fields, which may sometimes suit your purpose better than multi-language fields, even for regular text fields. Nothing about using the LanguageSupportPageNames module (which adds the new name columns as needed) interferes with name being required to be unique within the parent. That aspect remains regardless of whether using multi-language page names or not. However, it is possible for more than two languages to have the same name for the same page, and this is intended. Some languages use the same terminology and words, so it would actually be a limitation if we enforced uniqueness across them. It also enables use to fall-back to the default language for instances where someone wants to use multi-language page names in some instances and not others. In a multi language environment, the language is determined from the overall path, not the individual page name. This is an important aspect of multi-language page names, as there is often a lot of crossover in terminology between different languages. This is one reason why we recommend (though don't require) that you at least set a starting segment for the language on your homepage, i.e. /de/, /en/, /es/, etc.

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).