ryan

You guys got me curious about PBCKCode, so I tried to install it here. Seems to work nicely. Not sure if this helps, but here's how I installed it. I downloaded the ZIP from here then extracted the contents to /site/modules/InputfieldCKEditor/ckeditor-4.1.2/plugins/pbckcode/. Then I went and edited my 'body' field and added a line for "pbckeditor" to the toolbar, and another for the "extra plugins". Then in "Extra Allowed Content", I added: "pre[class](*)". See the attached screenshot of my config screen for CKEditor. I opted not to keep the "data-pbcklang" attribute that it adds to the <pre> tag. Though I'm sure HTMLPurifier would strip that one out anyway. I figured that wasn't necessary since I already had a class tag identifying the language.

Actions that create, modify or delete an entry in the DB (like save) should be done via POST requests. I find urlSegments or GET variables handy for the rest. Here's a rough skeleton of how you could do it: function edit() { ... } function save() { ... } function delete() { ... } if($input->urlSegment1 == 'edit') edit(); else if($input->post->save) save(); else if($input->post->delete) delete(); else $session->redirect($page->url . 'edit');

From the README file (given this, I think your example would work): Using Hanna Code from the API If you want to populate Hanna Code from the API, you can do so using the render() method, like this: $hanna = $modules->get('TextformatterHannaCode'); $page->body = $hanna->render($page->body);

The problem was in /wire/core/Inputfield.php. Here is the patch I'm testing if you are interested. I even had a comment in there to myself about a potential problem (see the TODO). --- a/wire/core/Inputfield.php +++ b/wire/core/Inputfield.php @@ -418,11 +418,15 @@ abstract class Inputfield extends WireData implements Module { */ public function ___processInput(WireInputData $input) { - // if value was unset in the array, then just return - // TODO should this set an empty value rather than leaving an existing value? - if(!isset($input[$this->name])) return $this; + if(isset($input[$this->name])) { + $value = $input[$this->name]; + + } else if($this instanceof InputfieldHasArrayValue) { + $value = array(); + } else { + $value = $input[$this->name]; + } - $value = $input[$this->name];

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.