ryan

Nico, sorry about that. Can you tell me the module title and class name, exactly as entered? [edit] so far tried lots of things, but can't duplicate a 404. I have a feeling it's tied to class name or title, but can't tell for sure. Let me know how to duplicate when you get a chance.

I was supposed to have jury duty today, and they didn't need me. Since I'd already rescheduled today's client work, I decided it was a good time to finally get a start on the PW modules directory. Here it is: http://modules.processwire.com I just added that DNS host so may not be active everywhere yet. There are only a few of my own modules and a couple admin themes in there at present. I need your help populating it (see below). This is just a start, and I've only had a day to work on it. I've got plenty more planned for it and appreciate any feedback you have. How to add your modules For those that have created modules, admin themes or language packs, I need your help populating the directory. When you get to the directory, you can click "Add New Module" in the sidebar and it will take you to a screen where you can add it. You assign an email and password with each module you add so that you can return to make updates as often as you'd like. When you add a module, it puts it in a pending state just so that I can keep out the spam. It emails me when you add a new one, so I'll approve any modules you add asap. Though you view your own module page and continue to make as many edits as you want to regardless of whether it's approved. Nikola and Soma: I put in one each of your admin themes for testing purposes. I've associated these with your email accounts. To modify your admin theme pages in the modules directory, click "edit" on it and scroll to the bottom in "Authentication" and click the link to retrieve your password. Enter your email address and it'll send it to you.

We already have Markdown and Textile text formatters, so I thought we should have BBCode too. BBCode is a good text formatter to use when you'll be outputting untrusted user-supplied input. I think it's also a little simpler and more widely understood than Markdown and Textile, since it is used by many forums (including the ProcessWire forum, before we switched to IP.Board). More about the BBCode format can be found here: http://en.wikipedia.org/wiki/BBCode This module uses the NBBC Library to handle BBCode parsing. I selected this one because it seems to be really well documented and also includes it's own set of smileys, for those that like that sort of thing. To install, clone it from the TextformatterBBCode GitHub page or download the ZIP file.

You don't necessarily need to create a separate Process module if you don't want to. Though there's nothing wrong with doing it that way, and it may make sense for a separation of powers deal. If you take that approach, your render() function can simply return the content to be output and ProcessWire will take care of the output for you (it outputs only your returned output, without any template output, when the request is ajax). But there are other ways of handling it within your existing module. 1. If you are retrieving pages, ProcessWire already has an Ajax-API built in for you to use. This is what the Autocomplete inputfield uses, for example. It'll let you query and retrieve just about anything that you could from a native PW API call. See here for more info. This at least answers 90% of the AJAX needs I have in ProcessWire. 2. If either your Fieldtype or Inputfield is autoload, you can have it listen for your ajax request in the module's init(): public function init() { // look for ajax request and some variable you've set as your landmark to look for if($this->config->ajax && $this->input->post->rob == 'rob' && !$this->user->isGuest()) { // do your thing, outputting your JSON/XML or whatever exit(); } } In the above scenario, you could ping literally any page and so long as the request came from ajax and $_POST['rob'] == 'rob', your bit of code would get executed. You might also be able to get away with doing this in your $inputfield->init() (non-autoload) function, which would prevent you from having to check for access, and would ensure the execution is limited to when your module comes into play. However, I haven't tried that to confirm.

I'm always willing to take a fresh look at tools other people like. There was no VIM mode back when I used PhpStorm, so that sounds interesting from that aspect (as does the sublime vintage mode). But should qualify that I'm not naive about this, have spent a lot of time in IDEs, and used dozens of different editing environments over the years. Back when I was a C++ programmer working for another company, I didn't have a choice. I also used PhpStorm for a couple weeks when it was new (with ProcessWire), as well as Zend's IDE for some time. I even grew up in Turbo Pascal and Borland C++ IDEs, using them for years. But my mind always ends up more in the editor than in the code. For me, less has always been more. It's not about what's practical, easy or fast. VIM takes me to a place where I can think, and it took me years to find it. I lose creativity and enjoyment when you take away the minimalism. Coding becomes about work rather than code. I lose track of stuff when something is keeping track of it for me. What can I say, this is how I am about all my tools except maybe Photoshop. No doubt IDEs can be time savers when it comes to certain tasks, but I've not found it worth the tradeoff. (Though TextWrangler is my go-to for anything involving regex search/replaces across mass amounts of files). I will keep trying out tools that other people like and recommend, but I think most of the time we're looking for different things. I'm not trying to sway anyone towards using what I use. It's not practical, and it's slightly insane. In fact, I would say you should avoid the likes of VIM if you enjoy using an IDE. This is all beside the point on PSR-0 changes to the core. I can put up with more files, as the inconvenience is relatively minor. But I thought it was worth asking if there were any compliant conventions for including a similarly-named group of classes in one file. For instance, a file named Selector_.php might include classes beginning with the word "Selector", which are already grouped together in a file by intention and design.

I thought I fixed this one last week, but turns out I got the /markup-cache/ URL and not the /markupcache/ one. Not sure how I ended up with both, got to be user error on my part. Anyway both should work now. Thanks for finding it.

Mediaelement looks pretty cool, I actually have a use for this on another project and am glad to find out about it. I need to take a closer look to determine if this is something that fits the URL-to-embed code purpose of the module without stepping over the line on front-end dev. But it certainly fits with the name and purpose of the module. Modal popups are a good idea, but things that might be better in one's front-end development rather than in a text formatting module, given that they are more site/need specific and involve linking to local javascript files and such. These common YouTube/Vimeo video embeds are pretty much universal to the point where one almost expects one of their URLs to convert to a player, so that's what the purpose is here. And that's the most likely way this module would grow (adding more services). Still, this module may be a good starting point for branching in less universal, more site specific needs, and I'd encourage extending it like that.

Great and useful module Pete! One recommendation I have is that this module probably shouldn't be autoload. That's something reserved for modules that need to attach hooks and execute on every request. In this case (if I understand it correctly), the Minify module only needs to execute when you are configuring it. So this module will be more efficient if it is not loaded on every request. This 'autoload' is defined in your getModuleInfo() function and you can either remove the line or set it to false, to make this adjustment.

This sounds great Evan, I can't wait to check this one out. To answer your question about how to pass arguments to a hook function: $myPages->toJSON($a, $b, $c); public function toJSON(HookEvent $event) { $a = $event->arguments[0]; $b = $event->arguments[1]; $c = $event->arguments[2]; } Since you want to pass in an options array as the first argument, you would call your function like in your example, and you could retrieve the argument like this: $options = $event->arguments[0];

Thanks Marty, I was wondering about https URLs, but hadn't yet seen any so figured they didn't use them. I have just updated the module to support them, so they should work now (vimeo or youtube).

I'm not seeing the double links, but there is one unrelated issue I've been running into every day and might as well mention it because it's easy to show. It's a problem with indentation in any code listing. Check out the following example: Each line is indented with the indicated number of spaces. Notice how IP.Board messes this up, causing endless problems formatting code examples: 0 spaces 1 space 2 spaces 3 spaces 4 spaces 5 spaces 6 spaces 7 spaces 8 spaces 9 spaces Here's a screenshot of how it was entered: No love for tabs in code examples either. But they are lost when pasted into this editor, as opposed to after submitting the message: 0 tabs 1 tab 2 tabs 3 tabs 4 tabs Since code examples are such a big part of what we do here, I was wondering if IP.Board has any settings or plugin modules that would make it more code friendly? Thanks, Ryan

While it may be okay to do once in awhile, I would avoid structuring your site in a way that requires uploading the same image in multiple places. Instead, pull from the source page via the API and use the image. An example of this would be a site structure like this: /about/ /contact/ /press/ /history/ Lets say that you want all these pages to have the same header image. Rather than populating a header_image field on each page with the same image, populate it on just your /about/ page and let the others pull from it. Even if all the pages use the same template file, you can achieve it with this: $image = $page->header_image; if(!$image) $image = $page->rootParent->header_image; if($image) echo "<img src='{$image->url}'>"; The approach here is to give each page the ability to define it's header image, but make it optional. When it's not populated, it grabs the default from the root parent page (/about/). But lets say your structure is a little deeper than that: /about/ /contact/ /directions/ /press/ /history/ In that case, you may want to have it inherit the header image from the nearest parent that has it defined. So /about/contact/directions/ would show the header image from /about/contact/ (if it had one) rather than the one from /about/: $parent = $page; do { $image = $parent->header_image; $parent = $parent->parent; } while(!$image && $parent->id); if($image) echo "<img src='{$image->url}'>"; There may be other cases outside of the example above where you might have the need of using an image defined on another specific page. In that case, use a page reference field. You might call it header_image_page. It would essentially say "I want to display the header image from that page". This is a little better than a direct file reference because your image will still work even if the source page changes it. $image = $page->header_image_page->header_image; if($image) echo "<img src='{$image->url}'>";

Thanks for your work here. Just took a look and if I understand correctly, the scope of it is just to give each class and interface it's own file, named identically to the class. Also because Data.php becomes WireData.php, Array.php becomes WireArray.php, etc., that portion of the autoloader is no longer necessary as well. Let me know if I'm on the right track? I am going to have to start creating fewer classes in my workflow. One [short term] concern: The scope of doing this same thing may be a lot greater in /wire/modules/, perhaps more than would be a good idea in the short term. Though I could be wrong, haven't not looked too closely yet. But I just wanted to make sure that it was worthwhile to do part of it now (/wire/core/) even if we can't do the whole thing in the short term? Or would it be better to pen the whole thing at once to a version (2.3, 2.4, etc.)? I also have a couple classes with major work-in-progress in /core/ that I probably need to wrap up before I introduce new files and change filenames. Do you know if there are any exceptions or alternatives to the 1-file per class with this PSR-0 compliance? I'm just thinking of the dozen or so Selector* classes, and others, as some of this could be difficult to manage in my editing environment (VIM). I think it's worthwhile even if we have to increase the quantity of files in the system somewhat, and it's not often I have to go back and edit these classes… but just wanted to check, as the PSR-0 compliance does appear to introduce new challenges, at least in my editing environment. But it all seems worthwhile regardless.

Michael, that looks interesting. Looks like a lot of cool possibilities there and I look forward to taking a closer look and seeing if there might be another module brewing in there. But I have to admit that I find the whole oEmbed thing a bit vulnerable, as it's letting another web site populate raw markup into your site. You must have a lot of trust in whoever you let do that. It's more sensitive than linking to another service's JS. I have that level of trust with YouTube and Vimeo. I suppose I need to convince myself that something like embed.ly doesn't seem like a potential security timebomb, because the potential is very cool. I'm going to spend some more time looking at it.

There is now a module for this:

I'm actually using a 1987 IBM Model-M keyboard with my Mac, so I have an ALT key rather than an Command (Apple) key. But unless I'm mistaken, ALT and Command (Apple) are just platform specific names for the same thing. Macs also have something called the Option key, which I don't think has an equivalent on the PC. In my case, I just have Option mapped to my caps-lock key since I'm using an elderly PC keyboard. Regardless, I think that anyone on a Mac that uses this module would find the default search command (ALT-Q) causes their browser to quit. Though given that my setup isn't conventional Mac, it might be good for someone else on OS X to confirm.

Video embed for YouTube and Vimeo ProcessWire Textformatter module that enables translation of YouTube or Vimeo URLs to full embed codes, resulting in a viewable video in textarea fields you apply it to. How to install Download or clone from GitHub: https://github.com/r...atterVideoEmbed Copy the TextformatterVideoEmbed.module file to your /site/modules/ directory (or place it in /site/modules/TextformatterVideoEmbed/). Click check for new modules in ProcessWire Admin Modules screen. Click install for the module labeled: "Video embed for YouTube/Vimeo". How to use Edit your body field in Setup > Fields (or whatever field(s) you will be placing videos in). On the details tab, find the Text Formatters field and select "Video embed for YouTube/Vimeo". Save. Edit a page using the field you edited and paste in YouTube and/or Vimeo video URLs each on their own paragraph. Example How it might look in your editor (like TinyMCE): Here are two videos about ProcessWire https://www.youtube.com/watch?v=Wl4XiYadV_k https://www.youtube.com/watch?v=XKnG7sikE-U And here is a great video I watched earlier this week: http://vimeo.com/18280328 How it works This module uses YouTube and Vimeo oEmbed services to generate the embed codes populated in your content. After these services are queried the first time, the embed code is cached so that it doesn't need to be pulled again. The advantage of using the oEmbed services is that you get a video formatted at the proper width, height and proportion. You can also set a max width and max height (in the module config) and expect a proportional video. Configuration/Customization You may want to update the max width and max height settings on the module's configuration screen. You should make these consistent with what is supported by your site design. If you change these max width / max height settings you may also want to check the box to clear cache, so that YouTube/Vimeo oembed services will generate new embed codes for you. Using with Markdown, Textile or other LML I mostly assume you are using this with TinyMCE. But there's no reason why you can't also use this with something like Markdown or Textile. This text formatter is looking for a YouTube or Vimeo video URL surrounded by paragraph tags. As a result, if you are using Markdown or Textile (or something else like it) you want that text formatter to run before this one. That ensures that the expected paragraph tags will be present when TextformatterVideoEmbed runs. You can control the order that text formatters are run in by drag/drop sorting in the field editor. Thanks to Pete for tuning me into these oEmbed services provided by YouTube and Vimeo a long time ago in another thread.

I thought it sounded good, but haven't yet done enough research to answer definitively. I'm not sure that I understand the full scope of changes it would involve yet. But the benefit of meeting that standard would seem to answer any reservations about breaking things into yet more files, assuming it doesn't add overhead to the system. I think it's generally safe for files in /wire/core/, but some concerns about breaking stuff down in /wire/modules/ because there are possible file location dependencies in there (which can be overcome I'm sure). I'm probably not the best person to outline best practices about forks and pull requests. I just know the way that I understand code is a little different from others. I don't have a high comfort level with automated code changes from Git, because it's too easy for me to gloss over the details. I generally need to type something myself before I really see and understand the full scope of it. So the way I handle pull requests is to review the changes and basically re-type (or copy/paste where comfortable) into the code and commit them myself. I still tag it as the pull request so that GitHub understands it as the original pull request. This probably sounds a bit insane, but what can I say, I'm old and it works, and it helps me spot any issues a lot sooner. So if you are interested in making these changes, it doesn't matter to me if you do a pull request or outline the changes here in the forum, email, etc. Whatever works best for you is good with me. Thanks, Ryan

Great update Soma! I'm really liking the new ajax page search. Only thing I wanted to mention though was the default key assigned to this ALT+Q can't be assigned in OS X because it's the application Quit command. I did it, and it immediately quit the browser, closed all windows, etc. I changed it to CTRL+Q, which seems to work well, but am thinking you chose alt+q because ctrl+q has the same problem on windows? Maybe there is some other default for this that would be safe across platforms? Maybe something like CTRL+. or CTRL+[ or CTRL+- I love everything about this module, except that I'm confused by the templates/fields search. Probably because I'm just accustomed to clicking, rather than typing template/field names in the admin. In most sites, the quantities here are small enough to make the search seem overkill. So if there were a most wished for feature on my part, it would be that either: 1) it showed a list of templates/fields rather than a search box. Or; 2) that the field/template search boxes showed all of the fields/templates (that you could click to edit) and then filtered (rather than created) in the list as you type.

The request for a media manager has come up a few times here. Once you really get into the ProcessWire frame of mind, a media manager becomes redundant (at least in my opinion). But it's so ingrained in other CMSs that it's understandable why it comes up. In ProcessWire any page can be a media manager, able to share any of it's assets with any other page. Not just from the API, but from the editor (TinyMCE) as well, you can select images or files from other pages. If you need something formal, like a "shared images" page, then you would create that page in your structure and use it specifically for that. Different I know, but also very capable. We will continue to improve the file and image fields to the point where any perceived benefits from a separate file manager would be diminished.

I think these are good ideas. Regarding the quality setting: ImageSizer does support adjustment of the quality (via the setQuality() method), but there's not currently a way to get directly to that from the size(), width() or height() functions (like with the upscaling option). However, I'm wondering if this is something that needs to be on-the-fly or might be better off in a $config setting that you can set for the whole site? (or modify it at runtime as needed). Something like this: // just an idea, but not yet implemented, so don't put in your config.php yet $config->imageSizerQuality = 90; $config->imageSizerUpscaling = false; $config->imageSizerCropping = true; Of course, that could still be on-the-fly, by modifying the $config properties at runtime. But just wondering if this might be better than adding params to functions that most won't need to utilize. In addition, we could always provide a 3rd param $options array to the size() function that could override individual settings too, but wouldn't want to make that the only way since I'm guessing most don't need to set these things but once. Regarding the crop, I like the idea and capability. I just don't know how to do it, yet. If anyone wants to collaborate I'd love to get the capability in there. Rather than getting it in as another function param, I'd want to integrate that option as part of the $options array to the function, i.e. $image->size(100, 100, array('position' => 'top-left', 'quality' => 95));

You should also be able to grab the last image and add the description to it: $page->images->add($filename); $page->images->last()->description = "description";

In the majority of scenarios, when I replace an image, it's because the image has changed, and thus so has the description. But we all use things differently, and sometimes needs change from site to site. It sounds like in your case, you are replacing an image where you want to retain the same description. In this case, I would suggest making your image field a multi-image field, and just use the first image in your site. When you upload another image, you will then have two images. You can drag your second image to be first, and copy/paste the description when it should be the same. In this workflow, you at least can retain your description in a manner that can't be lost and is easy to migrate where you need it.

That formToPage function there is for dealing with a PW-generated from using Inputfields. It looks to me like your form is one you've created yourself, so there's no need to use formToPage. Instead, you would get your form values from $input->post, sanitize them, and then populate them to your page object, i.e. $page->nachname = $sanitizer->email($input->post->nachname); Also slkwrm is correct that the formToPage function was expecting a single Page rather than a PageArray. But like I say, it looks to me like formToPage is not what you want.

It's possible that there is some site out there using ProcessWire with hundreds of thousands of pages, but if there is, I don't know about it yet. I haven't gone above ~50k pages myself, though I don't think it would be a problem to scale as large as you need it to. It's not like an odometer on a car where there is a max upper limit and the higher you get, the more you are taxing the system. Whether your site has 100 pages or 100k pages, ProcessWire itself isn't dealing with any more data at a given time (only MySQL is). Scale should not affect the performance of the admin UI either. I actually think that the admin lends itself very well to large scale, and the larger scale you go, the more you'll appreciate some of the ways it does things. That's what it was originally designed for after all. As scale increases, you just have to be more careful about how you develop things. You need to be conscious of calls like $page->children and be sure you are placing limits on quantity of results returned from such functions, i.e. $page->children('limit=50'); More about that here. When dealing with high traffic, you need to consider caching at various levels. Know when to use template caching and markup caching. Optimize some situations with autojoin fields. You might also investigate FieldtypeCache to potentially reduce page load times and increase the speed of multi-field text searches. Make sure your PHP is running with an opcode cache like eAccelerator or APC. I'm also working on an htaccess/rewrite cache for ProcessWire (like WordPress W3C Supercache), but it's not done yet. The advantage of this will be that you can direct some pages to be delivered directly from the markup file (via some complex rewrite rules), bypassing PHP, MySQL and ProcessWire completely. I don't have anything to add about multi-server setups, but interested in hearing if anyone else has experimented here.