ryan

PHP definitely can't write to /vagrant/rhythm-site/site/assets/sessions/, as that's essentially what the error message says. With no file or line number, it appears the error must be coming internally from PHP. Maybe there is something about your PHP configuration that doesn't allow overriding of the session save path? You could try removing this line from /index.php: if(ini_get('session.save_handler') == 'files') ini_set("session.save_path", rtrim($config->paths->sessions, '/'));

Sounds great. I have updated the version to CollagePlus 0.3.1 and pushed the update to the module. All seems to be working nicely from here, a nice improvement–thanks.

Thanks Adrian, this looks like a good solution. Where exactly did you put it? I'm not clear about the full context of where it goes. The title field should never be truncated. But the name field has a maximum length of 128 characters.

This is not necessary. Admittedly, I don't know these jQuery plugins well enough to know why they aren't working in your case, but it does sound like you've got everything needed to have it work from the admin side. Meaning, it sounds like you need to focus on the front-end and the instructions for the code highlighting plugins you are using. I would also suggest opening up a Javascript console window, just to make sure there aren't any pesky JS errors holding everything up. When I view the page you linked to, I am seeing a couple Javascript errors, which could very likely be the reason why the code highlighting scripts aren't working. None of the JS errors appears to be related to the code highlighting, but they could certainly interfere with it:

Is this still the case even in the dev branch (2.3.2)? So far I can't duplicate. If you only tested this in 2.3.0, don't worry about trying it again as I'm pretty sure we fixed this one already in dev.

Technically everything can already be hooked into, return values modified, or methods replaced, the most likely candidates being Inputfield::render() and Inputfield::processInput(). But admittedly I can't think of an occasion where I'd need to do that. Fieldtypes are defining data that goes into the database and needs a schema, while Inputfields are handling that input at the UI level. An "anything goes" type Inputfield where you override the render() and/or processInput() with hooks would likely only be useful for situations where you want to substitute the way the input is performed at the UI level... but that's the purpose of Inputfields in the first place, so the question would be: why not just make an Inputfield? Perhaps there are some cases, like if you wanted to replace all <select> fields with a jQuery driven Chosen field or something. As for simplifying the approach, it's actually really very simple and a lot more so than what I think most people realize. But when people are making their own Fieldtype/Inputfields it's usually because they are trying to meet some data storage or input need that is not fundamentally simple in any system. In my opinion it's simpler and more reliable to handle such a need using the pattern made for it (i.e. custom Fieldtypes and/or Inputfields), rather than to selectively override things.

If I understand what you are trying to do correctly, you've got several options: Repeaters Pages / page structure Custom Fieldtype/Inputfield Formatted text What direction you go depends on how much time you want to put into it, how much it needs to scale and who will be doing the content population.

Oops. Just fixed. Thanks.

I've posted an update to Hanna Code to address some of the things brought up earlier: It now comes with a proper code editor (Ace Editor). You can configure the theme and editor height in the ProcessHannaCode module settings. There is now a "Save & Test" option. When you click that, it will save then attempt to run the Hanna code. This is primarily useful for determining if you have any PHP parse errors or the like. The default behavior of "Save" is now to continue editing, rather than going back to the list of Hanna codes. There is now a separate "Save & Exit" button to do that. The interface now uses tabs.

Actually you could do this by hooking $hanna->render() into Page::render. But I don't recommend it because then you always have to filter for Hanna Codes in any user input that gets echoed back to the screen. Basically, it just opens up security issues that would be potentially difficult for someone to keep track of. It's a lot safer to be specific and just render Hanna Codes in the blocks of content you intend. The problem I can see with your Hanna Code is that it's echoing $page->body. Your Hanna Code should only echo what actually replaces the tag. Maybe that's what you want when you do a call like $hanna->render("[[newdetails]]"); but that's definitely not what you want to be textformatting your $page->body field -- seems like that could potentially result in an infinite loop.

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;