ryan

Great theme Nico! I really like where you are going with this, and the tree of pages in the sidebar is a nice feature for sure. This is a very innovative theme and nicely designed as with all of your work. I understand where Diogo is coming from in that it might be nice if nothing was cut off from the content column (i.e. it had a max-width: 100%; or something, so the fields would scale for the space). After playing with the theme for awhile, I think this is primarily an issue in this scenario: after clicking "edit" on a page, it opens the page to edit, then pops open the sidebar and page tree again, making it necessary to close those two sidebars before I can start editing. Unless I'm missing something, it appears one has to close the sidebars before every page edit (a lot of extra clicks). If it simply didn't open those two sidebars when I was going to edit a page, there might not be an issue with the way it truncates the main column. I like this theme a lot, so want to point out some very minor details of items that looked like they might still need styling: Appears to be extra indentation on the pagination links. Plus I was guessing the links aren't supposed to be underlined? Note the blue "more" link: Getting this notice on a log of pages: Unexpected indentation? Unexpected space before the change link? Unstyled button? Unexpected indentation? Some unexpected styling here Lastly, the "show actions on hover" in the page list was tricky to navigate in the admin, just because the narrow column always meant the actions fell to the nextline, making the pagelist jump all over the place on hover. I guess my personal preference would be to not have it show the actions on hover but on click instead (like the default admin theme), but this is just personal preference. I'm only nitpicking here because I really like what you've done, and would like to use it. Great work!

Thanks guys, and sorry about the bug there. The problem was actually not what was highlighted above, but this line: public function render($value) { $value = $this->formatValue(new NullPage(), new Field(), $value); // this line return $value; } ...is supposed to be this: public function render($value) { $this->formatValue(new NullPage(), new Field(), $value); // this line return $value; } The formatValue function accepts $value as reference, not a separate copy (i.e. &$value rather than $value). So the line that blanks out $this->value is intentional. The point of that is to clear the memory, ensuring the module doesn't keep a separate copy of the text, since it no longer is working with it. So if you commented that line, I would uncomment it again. Actually I'm updating the source to fix the issue now, so you can also just grab the latest version.

Please don't pay any attention to systemVersion. I was just trying to explain what it was for those interested, but it's not something anyone but core devs need to think about. The dev branch is not an official release and I want to be careful about anything that might present it that way. People don't even need to know about the dev branch unless they are interested in helping to test or develop ProcessWire, or (in this case) take advantage of the multi-language updates before they appear in PW 2.4. It's a branch that gets updated a few times a week, sometimes even daily or more. For a dev branch like this, the commit ID is the version, and the commit log is the README. Everything on dev is basically "being prepared" for an official release, so you wouldn't typically have separate README files for master vs. dev, etc., because dev is not a release, it's a branch working to eventually become a release. It's best to follow the commit log of the dev branch to see what's happening. It's also best to use the dev branch with Git (git checkout dev), and not by downloading a ZIP file. Typing "git status" will tell you what branch you are on (master or dev), and "git pull" will pull in the latest version instantly. I understand that Git can be confusing and a whole lot to figure out (I'm still learning it myself), but we are getting into the nature of how Git and software development work. The audience here is intended to be developers and testers, where Git is the standard. It's not supposed to be neatly packaged, versioned and ready for the consumer, and will always take more time investment on the part of anyone using it. We want users to have some experience with Git when using the dev branch because we are asking them to help test, report, and potentially fix issues through the GitHub system. I think part of the confusion here is just that we are getting very close to a 2.4 official version release and the dev branch is quite stable. So the distinction between official release and dev is probably more blurry than usual. Without thinking much about it, I've been casually telling people to use dev when it seems to make sense. But that will change as we hopefully release version 2.4 soon.

Thanks Adrian, good to see he's updating it, and thanks for bringing the issues to him. I'm unclear about how far along these updates are. Should I go ahead and update the CollagePlus plugin for the module now?

What you see on modules.processwire.com is part of a new Fieldtype module I've been developing on and off to support "like" buttons or star ratings by users. The implementation you see on the modules site enables anyone to anonymously "recommend" (like) a module, though the module itself does support limiting access to roles. When it comes to anonymous voting, the system prevents duplicates by both cookies and IP addresses, which isn't foolproof, but it's the best you can do short of having an authenticated user. It also requires Javascript and uses some cookie tricks, to keep the crawlers from voting. I put it up there a few days ago without mentioning it, and am surprised already at how much "recommending" has been going on, good to see. I'm also glad to hear there is interest in a module like this. I will keep working on it! It will also come with a Process module (under Setup) that lets you browse the liked pages in your admin For the star ratings part, I feel like this really is best kept to authenticated users (since one can also down-vote), so am looking into ways to limiting rating to those with PW user accounts and/or Twitter/Facebook/Linkedin accounts. I might ultimately just make the star ratings one a separate module, but still dwelling on it. Good idea, I will add this to the core.

Tony, thanks for making the diagram. I'm in the process of clearing out the Wiki since it's getting all kinds of unusual traffic and it's database has grown to multiple gigabytes (despite only having less than a megabyte of content). Basically, I'm concerned about the security of it, so am slowly moving the content over to the main site. Not to mention, I have no idea how to upload a file to this wiki. I will plan to include your diagram when this tutorial gets moved over to the main site.

PW doesn't currently have to option to convert an image from one type to another.

TinyMCE can be a bear sometimes. I don't know how to accomplish what you are trying to do, and most likely this is a question more for the TinyMCE forums than here. But the first thing I would try is to open the code editor, insert an , close the code editor, then open it again. Is the still there, or did TinyMCE get rid of it? This might point to whether you are dealing with a filter or not. Or, does the only disappear after saving the page?

That could be the case that "*" is just being considered a selector value, and is being filtered out. Though without following the path through the code, it's also that the selector engine sees an operator character with no field and no value, and thus excludes it from the equation.

Sounds good. I'll keep an eye out for this issue. Hopefully a live example will turn up at some point. In the mean time, I'll experiment and continue trying to reproduce it.

Soma is right that you'd need the latest dev version (2.3.2) to take advantage of these features and updates. When you replace the /wire/ directory, make sure you remove the old one first and then put in the new one. Trying to copy over the old one is problematic just because it can result in duplicate and/or extra files. PW doesn't create new tables when you change a field's type from Textarea to TextareaLanguage. Instead it modifies the schema of existing tables. So long as you have PDO, it should not matter. If your site works at all, then you have PDO. Check that your PHP version is newer than 5.3.8, that you replaced the /wire/ directory as mentioned above, and that you replaced your /index.php and /.htaccess file with the new versions (though that part may not be necessary).

Install MAMP and you'll be happy. I don't even bother experimenting with the AMP stuff that comes bundled with OS X.

I've never come across a client that didn't prefer a rich text editor to the alternatives. The reality is, they like RTEs because it's something they are already familiar with and it's easy for them to use. So I think a better goal is to give them what they want, but place limits upon it so that it can't produce a mess. Just because RTEs+clients can create a mess doesn't mean we have to let them do it. Both our TinyMCE and CKEditor rich text inputfields come very much restrained and prevent the client from creating a mess. CKEditor4 and it's ACF (advanced content filter) seem particularly adept at solving this problem. If you can convince a client to use an LML (Markdown, etc.) or some method of creating content in blocks, then that's fine. But once the next guy comes around showing them "look what you can do in my CMS–it's like using Word", you may be at a disadvantage. Other factors to consider: 1) content maintained by blocks may be significantly less portable through future CMS changes, web service/syndication feeds and such; 2) it may be more difficult to maintain site-wide consistency with the designer's original vision if a site's main content area is a mashup of content blocks. Personally, I would avoid trying to pursue a blocks strategy for most content editors, whether in a CMS that is built around the concept, or via trying to build everything around Hanna Codes. Instead, let the designer do their job and determine consistent and well thought placements for photo galleries, navigation, etc. I see Hanna Code as being better for the exceptions of needing something somewhere, and not something that editors should have to keep as part of their vocabulary.

Currently you can't show field labels rather than names in the template editor. This part is meant to be for the developer, who would typically know fields by their names rather than labels. Like in your template files, you'd refer to fields here by their names. Field labels are more for clients, language translation, etc. I would suggest using more descriptive names than float_field_1, float_field_2, etc., because there's no way to tell what that is, outside of the label. It could make the code in your site's template files difficult to maintain and navigate.

While not necessary here, you can of course also clone a page array (using the usual PHP method): $myClonedPageArray = clone $myPageArray;

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.