ryan

PW 2.3.2+ also includes a way to update modules from the admin, like ModulesManager. But the benefit of updating with ModulesManager is that it can tell you all the modules that have updates available, without you having to check them individually.

Unfortunately I can't listen to music when coding at all. I'm with dragan in that the only thing I can handle is ambient or classical stuff, and even that can be too much distraction. The only time I do it is if there is some other noise that is more distracting that I need to muffle out. I do like listening to music when working in Photoshop or doing some kind of data entry, content population, etc.

That usually means there is a PHP error getting shown, which is preventing jQuery from parsing the JSON returned by ProcessPageList. The best way to see the error is to go to your JS browser tools and click on the "network" tab, then examine the request–you should see an error message followed by some JSON.

That's an excellent suggestion. I'm honestly not yet sure how to implement it though. I've gone ahead and added a "data-language" attribute, with the language ID, to the LanguageSupport wrapper that goes around each multi-language field. The next step is to get the TinyMCE and CKEditor pwlink.js plugins to pull the language ID from the wrapper–this is the part I can't figure out yet. Once we've got that, the TinyMCE/CKEditor plugins can easily bundle it into the iframe/model request URL as a GET variable. Then the ProcessPageEditLink.module can detect and use it from there.

Okay it sounds like it must be part of TinyMCE's validation rules. In that case it's just a matter of finding what configuration directive needs to be supplied (or removed from) TinyMCE in order to change that behavior. I am guessing you will be able to find it in their documentation, but if you can't, you could always make a [[nbsp]] Hanna code too.

See this Comments Fieldtype documentation page sections on customizing output and styling output. While it makes it easier, you don't actually have to use the built in methods for rendering the comments list or form. You can create your own markup entirely if preferred. However, I do think it would be worthwhile to copy or extend ProcessWire's /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php file to your own class (MyCommentForm) in /site/templates/. When you want to render your form, you would do this: include("./MyCommentForm.php"); $form = new MyCommentForm($page, $page->comments); echo $form->render();

It's best that the directory name and filename don't change after it's installed. It should be uninstalled first, deleted, then re-installed, if such things change. I It looks like I've got a disconnect between the class name listed on the modules directory and the repository name at GitHub. The class name listed in the modules directory is what should be used for the directory name (TextformatterHannaCode). Though you certainly could install it under ProcessHannaCode too, but this would confuse the modules manager (including the built-in one). So I recommend using a folder name of TextformatterHannaCode for compatibility with the modules directory.

It works on the dev branch. That's assuming you are using the built-in language support modules (LanguageSupport, LanguageSupportFields, LanguageSupportPageNames). Though I am still working out a bug where the multi-language page names don't get copied over to the clone, so don't bother setting the non-default language page names until after the clone is made.

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.