ryan

If your $this->[api variable] isn't working, chances are you've overridden WireData's $this->get() or $this->__get() -- is that the case? If so, using wire('api variable'); is a fine way to go, though you may still want to fix the API variable access in whatever get() method is overridden, just to be safe. Another possibility is that you have a line that says $this->useFuel=false; That tells ProcessWire to cancel access to API variables via $this. As for why your hooks aren't being called, that's a mystery as I don't see an obvious problem with the code you posted. Though I would suggest hooking Pages::saved and Pages::deleted rather than Pages::save and Pages::delete. Add a line in your hook function like $this->message("hello!"); so that you can see in your admin that the hook was called. ProcessWire performs a redirect after page saves, which can make it easy to conclude that something isn't happening when it actually is. When you use $this->message("hello"); that gets queued between requests, which makes it useful for this kind of debugging.

I'm not sure I've got enough info to go on to fix this one. Can you describe more about how you fixed it with your workaround? Or if anyone has a live example of this issue and doesn't mind giving me access to it, I can troubleshoot it that way too.

systemVersion is just an internal thing so that PW knows when it needs to apply something like modifying the schema of the database. Most ProcessWire versions don't involve changes to DB schema, so I wanted to have a separate way to track that. It's automated behind the scenes, and the systemVersion isn't useful for much else. If you ever see ProcessWire give you a message in the admin to the effect of "Applied system update #3", then it means it just made some adjustment in the system (likely to the database) and incremented the system version.

The company behind WordPress is a very big supporter of open source and seems to be in it for the right reasons. I'm glad to have them powering a good chunk of the web rather than some product from Microsoft or Apple. I think WordPress has also paved a road for almost all other open source CMS products by building an audience that wasn't there before. WordPress (as a product) is fairly limited in what it really should be used for, but people push it as far as they can. Then if the need arises, they learn about and switch to other products that can do it better (like ProcessWire). WordPress market share seems to be good for the whole ecosystem (other than the persistent security issues). It's also opened many people to the idea of using open source rather than proprietary solutions... Microsoft and Apple (and so on) don't even want to touch the market because there is no money to be made in competing. So long as WordPress stays true to the original vision of being an entry level publishing tool, I think they will keep growing as a positive force. Shifting gears, but there was a question above about why there isn't a built-in tagging system in ProcessWire. You have to go beyond the term "tag" and consider what a tagging system actually is and what it does. It's a concept of relating one thing to other things. The reason ProcessWire doesn't have a tagging system is because it is a tagging system. Most know it as the Page field type in ProcessWire, which is one of the most important and fundamental types in ProcessWire. While the answer on how to use it as a literal tagging system can be found by looking in the admin side of the blog profile, I will write up some quick step-by-step instructions when I get the chance. But the primary difference between a tagging system and any other type of page reference is primarily just terminology, i.e. "tags" rather than "categories", etc.

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.