ryan

Sounds like you have pretty unique needs here, and I understand now – your approach does make sense given the context. I think Kongondo's ideas are good here, and I will keep thinking about how we might support separate labels in the asmSelect list there for the future.

You can just do: if($field->type == 'FieldtypeText'. But it looks like you are intending to operate on the 'title' field? In that case, I think what you really want is FieldtypePageTitle. The "+" won't concatenate strings in PHP. You want to use "." instead. With regard to everything else, it looks like you are on the right track. However, it might make more sense for you to just implement a Textformatter module instead, as this is exactly what they are designed for: /site/modules/TextformatterOzwim.module class TextformatterOwzim extends Textformatter { public static function getModuleInfo() { return array('title'=>'Ozwim','version'=>1,'summary'=>'Ozwim summary'); } public function formatValue($page, $field, &$value) { $value .= "- modified page title FTW"; } } Once you've got that, install it and select it as the Textformatter for your page title field (or whatever field you want to apply it to).

I figured it out. Since PageRender::renderPage is providing the rendered output in $event->return; rather than the function returning it (since it is actually a hook to a non-existent Page::render), then you have to do the same. As a result, this code in your before hook function should work: $otherEvent = $event->arguments(0); // grab event provided to PageRender::renderPage $otherEvent->return = "<p>Hello World</p>"; // plug in our value $event->replace = true; // prevent PageRender::renderPage from being called

In your case, if your before hook replaces PageRender::renderPage, you should be able to just echo your output directly. You don't need to exit or stop execution. Meanwhile, I will look into making $event->return; work for before hooks with $event->replace = true;

This Page::render is kind of a special case, because there isn't actually a Page::render() method if you look in the Page class. It is itself a hook added by the PageRender.module. So you can't replace it since the method doesn't actually exist. Instead, you'd have to hook the source of that Page::render hook, which is actually: PageRender::renderPage.

That may be a good idea, but this module probably isn't the right one for it. I'm using some techniques with it that wouldn't seem to be applicable to situations other than this module. The FieldtypeMapMarker (which also includes its own Inputfield) is one I originally made as a tutorial on how to make your own Fieldtypes/Inputfields. I still think it's one of the best examples, though there may be others that are equally good or better now. But without knowing of one, I'd still suggest the MapMarker Fieldtype as a good example.

In my experience, clients understand and accept very well when you tell them that you created some constrains on purpose. The important is that they look at their website and their friend's website and see why theirs looks much better. I'm not implying that we should be offering all the control of Word to the client. I totally agree with using and communicating the constraints. Our RTE's are very constrained in their default configuration, relative to most other CMSs using RTEs, and that's of course intentional. I've spent a lot of my development career being opposed to web-based RTEs. But over time have come around to feeling that a constrained RTE is about the ideal situation… clients have a high level of comfort with it, as a result of it having similarities to desktop RTEs (Word, etc.). I've now had clients using TinyMCE for years (and now CKEditor) and I like the fact that it reduces the support burden a lot. A well constrained, quality RTE is going to make it very difficult for a client to break things. I'm especially a fan of CKEditor 4 paired with HTMLPurifier, for this reason. In the past, I've tried to get clients to rally behind Markdown. Dictator CMS (which had no RTE) was built around it, for example. I like Markdown, but it unfortunately takes a special client to adopt and like Markdown, and a lot of extra support burden for me. HTML is allowed in Markdown as part of the standard, and this is inevitably what clients resort to when they can't figure something out... which creates a new and perhaps worse kind of mess. GitHub-flavored Markdown seems to be a improvement in this respect. I'm sure there are both benefits and drawbacks to the blocks approach that's been mentioned, a compromise, like anything else. A CMS built around that is conceptually distant from ProcessWire, as we aim to keep layout concerns and markup generation out of the content management. In our environment, there is a clear separation between where and how things are output, versus management of content that is contained. Though for those cases where people do find the concept beneficial, ProcessWire also aims to be flexible, more than anything.

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?