ryan

Just wanted to mention that neither of these are necessary. The CKEditor module already handles both of these settings. The enterMode is already hard-coded for ENTER_P. And you can disable ACF (i.e. allowedContent=true) by unchecking the "Use ACF" box in the field settings, which applies this.

Yes, it does work with Fieldsets. The first version doesn't work with tabs (FieldsetTab) though. I think this seems like a good idea Pete. I'll look into how best to implement in the next version. The first version I need to get committed to the dev source tomorrow (30th), so not planning to expand the scope of it this week, but moving forward, would like to continue expanding the dependencies system everywhere it makes sense. And your ideas here do seem like they could be very useful, and may not be very difficult to implement. Something to keep in mind is that dependencies are assumed to be things that can change during the course of filling out the form (i.e. if this field is populated, then this field is available, etc.). So when we get into things like user roles, we're talking about things that don't change during the course of the form. So these would be an entirely different kind of dependency. These would be dependencies that would be applicable before the form is actually rendered. They wouldn't need to be considered by the javascript dependencies at all. As a result, it really might make more sense for this capability to be something separate, at least from the code perspective.

When $config->pagefileSecure is enabled, the images on unpublished an non-guest viewable pages are protected by the .htaccess file. However, if you are on the dev branch and using this option, you'll want to comment out these two lines from your .htaccess file. They are meant to be commented out by default, but looks like they aren't currently on the dev branch. Only use the $config->pagefileSecure option if it is worthwhile to your site, because it is a little slower to serve images/files this way.

Asking for a page by ID is really specific, so it's not going to make you jump through more hoops than that to get at what you want there. If you know a page well enough to know the actual ID of it ahead of time, then it's not really a search/find at all. Regardless of whether you use get(123) or get("id=123"), ProcessWire can bypass the entire PageFinder engine (and any overhead associated with it).

The import data must have been entity encoded before import. It would probably be a good idea to de-entity encode it, so that it can be used in a rich text editor. You'd want to run it through something like this, once: foreach($pages->find("selector to find your imported pages") as $item) { $item->of(false); $item->body = html_entity_decode($item->body, ENT_QUOTES, 'UTF-8'); $item->save(); }

Horst, this sounds like a good way to go. As the resident image expert–what would you suggest is a good maximum for us to start with in a /site/config.php setting? I'm thinking we probably have to set something that would be compatible with a PHP 32M memory_limit setting. Though not positive we can really identify an exact number without trial and error. I was thinking of starting with 15,000,000 pixels (5000x3000), though even that may be too large.

It's important for there to be a hard limit on page numbers just from a caching perspective. You don't want to have anything in your site that can generate an unlimited number of cache files and fill up the hard drive. But that doesn't mean the limit has to be 999, just that 999 is what I perceived to be the upper limit of what would ever be even remotely practical to support in pagination. I'm fine with making this configurable though, but hope you guys use it to configure the number down rather than up.

Thanks Soma, I was able to reproduce it here too. Can you try out the fix I posted to the dev branch? You'll have to undo the page move you did before, and move it back again in order to get it to rebuild its index.

GomatoX, thanks for your module. Can you describe what language constants are and how users would utilize them? What would be the benefits over using the existing translation system or multilanguage page fields? I'm on mobile, but when I get to my computer I'll try it out and probably find the answer myself, but wanted to pose the question for the benefit of other users that may be interested.

Probably what is needed is a hook into the PageFinder class, rather than into the selector parser. If a value is wrapped in {brackets} like you mentioned above, a custom hook could be called. PageFinder is admittedly one of the more complex parts of PW, so I don't necessarily see any solution as being particularly simple to implement. But here is the function that deals with sort values in PageFinder if you are interested. I could add a condition in that function that calls a hook like PageFinder::handleCustomSortValue when it finds the value wrapped in brackets.

I'm assuming that the directory replaces those pages, as they seem to now be redundant (though Mike is the only one that can answer for sure). But if they are capturing some search traffic that the directory isn't, or need to stick around for one reason or another, I'll request a listing for ProcessWire there.

It's hard to say without actually looking at it. But if one of the solutions mentioned above solves it, I think all the mentioned solutions here seem perfectly safe.

Using field labels on the front-end of your site isn't a very common usage, so they aren't automatically adjusted by language the way page fields are. But you can still get the language-specific field label pretty easily, like this: $language = $user->language; $fieldLabel = $field->get("label$language");

I'm wondering if your code that does the login might have overwritten the $user API variable provided to the template file? If so, you might want to change your use of $user to $u or some other name. Either that, or you could use wire('user')->isLoggedin() rather than $user->isLoggedin().

Antti's right that it does sound like something going on at the server side (mod_security?). But I don't think there's any reason to use 2.2.9 anymore, so if it's as simple as using PW 2.3.0, why not just do that? However, don't be surprised if the issue turns up again, as mod_security can be a real pest when used with a CMS.

I also replied to this in another thread this morning, not realizing Soma had already answered.

Chances are that the CSV file is not UTF-8? If you can confirm that it is in fact UTF-8, no-BOM, PM me a copy of the CSV file and I can give it a try here to isolate the issue.

I still can't duplicate the issue here. Let me know if you guys can think of any other factors that would enable me to duplicate it. Also, double check that your InputfieldCKEditor directory was replaced in full (rather than replaced into) when upgrading the editor. I noticed this too, though didn't realize why it was doing that (thanks for figuring it out). Maybe I should leave CodeMirror out of the installation, as it sounds like the current version is missing some things. Though I'll try updating the assets that you mentioned, but these types of errors make me wonder if there might be other problems with the current version of CodeMirror.

Why not? The way I would solve this is to create pages for shared assets, probably with a one-one relationship between pages and images. Something like /shared/images/... Give each of the shared image pages a title and an image. Then use a page reference field, perhaps with an asmSelect (multiple selection) to select the header images you want shown on each of your pages. In situations where I have image selection like this, I also like to provide a default/random selection in cases where nothing is selected (or too few are selected). So I might do something like this: $limit = 3; // number of images required $imagePages = $page->header_image_pages; // page reference field $n = $limit - count($imagePages); // n=number of images we need to get if($n > 0) { // not enough images selected $imagePages->add($pages->find("parent=/shared/images/, sort=random, id!=$imagePages, limit=$n")); } else if($n < 0) { // too many images selected $imagePages = $imagePages->slice(0, $limit); } // output the images foreach($imagePage as $imagePage) { $image = $imagePage->image; echo "<img src='$image->url' alt='$imagePage->title' />"; }

The client doesn't even want a CMS (and presumably isn't paying for it) yet you choose to built it out in ProcessWire for convenience. I like that. I would do the same thing, but it makes me smile to hear that others are using ProcessWire even when the project doesn't call for a CMS, simply because it's more convenient than building it without.

Soma's solution will work for typical inputfield forms, but fieldgroups are actually stored in a flat manner rather than a tree. So you'd have to iterate them to find all fields in a fieldset (unless I'm forgetting something, as I don't need to do this very often). $children = array(); $record = false; $name = 'your_fieldset_name'; foreach($template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen && $field->name == $name) $record = true; if(!$record) continue; if($field->type instanceof FieldtypeFieldsetClose) break; $children[] = $field; }

When you specify PHP as the type, then the Hanna code is a block of PHP. But you should be able to specify a closing PHP tag like ?> and then be in your HTML. If that does not work, start your Hanna code with: <?php ?>, which should prevent Hanna code from automatically inserting an opening PHP tag, and leave you in HTML.

I don't think the voting opens till September, but you can still click "like" for ProcessWire, if you want to. That "like" system is the same one we use in the modules directory, and something I plan to release as a module soon.

That's correct, that would require shell access. Anyone know if symlinks can be created via FTP? I'm guessing not, but haven't researched it.

Adrian, regarding 'name': I like your solution in post #7. I've added it to my code and will test locally and commit it soon if all works well. Regarding the 'title': There is no 255 limit for 'title'. Like WillyC mentioned, the only limits to title are those that you introduce in the field settings. If your title is getting truncated at 255 chars, then it's likely configured for a max length of 255 chars. The default max length setting for title is 2048, but this can be increased or decreased as desired in the field settings.