Leaderboard

Hi all, this is my first post here so i must tell that ProcessWire is the best CMF i know. Good work Ryan and others. After 14 days with PW i made two sites and alpha version of czech localization package. After hard time translating PW backend i found that i need one more tool. Tool which can find json files used on specific page. We speak about it on IRC with Soma and he made awesome new module for me TextDomainHelper.module https://gist.github.com/4520324 This module gives new posibility to Chrome PHP Debug module. In js output i can find all used strings and where are stored. Without this tool its much more dificult to translate PW! Example output: textdomain:/srv/http/pw_dev_translate/wire/templates-admin/default.php Text:Admin This module needs to have LanguageTranslator::getTranslation hookable. Ryan, can you make it hookable please?

TimeFormat for ProcessWire v1.0.3 This is a tiny ProcessWire Modules used for formatting times as 'X seconds ago', 'minutes ago'. It goes up to decades. Important note: this module uses 'soft limit' for units. That means that it will show '8 days ago' for 8 days, but '1 week ago' for 9 days, for instance. This will be configurable in one of the later releases. Usage It's very simple. Load module, pass the timestamp to `format` function. Bam, done. <?php $time_format = $modules->get('ToolsTimeFormat'); $posted = $time_format->ago($page->created); Links GitHub modules.processwire.com Notes v1.0.2 & v1.0.3 - bugfixing and module rename

I meant Nico <sings badly>Oh oh, diogo, Nico, whoah, don't go</sings badly>

Just had to implement admin theme install feature in ModulesManager to more easily install because I'm lazy dog.

Hi, currently TinyMCE is kind of standard implemented into PW. But I think that's no good practice because of the following points: (Almost) all of the Inputfields in /wire/modules/Inputfield/ are kind of "natural" html types. Like checkboxes or textareas. But TinyMCE is not. The size of the whole processwire folder is ca. 5mb and TinyMCE alone is 2.6mb. So TinyMCE is more then the half of the WHOLE system. And if I want to use ProcessWire only as CMF not as CMS I don't need it. TinyMCE is just one editor. The ACE module is another one but it's not installed by default. So in my opinion it's like IE on Windows (but of course PW is much nicer then Windows!). It's installed by default... How I would solve this: The easiest thing would be to move TinyMCE into the /site/modules/ folder. It would work from there as it is working currently. But you would have a stronger line between "naturally" implemented Fields and modules and additional modules (like TinyMCE should be!). And it would be easier to delete it if you don't need it because you don't have to "touch" the real system folders and files. Greets, Nico

But the answer isn't very hard! The year 2013 is a year of 3 things we'd like to accomplish: Continue with this nice growth we are currently experiencing Get the documentation in the top notch shape (so the forums don't explode with the same questions and confused people) Keep on improving website All of these of course while improving the CMS (and the ecosystem as well) itself. Note: this is my opinion, not official statement from PW Team

1001 things I love about ProcessWire, but the vision behind it I love the most.

HI Crssp Basically, a script would be a one-stop-shop It would open the file It would read the contents of the file and strip out unwanted tags it would store the elements (title, file number, body - whatever) in an array It would make a connection to the database It would create a page based on a template and populate the fields with the contents of the array. That is a bit rough, but the sort of thing it would do. So, as a single script you could just tell it the name of the file and hit GO and it would create the page. However, it could also be told to open a directory first and then do the same procedure with every file in the directory. You would just leave it to do it. It would create a page replacement for every file in the database using the template that you have created. The main issue is to work out how you want everything categorised, to be honest, but I assume that might be based on the directory structure? Or something else? Either way, for one of the serious coders here, this would not be a huge task. My suggestion for how to proceed would be: Work out how you want the articles stored/categorised in ProcessWire Start to put together your PW website, getting your templates and fields sorted out plus who is going to have access to what. Sort out the look and feel of the site, the template files, whatever framework you want to use and so on. Run the script and import the articles. Do a rather painful quality check to make sure you dont have any problems! Joss

Yes, I would like to see it as a separate beast in the long term. Which ever system people use, however, there will always be a need to get to the image and links systems. Is there a way of separating these out a little? I was thinking like: Editor Module (eg, TinyMCE) <-> Compatibility hook <-> Image System That means the image or links system is clear of any direct involvement with any editor and can be improved or modified over time, and a simple hooking system then just joins the two together. Anyone adding future alternative editors then only need to create the hook script as part of their module, rather than a dedicated system. Just a thought

I think it's a good approach going forward to keep big modules like this out of the core. But doing it now with TinyMCE could create some real upgrade challenges for folks. The TinyMCE module is also a bit of a different animal in that it has a couple of supporting modules in the core as well: ProcessPageEditImageSelect and ProcessPageEditLink. At present, all the site profiles we distribute also use TinyMCE. I think by the time we hit PW 3.0, we'll be at a point where we can look at excluding it. Ideally PW of the future comes with nothing but the absolutely essential core modules, and I think it'll be possible in the future (especially with modules manager as a core module). But right now ease of setup and upgrades takes major precedence over file sizes, as we are still an largely unknown CMS trying to grow our audience.

This is the plan. We just need to find a way to integrate it all and make it scalable and I look forward to working with Soma on this if he's agreeable to it. I don't think the current method of displaying all the modules on 1 screen will be sustainable as the directory grows. Plus, if/when ProcessWire gets really popular, the server probably won't be able to handle the load. I'm thinking we'll eventually need the modules manager to start with a "categories" selection list, "author" selection list, "what's new", "what's popular" and "installed/updates" options, so you have to choose one of these before you start getting lists of modules. Then once we are listing modules, we've got to have a way of paginating them once it goes past 100 or 200 or something like that. Once we get to that point, we've got something that is sustainable as part of the core. I'm thinking we should target this for 2.4. Edit: will also want to make it skip over any modules that don't match the requirements of the installed PW version (maybe it does this already, not sure). I agree, this is a "core" for me. But the reality is, once modules manager is part of the core, we'll want to potentially reduce the number of modules included with ProcessWire as part of the core. It'll be so simple for people to install modules that it simply won't be necessary for any modules to be part of the core except for the minimum set needed to install and run a blank PW.

Great! I'm participating on discussions without even knowing

Thanks. I would never have occurred to me (->first ). And yeah the cheatsheet is my new friend.

So really there could be a version check and where you can install admin themes you could leave a note for 2.2 users

the.nature the real secret of category is the.world made of category. the world made.of page catpage in.catpage if you.know catpage.that world is made of you.make of it whatever you wish.

Ajax Search 1.1.0 There was a request for a ajax live search. So I went and created a simple module. Added in 1.1.0 * added key support for browsing results with arrow down and up. * added escape key to close results. * added close results on click outside http://modules.proce...es/ajax-search/ From the readme: This module progressively enhances the search form to an ajax live search. It will perform a search like you would use the form normally, and returns the output of the search page. So the search will still work without js enabled. There's some basic styling attached to this module in the "styling-example". You can use it to get started. See readme in there. Setup the search.php So it works almost out of the box with the basic install profile of ProcessWire, you only need make a minor change to the search.php template file to only return the content part (results) on a ajax request. To get the ajax search only return the content, open search.php and change the output on the bottom to this: ... if(!$config->ajax) include("./head.inc"); echo $out; if(!$config->ajax) include("./foot.inc"); Module Settings It comes with some module options to define various settings regarding the search form. Following a list with the defaults. Minium length = 3 min length for starting ajax request Close button text = 'close' close button text ID of searchform = #search_form if you have a different search form id,class ID of input = #search_query if you have a different search input id,class Query name = 'q' this is the default param name as_query_url = '' if left blank the script will take the action of the form Any help testing this module is appreciated. If you have any questions or problems setting this up feel free to ask here. Also feel free to use this as a starting point for your own, or take out the script to implement it differently. It's quite simple and can be adapted really quickly.

I’ve been working on a simple admin theme. I originally just wanted to add a simple dashboard area on the home page to display some quick links to key actions and documentation for clients, but I ended up doing a whole theme. The main focus of the theme is for the client / editor role, so it’s not been optimised for the developer usage yet. There are a few enhancements which are aimed at clients (opening previews in a new window, showing tree actions on hover). I have also tried to optimise it for mobile layout. You can see a preview on this video It’s using the Bootstrap framework and Open Sans font. The main issues I currently have are a conflict with the Bootstrap framework scripts and the older version of Jquery that ships with the PW admin. If I upgrade to Jquery 1.8.2 a lot of PW admin functionality breaks (sorting, ask select, modals). If I stick with the currently shipped version of jQuery 1.6, the bootstrap scripts do not work (drop downs, message alerts, mobile navigation). The other big issue, is I made a few simple hacks to some core js files (/wire/modules/Process/ProcessPageList/ProcessPageList.js, and /wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js) - this was mainly to insert extra css classes here and there or to show if the tree has children. Is there a better way to do this? Other issues I am thinking about Is there a way to modify the “add new page” workflow? So when the user adds a new page, I’d like to change the default “You are adding a page using the …” message. Maybe this could be an additionally template field called “instructions” or “”details” ? It could be a used as a kind of “templates documentation”, which could be used to document the project for other devs and designers and for the clients / editors. How can you modify the login screen without overriding this file (/wire/modules/Process/ProcessLogin/ProcessLogin.module)? Also not to sure if having two save buttons is good for usability - maybe I will just have one in the header and make it fixed as you scroll.

Yeah well, when I wrote that, I forgot for a while that it has to be confirmed on modules.processwire.com by Ryan, I suppose. So many mistakes… But, I repeat, it's out!

I hear ya. 11 months ago has place for blogs for one There are many things planned, namely: limiting the level you go into (maybe you want something like 432 days and don't want it translated into 14 months) other formats (today at XX:YY, for instance) configurability of soft limits simpler way to go to hard limits than defining precise soft limits I just wanted this one out quickly, because I also planned to introduce new Modules group with it which I hope will catch on.

Forgot to mention, I've pulled in the last of Soma's pull requests so this is now v1.0.5 to implement the added functionality he wrote as well as the fixes for the bugs he created My fault for not testing

Without knowing much about the code I'm going to say that it should be possible to abstract it out at some point in the future to make it easier to drop other editors in with their own links into those parts of the core but I can see why ryan would want to leave it til later. It brings up tricky questions like if it's removed from the /wire/modules/ dir, how do you get the new distribution of /site/modules/TinyMCE to people upon upgrade? Since it wouldn't be packaged with the new version it would have to be done automatically by the then-integrated ModulesManager I think, causing someone yet more fun coding headaches But yes, I'm going to go out on a limb and bring out that line I like to use: "Everything is possible in ProcessWire".

Digging up an old topic I know, but I had a need to have a module do some AJAX to request some content from itself - the details of that are irrelevant for now, but you can have a module intercept a page request so that you can have all your PHP code from the AJAX request sitting neatly in the module itself. For example, if your module's JS file sends an AJAX request on click of a certain element and you want it to return some data, you can do this in your module's JS file: $('#myelement').load('ModuleName-ajax?do=something'); And then you can intercept that request to yoursite.com/ModuleName-ajax by putting a line like this in your module's init() if (strpos($_SERVER['REQUEST_URI'], '/ModuleName-ajax') !== FALSE && isset($this->input->get->do)) { echo "Nice!"; exit; } And of course this then echo's "Nice!" into the leement with the ID "myelement" in your HTML. The only reason I used the module name followed by -ajax was to make sure that that would never be a page on the site. It just avoids confusion if you made a site about modules I wonder if someone will tell me there's a better way now

Greetings, OK, while we're at it... Another idea is to read Jorge Luis Borges. I'm not just throwing out random authors. These works are linked to the whole idea of categories. Yes, that's right -- ProcessWire seems connected to these literary works. There is a lot to say about this, but I will save it for another discussion so Joss's original concept is not completely covered over. Now I know I am in the right crowd when I can talk about D'Arcy Thompson and Borges. Thanks, Matthew

I support this, +1 Additionally, I think ACE Editor should be shipped with PW and used as default edit…

Thanks Ryan. I'm still up with including Modules Manager in the core, but I'm trying hard to imagine how to go for it and what all the features are that are absolutely needed and super important. We discussed this already some in this thread and I still couldn't make up my mind thinking about it. However One thing is sure that it should still work the way it is now and let you install modules without internet access (local environement). But the way it works now this is already possible and it is no problem I think. √ I don't think an alternative "upload" function via a form is a good way, as you already can put it manually in such a case (already have it locally for example) Now working on the module a little and thinking about versions. How should we handle this all if at all? Module Version: There's a module version that have to be different to recognize an update and output a action link according. By now it just replaces the folder. What if the new version doesn't work and. In short, would some version management make sense here, with rollback etc? I think this would be harder and a lot more work to implement. But also thinking about managing modules through such a interface with direct downloading may really need such features as a "manifest" for the module with update instruction that can be displayed while installing and make some of those thing required for PW modules. Rather now than later. Currently there's no way to implement a good system without it. There's some idea's but I can't make it up myself. Module PW version compatibility: On modules.processwire.com you can select for what versions of PW the module works. Which is cool. But currently when there's a new PW version option there like the 2.3, almost all modules don't have this checked. So now checking for the version on PW locally and the ones of the modules wouldn't work so well as there're only one of mine that has it checked. What you think? Some soft notification that it may not work? Not really. But I don't see a nice solution to this issue, maybe otherthinking it.

Yeah, there's no Windows version of that. I thought your videos were pretty good - clear, concise, to the point, you explain things well I'll definitely have to put my own recordings through the Windows video editor myself for some basic editing

Also, since you are on /portfolio/, you might switch the call for portiolio items: $portfolio_items = $pages->get("/portfolio")->children(); //this is your call $portfolio_items = $page->children(); //you have '$page' from PW - current page Since in template you have always access to current page in $page variable, if you visit /portfolio/, $page is already there for you Note: if you are not using the page array in any other way later in code, you can as well do this: foreach($page->children() as $item){ // items' code }

Soma, here's what I did in FormBuilder, which also requires wireRmdir: /** * Temporary, until Form Builder requires PW 2.3 * */ if(!function_exists('wireRmdir')): /** * Remove a directory * * @param string $path * @param bool $recursive If set to true, all files and directories in $path will be recursively removed as well. * @return bool * */ function wireRmdir($path, $recursive = false) { if(!is_dir($path)) return false; if($recursive) { $files = scandir($path); if(is_array($files)) foreach($files as $file) { if($file == '.' || $file == '..') continue; $pathname = "$path/$file"; if(is_dir($pathname)) { wireRmdir($pathname, true); } else { unlink($pathname); } } } return rmdir($path); } endif; Always be very careful with wireRmdir and check everything you send to it to make sure it's correct and not blank, etc. This function always scares me a bit. The wireRmdir function will empty your entire file system if told to.

Looks like a .htaccess issue. Maybe there is a rule in your .htaccess that forces all subdomains to the www. version? Might want to add an exception for each subdomain? https://github.com/ryancramerdesign/ProcessWire/blob/master/htaccess.txt#L89 That is the line (and below) for the redirect of subdomains, my best guess you have a similair line like that in your MODx .htaccess

Omg what did I do!! Now I cant decide which one and am constantly swizing between them... No but it's fun and makes it easy and interesting comparing them. Some need updazes.

Or LegoWire

No I think WillyC has some insight here. A page tree can be a type of fractal, which is what I think he's trying to show with that image. And the man is presumably creating and manipulating the tree (fractal) as you would in ProcessWire. Translation: the nature/secret of categories is that they are just pages. world=your site, catpage=category+page. So your site is made of categories or pages, and the distinction does not matter as it's all the same. Translation: Once you know the true nature of pages, you can create anything. Self actualization or something? Do I have this right WillyC?

lol, pointerpointer.com

Hmmmm??? Sounds like it is going from one note and then down 12 semitones. You do the sound once then copy it and overlap it with a gentle cross fade (you can hear it coming in.) Then you chop it in half and swap the halves over and join it back up again and voila, you have your loop. Because you are being strict about the starting and ending on the same note (this is playing fifths I think), then looping is relatively easily. We used to do this sort of thing on quarter inch tape running at 30 inches per second for high quality. To get the loop working we would run it down the corridor on mic stands across little tape reels. If you were confident about starting tape machines at the same time you could run it through several and therefore get the playback at several points, dub the result onto a new loop and start again. The famous doctor who theme used rather a lot of this, I believe. Joss

I simplified the options as a matter of personal preference, not because I thought you had too many, I can see the pros/cons of either approach, also the name "Better" is only in reference to the original implementation, though maybe a word like "Configurable" or "Advanced" would be a better choice. Thanks nikola, I will take a look at this, I don't use the thumbnail module on all my projects so I will test it with one ASAP and fix.

I am partway through that here: http://wiki.processwire.com/index.php/Page_Field And I am creating categories and tags for myself at the moment, so I will use that as an example spin-off page.

Are there any plans to upgrade the TinyMCE editor again in ProcessWire 2.3? The current solution works fine overall, but what I'm really missing are the webkit image resize handles (integrated since TinyMCE 3.5.5).