ryan

Maybe I've forgotten something, but I don't know why that works. I don't think we have any code specifically looking for a wildcard like that. Chances are its getting filtered out to nothing, but getting far enough in the Selector engine to let the query proceed... kind of like an id>0 selector.

I think it really depends on the file system and version of it. If I recall correctly, many servers have no practical limit nowadays. It sounds like it used to be a bigger consideration than it is now. But it's one of those things that I'm not sure is worth the effort of "solving" until we have an instance of it being a problem. So far, nobody has ever run into any issues as a result of this, and we certainly have many installations with more than 30k pages. Though I don't know of any installations yet with 30k pages that each contain file assets, so always keeping an eye open to it.

Definitely looks like it has some funny moments, if a bit over the top. This reminds me of the Borat movie with the real situations that people don't realize are staged, awkward moments, resulting hilarity, etc.

In your sitemap-xml.php file, add this line at the bottom: $useMain = false;

Makes sense to me, though not sure my JS skills are good enough to figure it out just yet. It would probably have to happen in InputfieldPageTitle.js

It sounds like something is wiping out the $user->language variable. Do you have any code that is setting $user->language in your site? Are there any other 3rd party modules installed that have to do with multi-language? If not, try replacing your /wire/modules/LanguageSupport/LanguageSupportPageNames.module file with the one attached--please let me know what you find? LanguageSupportPageNames.module

We were watching this show tonight called Rick Steeves Europe, where this guy goes around and visits many of the countries in Europe. On tonight's show he was visiting Spain. My wife loved it because she used to live there (for a short while anyway), and I thought it looked amazing. He said that Americans have the fewest vacation days of most in the world and that we need to take more. I was thinking about it, and realized that I didn't start having vacations until we had our first baby (Hanna), which was about 10 years after getting married... since Hanna arrived (and now Karena), we try to take two vacations a year, 2-7 days. I just got back from from a 3 day vacation here (great time). Though I wish we were vacationing in Europe, but that's a much bigger investment in time and money. But it got me thinking... many of you guys are in Europe–what kind of vacations do you take? How long, and where do you go? Also, if you were (or have been) in the US for the last 35+ years, where would you go on vacation?

Sounds like it's a mystery. When you've got the code at a point where I can play with it, let me know and I'll try to debug it here. Or if you've got a skeleton of it that reproduces the issue, that's just as good.

All of the message() and error() calls end up in an API variable called $notices. You could hook after Page::render and do something like this: $mylog = new FileLog(wire('config')->paths->logs, "mylog"); foreach(wire('notices') as $notice) { $text = $notice instanceof NoticeError ? "Error" : "Message"; $mylog->save("$text: $notice->text"); }

This looks awesome, loved watching the video. Just let me know if there's anything I can do to support further development of this.

While I've not had to do it before, I think you can approximate a limit=1 (for pagination purposes) just by specifying a "start" value based on the page number: $item = $pages->find("limit=2, start=" . ($input->pageNum-1))->first(); The resulting $item would be the one you'd output on this pagination.

I think this had something to do with FieldtypeConcat? Just reviewing the PM threads with Valan, I think that's how we solved it. Grab the latest version of FieldtypeConcat (I'm assuming you are using it?). Let me know if that's not it.

Thanks, I understand now. I've updated the InputfieldCKEditor to populate the config.height property based on the rows value.

Lets say you've got a structure like this: /posts/ /some-post/ /another-post/ ...and so on... /categories/ /plants/ /fish/ /birds/ Create a field called "categories" (or whatever you want to call it). On the "details" tab, make sure it says "Multiple pages - PageArray" for the type, which I think is the default. On the "input" tab, set the parent to be /categories/. Also on the "input" tab, choose "asmSelect" as the input field type (or if you prefer something other than asmSelect: checkboxes, select multiple or autocomplete). Add your "categories" field to your "post" template. Save. Now edit one of your pages below /posts/ and you should be able to select multiple categories. To output those categories on the front-end, you'd do this: <h3>Categories</h3> <ul><?php foreach($page->categories as $c) { echo "<li><a href='$c->url'>$c->title</a></li>"; } ?></ul>

Make sure that the form (InputfieldForm) knows that you are using GET: $form->attr('method', 'get'); That should be enough to disable CSRF protection for that form. If you had a POST form that you didn't want CSRF protection on, you could do it like this: $form->protectCSRF = false; InputfieldForm doesn't even attempt CSRF protection for method=GET forms, so not necessary to do that if the method is already set to get.

I was able to duplicate it too. Looks like it's a core issue when dealing with multi-value Fieldtypes that only have an array value (rather than an object value). These two modules (FieldtypeModules and FieldtypeTemplates) I think are the only two that would be affected. I've implemented a fix in the dev branch and will be testing it for a bit before committing.

I would really like to see MODX do well. They have a very similar audience to ours and I think what's good for MODX is also good for ProcessWire. Because there seem to be many people here that are fans of both MODX and ProcessWire, I would gather that the more their audience grows, the more ours does too.

Most of the tutorials I've read, I've not been able to really understand how they work and end up getting lost trying to get through them. I don't think it's the fault of the tutorial–I've never been able to learn from tutorials of any sort. I learn by reading the docs and then tinkering with a working example... that's the only thing that seems to work for me. But I recognize that people learn in different ways, and many like tutorials. But I can't vouch for any tutorials I've not personally written. If anyone finds that any of the tutorials have errors or something that doesn't work, let me know what to fix. In your case, it sounds like you are now simply trying to manage categories. You don't need a repeater for this unless you need to define other fields together with the category. Chances are you would be better off not using a repeater and instead just using a Page reference field (perhaps with the asmSelect input). I'm also wondering about the naming, with items having "_01" at the end. That seems to imply that there might be a "_02" and a "_03", etc. This would be pretty unusual for field naming. Chances are you instead want a single "categories" multi-page reference field (which is the default behavior of the "Page" reference field).

I've been using CKEditor almost exclusively for the last couple of months, but haven't ever run into this. Maybe that's because I'm always using inline mode, which automatically sizes the height of the editor to the text within it. But I think the same thing may be possible even in regular mode (I can find out). Just want to make sure I understand how to reproduce the issue. Does this only occur in regular mode?

I think you might be using some version of ProcessWire older than 2.3.2 (dev), because the line numbers indicated in your error message don't line up with the line numbers in the dev source. I would replace your /wire/ directory with the one from the dev branch (ProcessWire 2.3.2) and try again. I don't recommend using LanguageSupportPageNames from 2.3.0 just because 2.3.2 is so much farther along in that regard.

That's correct, it's just an optimization to prevent loading resources that won't be applicable for the request. When ProcessPageEdit performs a save, it doesn't generate any output–it finishes by redirecting back to itself, so there's no need to load things like tabs.

The PagefilesManager::url() method is now hookable on dev. For high volume functions like this, I go a little further than just prepending 3 underscores and instead implement both a hooked and non-hooked version, just to reduce any potential overhead. Meaning, PW's hook system doesn't get called upon unless/until the function is hooked. Not sure it really matters, but it's just a minor optimization.

Dragan, it sounds like you are attempting to use LanguageSupportPageNames in combination with another multi-language solution (appending language segments to URLs). These cannot be used together. You either need to use the solution you started with, or abandon it and switch to LanguageSupportPageNames. If you are going to use the multi-language solution you started with, which was to append language segments to the end of the URLs, then you should definitely uninstall LanguageSupportPageNames. Or, if you are willing to remove all of your code that has to do with getting/setting $user->language, or modifying URLs, in your template files, then you can use LanguageSupportPageNames. The important thing to keep in mind is that LanguageSupportPageNames does all the work for you, so you do not need or want to have any code for dealing with languages in your template files (unless making something like a language switcher).

That error seems to indicate that the system has language support installed (i.e. there is an $languages API variable), but the user's language is not set. That's unusual for it not to be set, so I would check in your code to make sure you aren't manually setting $user->language to an invalid value somewhere.

I ran my tests attaching them statically too, but it doesn't make a difference. I will try bundling them into a module (rather than anonymous functions from a template file) to see if it makes any difference. But two suggestions I have here are: 1) attach your hooks in an init() method, rather than _construct(). ProcessWire may still be booting when your _construct() is called. Though in this case, I doubt it makes any difference, but I would try that just in case. init() or ready() is typically where hooks are attached (initializing connections with external things), whereas _construct() is for initializing internal things. init() is called before the current $page is known, and ready() is called after it is known and available as an API variable. In your case, init() is the right one to use (though ready() could also be used). 2) after moving them to an init() method, switch to using non-static -- attach directly to $this->fields and $this->templates (the API variables). Static hook attachments are only necessary for objects that might have more than one instance, like Page, User, Field, Template, etc. But there will never be more than one instance of Fields or Templates, so you can benefit from slightly less overhead by attaching them directly to the API variables.