Leaderboard

Just wanted to mention some updates I was recently working on. 1. The Cheatsheet is now a ProcessWire Site (since couple months already). This allows for easy updating by team members. Also it allows for implementing stuff that wouldn't be easy with a static html. So all entries are now pages. This was very easy to setup and import the html data via a simple script. 2. Since we now got all the power of PW there, my idea was to create a API doc Site that would serve as a alternative extended sort of cheatsheet. Similar to php.net where you can see more details along with simple code examples and further information like what version introduced or if it's depreciated, related links to other API's. Also there's possibility to add comments. This opens great possibilities to give more information to you, add a "social" aspect, and at the same time also open it for indexing by search engines . You can see the current (not finished) version of the extended API doc here: http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ We are currently adding content and examples to the API's so this will take some time. Also there will be added some cross linking from the Cheatsheet to the extended docs when ready. Hope you like it. (edit: just realized that this was the 100th response in this thread! great coincidence)

Yes, it does work with Fieldsets. The first version doesn't work with tabs (FieldsetTab) though. I think this seems like a good idea Pete. I'll look into how best to implement in the next version. The first version I need to get committed to the dev source tomorrow (30th), so not planning to expand the scope of it this week, but moving forward, would like to continue expanding the dependencies system everywhere it makes sense. And your ideas here do seem like they could be very useful, and may not be very difficult to implement. Something to keep in mind is that dependencies are assumed to be things that can change during the course of filling out the form (i.e. if this field is populated, then this field is available, etc.). So when we get into things like user roles, we're talking about things that don't change during the course of the form. So these would be an entirely different kind of dependency. These would be dependencies that would be applicable before the form is actually rendered. They wouldn't need to be considered by the javascript dependencies at all. As a result, it really might make more sense for this capability to be something separate, at least from the code perspective.

You should install the dev version 2.3.2 from Github. (I guess the latest version is now 2.3.3) Then read this http://processwire.com/api/multi-language-support/multi-language-urls/ and marvel about how easy everything is

Help on the way https://www.google.com/search?q=processwire+error+Maximum+function+nesting+level+of+'100'+reached%2C+aborting&oq=processwire+error+Maximum+function+nesting+level+of+'100'+reached%2C+aborting&aqs=chrome..69i57j69i64.6964j0j1&sourceid=chrome&ie=UTF-8

ryan - just a thought, but would it be possible to make it so that fields can be shown depending on whether a user has a certain role, or even ID? Certainly roles would take you one step closer to a system I used to use where there was an editing flow with a website's content - someone would work on content, then their manager would fill out some other fields on the same page, sometimes in another tab in the editor, before finally publishing a page. It's not something that everyone needs, but to my untrained eye it also doesn't look like it would be too difficult to add (*ducks for cover*), would make it even more powerful and could be useful in many different scenarios. I guess the selector for that would be something like user.role=editor|manager as well as user.id=41 maybe for scenarios where the main admin user wants to test some stuff or have hidden fields that other superusers can't see (though that's silly as other superusers could give themselves access anyway - just thinking of odd scenarios!). Can anyone else think of uses for this?

The next version of PiM will be able to enhance the Thumbnails module (after I have successful send a pull request to apeisa and he have had time to check and implement the code, - hopefully) While writing on the (optional) support for PiM with Thumbnails, owzim has written the js-code that rebuilds the crop rectangle, - and also he has tested and forthrightly commented my various tests with that. Thumbnails will recognize if PiM is installed and use a different routine then. And without PiM the Thumbnails Module will use the PW core ImageSizer. Since dev-version 2.3.3 the ImageSizer uses automatic sharpening after resize. So - once after updating to the new module and a newer PW version (dev 2.3.3 or stable 2.4) everyone has sharpening support. We both (owzim & me) want to have the coords & data stored and pre-selected when coming back to a previous created thumbnail. We use a wrapper class with a read and a write method on a session basis to achieve that. (After closing the browser or otherwise destroy the session, all data is lost) But together with PiM the coords and options can be stored permanent! It can be stored as metadata in a IPTC custom field (2#215) with the original imagefile. If you want enable permanent storage you have to create a config array named imageManipulatorOptions in your site/config.php and create the key thumbnailCoordsPermanent and set it to true: $config->imageManipulatorOptions = array( // ... 'thumbnailCoordsPermanent' => true ); So, - if you don't want permanent storage, you are still able to use Thumbnails Module and PiM together, but without permanent storage. https://youtu.be/IHwjL7YSfRo EDIT: PullRequest is send https://github.com/apeisa/Thumbnails/pull/13 (the unorthodox way)

Honestly, I think it's a bit soon for considering this. I can certainly make a one to one relation with the time that I spend here helping people (two modules and one language pack are not very impressive to refer ) and the working time that I economize because I use PW and not another tool for my work. I feel that I owe so much to Ryan and to this project (community included *), that I wouldn't try to get a compensation for contributing in the present or in a near future. If someone deserves a compensation for all his time, that someone is Ryan**, and he told already that he wants to get it from his payed modules and not through donations. * I may not ask lots of questions, but I profit a lot in silence from the answers to questions that others make ** I feel that I should open an exception to refer Soma also. The work he has already done for PW is huge (https://flattr.com/profile/philipp.urlich)

It's important for there to be a hard limit on page numbers just from a caching perspective. You don't want to have anything in your site that can generate an unlimited number of cache files and fill up the hard drive. But that doesn't mean the limit has to be 999, just that 999 is what I perceived to be the upper limit of what would ever be even remotely practical to support in pagination. I'm fine with making this configurable though, but hope you guys use it to configure the number down rather than up.

oh, it's possible because of the help from owzim! so it should be: "Big tnx @owzim, too"

For us it is pure business: it is great to have possibility to buy (or support) development from outside of our company. To get it directly from Ryan is great bonus. To share it open source and make ProcessWire even better is of course superb. The better and more popular ProcessWire is, the stronger our development framework is. It would be great to see fundraising projects for module development. Building open source modules is fun, and I don't believe anyone hates the idea to make few bucks at the same time. But I think there are plenty of real money making opportunities coming now that ProcessWire is gaining more popularity: paid modules, paid profiles, site building, paid support, books, learning videos / tutorials, consulting... Currently PW has still relatively small audience, so I don't believe any module or book can get super high sales. But this is growing audience and very little competition. I would love to see more people trying to make money this way.

http://bit.ly/1dTvVsI oops...

Asking for a page by ID is really specific, so it's not going to make you jump through more hoops than that to get at what you want there. If you know a page well enough to know the actual ID of it ahead of time, then it's not really a search/find at all. Regardless of whether you use get(123) or get("id=123"), ProcessWire can bypass the entire PageFinder engine (and any overhead associated with it).

Although small donations PayPall like things for ProcessWire I love to see. But the reason I started this topic is that Avoine, (the company where Apeisa works) was so generous to give their investment back to the community. We all benefit. I'm on this forum in free time for fun and I'm on this forum getting things done for the company I work for. The first part, (free me ) love to be involved in things where the ProcessWire community benifits. There are plenty of great developers here, sharing, writing, making PW the best place for me to be on the web. What if we work out ideas, having fun and let the build begin. Developers don't have to do all things free. The little bit payment can just be a motivator. (they actualy they deserve). And for me (the free) don't want to get the guilty feeling of leeching.

What you'll probably want to do is: 1. Find all pages whose date_field is not empty but whose date_field is past $today. $what_you_dont_want = $this->pages->find("date_field>0, date_field<$today"); 2. now select what you want $what_you_want = $this->pages->find("template=template_with_date_field, id!=$what_you_dont_want, limit=$limit"); The general idea is: 1. Find all pages that you want to exclude. 2. Find ALL the pages but filter out the pages found in #1. Thoughts: You can use filter() method for this by finding all the pages you need first then filtering out what you don't want but this somehow messes up pagination by default as what I mentioned in the original post. BUT, ryan did say you can use setTotal() and setLimit() methods on the PageArray but I haven't tried it since I'd already found a solution but then was too lazy to rewrite

There were a few textpattern plugins released via 'ransom' - a custom fields one too if I remember correctly (hilarious!) - which went along the lines of 'I need this much money and I'll release it'. Personally if I was putting money towards module development I'd have no problem letting everyone get the benefit of it. I'm still blown away by not only the generosity of Ryan releasing ProcessWire but the dozens of module devs here that have made my life as site builder that much easier. Perhaps another approach would be to have a PayPal donate button (or similar) in the existing modules section where folk can send their cash to.

Here is a new module for ProcessWire 2.1 that imports pages from a CSV file. By default it will create new pages from data in the CSV file, but you can also configure it to modify existing pages too (existing pages that have the same title). Please give it a try and let me know how it works for you and if you run into any issues with it. This module is something I've had in the works for awhile, and regularly use on various projects, so figured I should clean it up a bit and release it. Also attached are a couple screenshots from it. How to Install: 1. Download from: https://github.com/r.../ImportPagesCSV 2. Place the file ImportPagesCSV.module in your /site/modules/ directory. 3. In ProcessWire admin, click to 'Modules' and 'Check for new modules'. 4. Click 'install' next to the 'Import Pages CSV' module (under heading 'Import'). Following that, you'll see a new menu option for this module on your Admin > Setup menu. Supported field types for importing:* PageTitle Text Textarea (including normal or TinyMCE) Integer Float Email URL Checkbox (single) *I'll be adding support for multi-value, page-reference and file-based Fieldtypes in a future version.

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

kickstarter There are several developers here that contribute a lot, working for fun and sharing knowledge giving us wonderful modules. But next to the respect they get, it would be nice we pay for the Cola & Pizza's they need while programming. ( Can hungry programmers code to ? ) For me as individual I won't/can't pay a decent price for good software, but with 10 members things change. Say: If an developer needs $750,- before starting the write. (I'ts only €56,-- per person, not reached, money back ) Then: Every person who paid, can download the finished module. After 3 months: The module becomes normal opensource, available for everyone. Maybe Ryan can choose some privileged developers that are capable of building quality modules. What do you think ?

Mine reads 2.3.3...Not sure whether you need to clear some cache, etc? Try this on a template file: echo "<h3>The installed PW Version is: <strong>{$config->version}</strong></h3><hr>"; //system version That will tell you the PW version installed.

there is also a short way to write it in PHP. Maybe you know it from JS: $image = $page->images->first(); $img = ($image->width >= $image->height) ? $image->width(900) : $image->height(900); echo "<img src='{$img->url}' alt=''>";

OK, I just have deleted my fork complete, and then GitHub has created a new one, like the first time. That new one I was able to modify and send as a PullRequest. So, yes I know, - that's not the recommended way to do it, but I need to go to bed and want it solved before.

Big tnx @owzim!

No way thats not possible !!! Very impressive !!! Big tnx @Horst

I think we are in about 100 000 pages with one site. Mostly because it uses discussions module where each post is a page and I imported all the old discussions there on site migration. Everything runs smoothly, running on company VPS with about 20 other PW sites. We had one performance problem with search that was limited to one rootParent branch, but it was quickly tweaked by Ryan. So no worries with "hundreds of thousands". Anyone has millions yet? How about test site if not real stuff yet?

Don't forget that the admin side has a search feature a swell, so administrators can use that to find the exact baby they want. Another option might be to create the alphabet as part of the page tree, and add babies as children of the correct letter. Example: mothership/babies/x/xavier If that structure isn't desirable for the actual front-end URLs, you don't necessarily have to use them - you could also have the home template accept "URL segments", and load the required baby from that using the API.

That's perfect, thank you! I'm fairly new to PHP (more of a JS knowledge) so these kind of things are still new to me. But very useful to learn. So thanks! b

I love this.

Hi Peter, Indeed. Something like that could be a good option too. Even some of the smallest of modules would save me more than $2.50 in time over the span of a month. - Marty

I think I've been getting confused - it must have been in a private beta earlier this year and I'm not as blind as I thought. The actual launch appears to have been the 15th of August so I don't feel so bad now: https://stripe.com/blog/introducing-stripe-uk I think the only drawback is that they don't offer the ability to transfer to your bank account on demand, favouring a 7 day automatic rolling payment schedule (to be honest having the money in their system a few days longer is probably one of the ways they make a profit from the system aside from the fees - which are 1% lower than PayPal). I don't think that that is really a huge deal though as there is usually some waiting period for transfers with most merchants and in this case you can know in advance what day each week money will land in your bank. The fact that they've opened a London office and are working with other European countries as well as Australia also shows their commitment to going global and the fact that they are likely to be around a while. I think they've got the potential to take quite a slice of the market at this rate, or certainly stir it up and kick a few bums into action in terms of the more archaic merchants out there.

Dear Marty, I like the idea of donating to Ryan's efforts. With PayPal donations / subscriptions, it's very easy. There is also power in numbers, i.e. if a hundred people donate $2.50 a month, that's $250 per month, which is better than a sharp stick in the eye. Of course, many can donate more than $2.50 a month, but in tough economic times, it's good to give people the option of a "micro-donation", rather than the choice of "donate $50 or nothing." I have an example of this process on my website, here: http://significatojournal.com/patron At the bottom of the page, a person can choose various levels of monthly donations, or choose to make a one-time donation, as a "Renaissance Patron." I think that if Ryan set up something like that, many of us here would donate at least $2.50 a month. Peter

As I can see both sides and maybe some more facettes, I like this: taken from here, the answer to question number 5)

Why not the people who are sponsoring just do so out of interest to see the project flourish? I agree with Owzim, a big part of Open Source is getting it thoroughly tested and transparent. If the module was right, I'd be happy to contribute and would be OK with others benefitting.

Mary, I suppose you've read this in the docs? http://processwire.com/api/modules/multi-site-support/ Your Alternative 2: would mean potentially 1000 databases... ? *shudder* Unless you mean multiple sites from the same database?

Yes, there is a hardcoded max of 999 for page numbering (defined here). Built-in pager does give you pagination links further than that, but they only work for numbers less than a thousand. You just have to take care of the rare occasions when for example a search would give more than (999 * pages_per_result_page) results. As the guys are saying in that other thread (I'm sloow today). But that's just how far the page numbering will go and has nothing to do with how many pages ProcessWire is capable of handling without any problem. We've got a site with 30000 pages and another one with 15000 pages. The bigger one is running nicely even without any kind of caching at the moment - and there is a bit more complex than just trivial search involved there. And no performance problems with the smaller one either, just to be clear =). There are even bigger PW sites around I'm sure. I think at least Antti has one in his hands and most probably others do as well. Sure one has to think a bit how to approach things to keep everything nice and fast. But it doesn't require any magic to stay on that road. Common sense and some testing along the way to see little things aren't piling up and you should be fine. In my opinion anyway. And I'm talking about the amount of pages here, not making any statement on whether to have several small sites in one install or not.

Would you want pagination to stretch that far? Doesn't sound great for usability to have a user click <Next> hundreds of times... Or am I missing something?

PWired...I think you misunderstand...This is not about limits to how many pages PW can handle...this is about pagination. Big difference It's right there in the post Arjen linked to...scroll down to Teppo's post...or see the code below: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageView.module#L32 https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageView.module#L264 Btw, Wanze has built a PW site with about 100K+ pages... Edited for clarity...

What I can see as problematic here is, that modules grow an flourish just because very early versions are shared from the beginning making them open to suggestions and bug reports, which is a very important aspect of open source. If you limit the audience just to the people who pay, modules may not become as awesome and user friendly, at least not in early stages. That's just a thought. In general I like the idea very much.

This looks fantastic Ryan, a real great addition to the backend and a huge thank you to Antti also for sponsoring this project. I think we need more sponsors if this is the end result!

I think it's more that so many of us hadn't thought about this before but can instantly see the benefits ryan, not that we've necessarily all been waiting for it before now. I think that's testament to how well it's been implemented.

Since Pagefile is a single file field you would use delete(). You're not dealing with a WireArray then but with the page file itself. Or a $page->file = ""; $page->save(); would also do it maybe. Just wanted to add that if you (or need to) first $page->of(false) (setOutputFormatting), even a single file field will be an WireArray, so deleteAll() should then also work.

Hey Ryan, Thnx for the answer, I posted the question and forgot to check (was hopeing for a mail :-s) Anyway we found a some-what other solution, we just dump the DB to our local-DB-server that we work, and put all info except the assets/files and assets/sessions in our git repo. With the script to import the DB we also copy the info from assets/files from the live location. This way our clients can work with the live enviroment, we can import all the live-data to our local computers and work at it this way. Only two 'real' downsides are that 'stuff' that gets thrown away in the live enviroment in assets/files isn;t deleted localy and the fact that if you change something in your local database / back-end you need to 'redo' that or do it on the live enviroment and then dump the DB back (or we can also dump our local DB to the live enviroment, but you need to be super-carefull with that offcourse)

It is possible to define a maximum number of allowed pixel (like Megapixel) somehow and it can be checked before loading the imagefile into memory with the getimagesize function: $size = getimagesize($filename); $maxPix = $size[0] * $size[1];

Chances are that the CSV file is not UTF-8? If you can confirm that it is in fact UTF-8, no-BOM, PM me a copy of the CSV file and I can give it a try here to isolate the issue.

This is great! Looking forward to this Ryan!

Thanks for pointing me in the right direction Ryan. Although it took a bit of figuring tinkering around since I initially got this error "Field must be in fieldgroup context before its context can be saved" for those passing through this thread, finally got the following code working correctly: //add the field to the template first $mytemplate = wire('templates')->get('mytemplate'); $mytemplate->fieldgroup-add('roles'); $mytemplate->fieldgroup->save(); //-- we now *override* the default label and description to suit our template --// $field = $mytemplate->fieldgroup->getField('roles', true); //!IMPORTANT: set 2nd parameter to true to get the field in the context of the fieldgroup. //note: I don't really understand what "in the context of.." means though $field->label = 'Select roles'; $field->description = 'Select the roles that should receive notifications.'; //now save! wire('fields')->saveFieldgroupContext($field, $template->fieldgroup); For those who want to go through core, the hints are in wire/modules/Process/ProcessField/ProcessField.module

@ceberlin Lots of modules only get activated if you want. Other modules have an early escape. (See textformatter example from Teppo's site). Then lots of modules use hooks (so you don't need duplication in your templates & it is portable). And then there are modules like ImportPagesCSV that is needed only once most of the time. After use, just de-install them. If you use modules wise, I don't see to much drawbacks from using them.

The creation process really isn't a problem with the tools Ryan mentioned. Especially for stuff like country lists i think it's really powerful to use pages. Easy to maintain; if a country name changes (yes, this does happen every once in a while) you just update that page and everything using it will always be in sync, be it your select options or other places you used the country pages. Maybe you would want to add some additional info, like a country flag or multilingual country names. This stuff all becomes easy and transparent if you use pages. What if later on you would also want to support regions and/or continents? Easy to implement when everything is pages.

…Until you do it from the API, Batcher or ImportPagesCSV.

Ryan, I'm really impressed, amazed at your level of productivity, responsiveness (and generosity)!