Leaderboard

I'm not sure you can directly compare modx and ProcessWire on load times unless you have them both in original state without any modules installed, except those required by the core. Even then, they may not be directly comparable unless they are accomplishing the same thing and providing the same level of tools at bootstrap. ProcessWire's boot time will be very much affected by how many "autoload" modules and running and how much activity they perform during their initialization process. It will also be affected by your overall quantity of modules, fields and templates. I would assume modx to be the same in that regard (assuming they have some equivalent of autoload modules, fields, templates, etc.). So whichever one is faster may have as much to do with how much stuff you are asking it to load as part of the bootstrap process. We do have a rather extensive API that most systems don't, so we do hand over a lot of ready-to-use tools to your template file and part of our bootstrap, and very likely most systems you'd compare PW to don't have near the scope of tools that we do. But we always want PW to have the best performance possible. In PW a "no api calls" page is not going to make any difference in the time of the bootstrap process, because execution of your code (in your template file) occurs after the bootstrap process. Again, I'd assume modx to be somewhat similar in this regard too. I did measure the time it takes for our bootstrap is a fairly blank state (with regard to modules) and found I was getting about 0.2s (200ms) bootstrap times. Admittedly, this is on a slow computer more than half a decade old, but did have APC enabled (APC is an opcode cache). Then I disabled APC and found they were at least 100ms higher. This is the time it takes ProcessWire to boot and give control to your code. As far as how long it takes after that depends entirely on you and what you are doing with the API. I would guess that in Soma's case, he's got a faster computer than me and perhaps with an opcode cache too. Even though my computer is old and doesn't have much in the way of horsepower, I thought there was some potential to speed up the bootstrap process (there is always room for optimization), so I've gone ahead and applied some optimizations to the dev branch, now available in PW 2.4.5. On the same computer as before, I've got the bootstrap down to 0.08s (80ms) with APC enabled, or 0.15 (150ms) with APC disabled (no opcode cache). This is with a logged-in user, so it's a pretty good performance boost. Is it possible to tell the difference in speed in person? No–we're talking about amounts of times that are beyond our perception (beyond my perception at least). But performance is always a priority in our core. And regardless of whether another platform might boot faster than ours or not, I think most would agree that ProcessWire's performance is always better in the areas where it really counts. In PW 2.4.5 (dev) if you want to measure boot-up times, there is now a "Timers" section in the debug info at the bottom, but debug mode must be enabled to see it. Keep in mind that debug mode takes up quite a bit of resources in its own right, so actual times would likely be less with debug mode off.

What Ryan and Antti are saying here definitely makes sense (and they're the ones to know the module best anyway) but this was exactly what we were wondering too when that first Lister screencast hit our office. For 90% or more of all product, news, event etc. lists and/or tables Lister views would be more than enough. No custom, site-specific code and even being able to allow customer decide exactly what is visible and where.. and then modify that whenever needed -- how damn cool would that be? In case you ever decide to take Lister to that direction, it'd be a killer feature for a lot of sites (and an awesome time-saver for people building those sites), but I totally understand that this was never your intention and it would probably require a ton of extra work. Perhaps even so much that building another tool just for that would make more sense. Still, +1 for this idea from me/us

Roger i guest you are a newbie( New to Processwire). i guess that is why you are sounding that way, Inorder for you to achieve the best from Processwire, always try to be patient as a web developer/programmer or a web designer. When ever you have issues, ask your questions in the right manner so that other developers or Processwire experts can give you a better solution to your problem. Well without much ado, start working with Processwire locally (install on your local system) on your system and see how it works before you go live so that you understand how it works before you deploy to a remote site. Though i am new to processwire, i faced the same problem and guys here helped me to resolved it and with my little knowledge i have been able to set it up and i am still modifying some things, also learning the Processwire API such as $page, $selector etc. Roger Never give up, with patients you will always achieve the best using Processwire. the link to the site i setup with processwire is www.mcalleluyashow.mil.nf and i am still on the modification of the site locally which i will upload the new changes this week so that you see the new look of what i i was able to do with processwire apart from the default settings. Roger i am glad you are here like me, because Processwire is flexible and user friendly and i promise to go more to the core of the Processwire API Thanks

@Pierre-Luc Take a look at the CryptoPPP library module which has a couple of generator routines (genKeys() and num2string()) that do almost all of what you'll need for this. Something like... $output = CryptoPPP::num2string(CryptoPPP::genKeys(), $length, $charset); ...where your $length and $charset choices are controlled by your form entries. All you need to do, apart from loading the library module, is check that the $output has not previously been generated if you really want to guarantee that it is unique. (The genKeys() routine is a pretty good pseudo random number generator but, as with all random number generators, its output is not guaranteed unique.)

I think markup module that takes few variables: selector, fields, results per page and then renders the list would be cool. That could be used together with InputfieldSelector or just as independent helper. Teppo, you should build that!

Problem was solved! Apperantly my host ( strato.de ) added some new bullshit option called "PHP Boost", description of which is "PHP codebase cache, up to 110% speed benefit by PHP scripts execution". Turning it off solves the problem, this "feauture" was not annaounced in any way, and when adding it they've turned it on by default. I Have no idea what exectly it does ( theres is no significant spped difference felt, suerly no 110 % ) and how it works but appereantly it breaks more complicated scripts than "echo $imAWebDeveloper; ". Anyways, im glad that problem is solved and the reason is found and i hope this topic will be useful for other ProcessWire users by the same host. Thanks for your time and support. Cheers...

Is this a trick question http://modules.processwire.com/modules/process-blog/ http://modules.processwire.com/modules/blog-profile/

thanks for the hint. new german updates for actual PW dev 2.4.4 (17 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). added files: wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json pw-lang-de-dev-update.zip best would be to have a GitHub repo for the dev lang-pack as discussed above, so others can check and correct files if necessary?

@Jonathan: Hi, it's me again, - I have some more thoughts / suggestions If someone want to use your optimize module and simply the ImageSizer (or any replacement of it), it's just fine as is. But if someone want to use the PageimageManipulator and the Optimizer, the option to temporary suppress the Optimizer is needed: $image->pimLoad('prefix')->someManipulations()->pimSave()->width(300); // this works fine, no need to suppress the optimizer $image->width(300)->pimLoad('prefix')->someManipulations()->pimSave(); // this doesn't work, we need to suppress the optimizer in the width(300) call! // we only want to optimize the final variation and don't want optimize intermediate images Next points all regard to pageImageOptimize() / pageimage::optimize(): With the initially module, the pageimage::optimize() was made for original images only. To preserve the original source (for quality etc) you create a variation with a name like basename.jo.jpg. That's all perfect. There is only a little issue: with the .jo in the name of the variations they get not fetched by the pageimage variation collections. As a result, when deleting / removing original images, these variations would stay as orphaned files. So, I know there is currently no way provided by PW to solve that (But there is already a private discussion with Ryan on how to provide a good support for custom imagefilename suffixes) As a quick (but bit clumpsy) workaround, you can change the .jo by a .0x0 - This matches the current used regex of the variation collections and isn't a name that could already exist. Not only after the use/need for the temporary suppression of the optimizer, there are application cases where someone need / want to call pageimage->optimize() not only on original images. For example when working with the PageimageManipulator: $image->pimLoad('prefix')->someManipulations()->pimSave()->optimize(); // here simply the existing file should be optimized, no need for a new variation name or a new pageimage object I have updated the pageimage::optimize() to recognize original images vs variations and act upon that. If the basic usage supports individual options per image, the optimize hook needs too: $options = array('joQuality'=>80, 'joThreshold'=>30); $image->optimize($options); ----------------- Finally some thoughts about how the different Pageimage modules could work together - If you implement support for PNG too, a name change to something like PageimageOptimize (PageimageOptimizer) would be useful. - Could it be useful for the average user that you do a check against the ImageSizer quality (hook)-before resizing? And if there is no individual setting, temporary set it to 100%? This way an average user do not have to know all about how it works best. And all users can save some code writing, no need for: $options = array('quality'=>100); $image->width(300, $options); just type $image->width(300) and get the best possible result. - with the PageimageSizerImagick (formerly known as ImagickResizer), the user can choose what type of metadata he want to keep, EXIF, XMP, ICC-profile. XMP isn't supported by JpegOptim, but the others too. Would it be useful to support these with the Optimizer? I can imagine that both modules have their own global settings in their config screens, but both check for individual settings on a per image basis: $options = array('keepEXIF'=>false, 'keepICC'=>true); $image->width(1200, $options); $image->optimize($options); I think their will be some more Sizers in the future, PageimageSizerImageMagick, PageimageSizerNetpbm, PageimageSizerWhatever and all of them should support and use the same options where possible. This way a user can write code for image handling independent of the image rendering engine. What do you think about this? I know its much at once and I have a bit of a guilty conscience to push so much stuff here. But I think it is needed that the existing and future image modules work well together and just by installing / uninstalling them.

Mosravo A couple of requests/pointers before I attempt an answer If your question does not relate to the specific issue in an existing thread, please start your own topic. This way, the conversation remains clear... Not everybody uses the same templating approach in ProcessWire. Not everybody will know what main.inc is, let alone know what sort of code it contains. Please, be as specific as possible in your questions. I am assuming your are talking about the main.inc in the Blog Profile Please, enclose all code within the code tags provided in the post editor when you are making a post (see the icons) Now that we have the niceties out of the way.. First, I would suggest to test your code in a standalone test page using its own template file rather than something as complicated as the Blog Profile. This way, it might be easier to debug.... Second, your image paths look like this: img src='cssSlider/data1/images/img2013122100548.jpg'. That's definitely not a ProcessWire page image path. Using web developer tools, have you confirmed that the images are actually being served? Are they missing? If not, how are you generating those paths? I am assuming you are not hard coding them, or are you? You have at least two choices with respect to serving the images to your slider plugin: You can create either 1 page with multiple images that you can loop through and output the html that is required by your slider plugin or you can have each image be its own page and loop through them outputting the html the plugin needs. You can save your images in your own folders somewhere in your /site/..e.g. /site/assets/myfolders/ and use PW API to get the relative path to your custom folder and serve your images from there I would go for #1. It will help you to read up on the PW image fieldtype API here: http://processwire.com/api/fieldtypes/images/ Also have a look at the $config API here: http://processwire.com/api/variables/config/ Btw, I don't know about cssSlider but its code looks overly complicated? There's a ton of jQuery slider plugins that would produce much cleaner code...just saying

Here's a draft of a simple service adding resource URIs. Just playing around, so don't take this too seriously But the idea would be to replace numeric IDs everywhere in the model with URIs instead - and then, in Fields::get() and Templates::get() etc. you would convert or "sanitize" the ID to a numeric ID using something like $key = wire('resources')->id($key) ?: $key; In addition, wire('resources')->get('...') would work for any type of resource - it uses the first portion of the URI path as the name of the resource collection, e.g. 'pages' or 'templates' etc. which can be resolved directly by just calling e.g. wire('templates')->get($id) etc. Supporting URIs in page queries might be tricky, I didn't spend much time investigating that, but it doesn't look trivial. Anyway, curious to hear what you think of the idea?

This has been asked for/mentioned/requested here a few times. I think all it will take to produce is someone with the money and/or skills to put it together. It'd be me if had either of those two

So, now, I've found the error. I have renamed when uploading files to the server to CKEditor 4.3.2 folder in CKEditor and have the whole thing now reversed and overwrite the module with the new files to the web space. Now my CKEditor is already displayed. So I am now smarter and have thus gained valuable experience but thank you for the quick help.

Introducing ProcessWire ProFields: Table – it lets you literally define your own Fieldtype! This is one of the most exciting ProFields and it's something very different than any other Fieldtypes. I think it is best described by this screencast (be sure your sound is on): Special thanks to Joss for his great voiceover on this screencast. Please view the video at 720p and full screen if possible. Read more about the Table Field Table is part of the ProcessWire ProFields package now available for purchase in the ProcessWire store.

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

After months of silence on the forum I've decided to speak out and introduce a brand new admin theme for ProcessWire 2.4.x I've made the theme initially for our internal business project and I've decided to share it with you all The theme itself is designed only for ProcessWire 2.4.x and up because it's wrapped as a module (new theming design approach introduced in ProcessWire 2.4) and it also has it's own options you can configure. It has all the bells and whistles as Default Admin Theme of PW 2.4 as well as some of my own You can download it from here: https://github.com/nvidoni/AdminThemeModesta and please let me know of any mistakes you find during your workflow... Changelog: v1.0.1 Added unpublished pages status icon next to username (fires modal window with unpublished pages list that you can edit) Improved PageList (children are more indented with arrows before them, hidden pages have more lighter color and icons have more darker color - by suggestion from Martijn Geerts) Other CSS improvements UPDATE: You can find version compatible with Processwire 2.4.4 and up on dev branch: https://github.com/nvidoni/AdminThemeModesta/tree/dev and also let me know about any mistakes that should be fixed. Dev version isn't updated to v1.0.1 yet because of strange problem with theme not switching right (doesn't activate) - it started to happen from 2.4.5 dev version of PW...) and it seems it happens only in Windows environments...), hopefully we'll fix this soon. To sum it up and let the images do the talking, here we go:

I have build another non-profit website http://www.fmgcs.com with ProcessWire 2.4 completely free! This my community website which I redesigned and hookup with ProcessWire. Before it was static html pages. I have spent quit a bit of time on designing and customizing templates. Please provide your feedback as you normally do. Thank you!

@Soma I’ll look into it, it looks like I could simply add some way to make PW aware that it can use a random string generator instead of the date or title. @netcarver I already have a function that I reuse on every project for this, but I’ll look at your code thanks!

Well Ghost gets great reviews: https://ghost.org/ It's free if you're selfhosting. But then again, you could also bootstrap PW into the site and use k's blog module still

It's really great, that you keep it up to date with the dev version. I have also found another file that needs translation for the new Lister module: /wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module This seems to contain the phrases for the filter dropdowns.

One way is to well redirect to another page that is only a text page instead after sending email... // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $message, "From: $form[email]"); $session->redirect("/some/thankyoupage/"); // populate body with success message, or pull it from another PW field // $page->body = "<h2>Thank you, your message has been sent.</h2>"; // $sent = true; }

Hi Benjamin! That kind of selector is not supported in the core apart from dev version. I'm not sure exactly when selectors have been updated to allow wildcard search to the names of pages via a page reference (which "roles" is), but that seems to work in the latest dev at least. Then again, the module doesn't handle these kind of errors too good - you need to logout and login again to get rid of the error as the selector is saved in the session. Maybe I should try and find a better way as I've been tripped by this behavior myself a couple of times as well. But meanwhile, and to achieve what you were trying to do, update the PW core if possible. That should do it.

It's called PRG design pattern: http://en.wikipedia.org/wiki/Post/Redirect/Get You could for example redirect to another "Thank you" page after success.

Thanks Marty for the answer. I guess i just need to find the right hooks for file writing if they do exist then the rest will be doable. I have the time to make it. Of course I'll share it with the community ( I got a few other modules under dev that I will share along the summer ). J.

I added a toolbar to profile the performance of partials/layouts. Check out the attached screenshot to see what it looks like when the toolbar is open, by default it collapses to just display the totals.

And I watched the game with my girlfriend who is German Lot's of world cup ahead still

@Diogo...when you come out of hiding , commiserations...Silly Pepe! (but naughty Müller ) .....

There's a permission for viewing a page and a permission for editing a page. Assigning the page edit permission to a role means they see the Pages page in the admin. There are situations where I don't want them to be able to see that (custom intranets). It would be nice if it was possible to have a separate permission to decide whether or not to show that page. There is a way to code around it in the admin template and only show it for roles that I specify, but it would be nice if there was a way to do it with permissions.

Names should be reasonably safe - it's a marginal case where two developers both decide to add a template named "blogpost", and it won't work either way, since you can't have two templates with the same name in the first place, so whether or not a GUID or some other new identifier enables you to identify the referenced template, you're still stuck with a problem that cannot (and should not) be solved. The system makes assertions for every possible type of migration, ahead of attempting to apply them - for example, "add template" will abort the migration process if a template with the same name already exists, etc... so it's already reasonably hardened against poorly coordinated changes. It's not intended (or expected) or designed to deal with poorly coordinated changes - it's not a "version control system", it can't "diff and merge" database changes or anything of that sort. What should work though, is if two developers independently add non-conflicting fields and templates, after coordinating and planning their work properly, and you'd be able to merge all the changes two ways. That's really all I was expecting or hoping for. It will permit other changes, like re-ordering of fields in a template, but the last applied order "wins", there is no (worthwhile) way to merge those changes. > I'm guessing you'd convert a template_id to a template name, and a parent_id to a page path Exactly right > You are right that without knowing what the properties mean ahead of time, you'd probably need some interface that externalizes those values to something considered more portable Probably the simplest (perhaps the only?) solution is to add hooks, so that field types can replace foreign keys with names or paths, and vice-versa. It makes me wish though, that field values containing e.g. template/page/field IDs were identifiable as such... this could be done in at least three different ways: Foreign key values could be somehow identifiable as foreign key values themselves - e.g. using some kind of value-type or value-object, or a URI scheme of some kind, like for example "pw://template/123" rather than simply "123". Foreign key values could be made globally unique, e.g. using GUIDs, so that when you encounter a GUID, you can go back to the ProcessWire API and ask for the resource with that GUID, whether it be a Template, Field, Page or some other PW type. Adding some kind of "schema" to Page models - e.g. allowing you to define what you're storing; so you would still be able to store an integer of course, but there would be some way to define what datatype you're storing, e.g. Template ID or Field ID, etc. I think every approach would have it's own advantages and drawbacks. A URI scheme would be very developer-friendly, since URIs would be easily readable in var_dump() etc... GUIDs would have advantages in terms of data portability in general, since any resource created on any system would be unique identifiable - this would help in the case of migration and import/export of any type of resource in general... Adding an actual schema to Page models might be the most complicated solution (for developers) and I'm not sure if it has any advantages over the other two. Thoughts?

Maybe activate the hidden formbuilder page for all languages. Not that if you use option c you'll have to add styles and scripts manually to your site.

I also recommend to work on a local environment (xammp, mamp, wamp etc.) for making your first steps with Processwire.

I explained that question poorly, I was thinking, while Lister is clearly an uber powerful Admin tool, as a by-product piece of functionality, could a Lister 'view' (a preconstructed 'find') be made visible on a public page (read-only, fixed results, no controls available to the public)? It would be a sort of query and results builder for custom finds. I hope that question makes sense and I've not misunderstood something obvious(!).

PW 2.4.4 on the dev branch...

Sure, that could work but I don't think people see it as an additional filter. It feels a bit too specific. I made a quick mockup of my initial suggestion. I'm thinking that the boxes shows up when you hit the "actions" tab - since that's the only place where they'd be needed.

Thanks! Yeah, it's fine if it's something you'll only do once - like data cleanup in your database. But I'm thinking that Lister is close to becoming a great moderation tool as well. As a developer, you could just set up a Lister-page called "Incoming stories" and have your reviewers use that listing to review any user-submitted posts. But they would need a quicker way to manage the post, than applying extra filters. Typical use case: Lister shows 10 new, unmoderated story posts. 2 of them needs to get deleted right away because of spam. 3 of them are missing proper categorization and needs to get the tag "tech" added. 1 is of too poor quality and can also get deleted. 4 of them are ready to get published on the site. Being able to quickly apply an action to eg. 3 of 10 items would be a huge productivity boost in this case.

This looks great! I'm just missing a way to apply actions to selected items in a list. Eg. using checkboxes to the left of each item (think Gmail). Some selections, based on eg. quality, can't be handled through automatic filters.

Send me a rough script and the original .....

Got first version of SwiftMailer implementation working locally, should be able to push to GitHub after some testing. Ryan has, once again, made things too easy for us..