adrian

Why not ? Seriously though - the fact that PW is targeted more to developers than many other systems was one of the key reasons I got interested in it. I didn't want something that was fully automated, drag 'n' drop - they can only take you so far before you end up screaming and just wanting to punch out a few lines of code to get done what you want. There are CMSs that fit along the entire spectrum from fully automated to very code centric, and that is a good thing - we can find the position along that continuum that suits us best - for me, that spot is PW. I know that it will probably never be the sexiest option out there, but it gets the job done in a way more efficient manner for how I like to work! Also, as others have pointed out, PW doesn't really require much initial coding knowledge - just a little willingness to learn. Sure, you won't be creating the next social network with it unless you have some serious coding skills, but you can certainly churn out a website for your cat without too much effort so long as you are not initially scared off. There has been some discussion here about making PW more non-dev friendly and it would certainly be possible to build something on top of it, but personally I think that would just lower the bar of the people using it - btw, this is not meant to sound snobbish - I just like the current user base

You can simply double-click on the first one and it will mark all images for deletion.

Just committed a new version which supports Page fields. Like all other field types (except textArea which has other options), check the Faker property under the Auto Content Options for the page field. If there is no automatic match, or no manually entered property, it will fallback to 1 to 3 word lorem ipsum titles. This became pretty complex pretty quickly because I wanted to support output of all fields from the faked page fields, so please test and let me know if you have any problems.

There are arguments both for and against have many contributors on a project - I have been involved with OS projects at both ends of the spectrum and while it may appear to be a limitation on the surface to have less contributors, the advantage is that with all code changes going through Ryan we can be sure that the high standard he has set is being maintained. There are many more than 4 contributors to the core - most of those with the STAFF badge have made contributions (and probably many more without) and you will likely see their name/handle mentioned in the core code on the features they have contributed to. If you are worried that only one core developer will mean slower progress with adding of new features, I think the weekly blog posts and GH commits show that this is not an issue! - what other CMS is getting as many cool new features as PW on a weekly basis? Who knows whether this will change in the future for PW, and certainly no software will live forever, but for the relevant future timeframe there are plenty of users around here who will want to keep this project progressing should anything happen to Ryan (either physically or with changes to his priorities), but I know that somewhere in these forums he committed to working on PW for the rest of his career.

teppo, you mentioned that it would be cool to be able to automatically generate pages to easily test scalability, so this question is directed mostly to you! With the new automatic test pages feature, I am storing the IDs of the created pages in the module's data field - this is so I can delete them all as requested. The module data field a MYSQL text field with a limit of 65,535 bytes. Based on my calculations, with UTF-8 numeric characters (0-9) being one byte each and PW page IDs having a minimum of 4 characters, eg: 1001, the most I will be able to store is 16383 page IDs. Of course when you get to that many pages, the page IDs will contain 5 characters, eg, 12005, which brings the number down to 13107 pages. So, is 13000 pages enough for most of your scalability testing, or can you envision wanting to test more than that? I am guessing it will be fine, but thought I should ask On another note, I just implemented my idea for only deleting auto generated pages if their status is still locked, which means it is now possible to unlock a page and edit it with real content and know that it won't be deleted when you delete all auto pages. I am still not convinced that using the locked status is the best approach here - definitely open to ideas!

Ok guys - the module now supports batch creation of testing pages. There is a one click option to delete all these pages once you are done. This is also called when the module is uninstalled, although thinking about this some more, I might need to check to see if there are any fields with actual content before deleting as I can see someone repurposing one/several of these "testing" pages for actual content during development. I'll look into this more tomorrow. EDIT: I just added "locked" status to all auto generated pages - hopefully this is enough protection against someone trying to add real content to these pages - any thoughts? Maybe I should check to see if the locked status has been removed when deleting the pages? That way superusers could remove the lock and edit if they really wanted to and know that the page wouldn't be deleted - any thoughts?

No worries - not taking suggestions as pressure at all I think the idea of automatic page generation - I am just not sure the best approach yet. Maybe it's a simple matter of maintaining an array of page IDs that are created so that I can offer a "Cleanup all automatically created pages" button, and obviously also run this cleanup when the module is uninstalled. Now to determine the best way to create the pages - should the "create tool" be added to the settings tab of each page? Or maybe it should be part of the main module config settings and do as Raymond suggested - choose parent, template, and number of pages to create. Maybe it's actually pretty simple to handle. Any further thoughts before I dive in?

I have just committed a new version that makes use of the Faker library (https://github.com/fzaninotto/Faker) - thanks to LostKobrakai for pointing that one out. I have included the library with this module for the speed benefits, compared to calling the API. Faker allows for automatically generating a wide variety of custom content targeted to be relevant to each particular field. The module attempts to match each field name to a Faker property automatically, but you can also link fields to specific ones if needed. For example, if you have a field named: "last_name" it will match the Faker "lastName" property and it will output things like "Smith", "Jones" etc. I have also added a module wide config option for setting the locale. This will determine the content that is generated. For example, people's names, street addresses, etc will be relevant to the locale. At the moment I am still using the loremipsum.net API for textarea content because I really like all the styling/content options which are not available in Faker, but this may change in a future iteration of this module. I may also add Faker to Integer/Float etc fields to allow for more flexibility. There is also initial support for the MapMarker field. Please test this new version and let me know if you have any suggestions.

@LostKobrakai - have you used the microservice? I started setting up support for the MapMarker fieldtype, but the response time is just too long. I have tried both curl and get_file_contents. Even calling it directly in the browser is slow - check out: http://faker.hook.io/?property=address.streetAddress&locale=en And I would have to call at a minimum three times for streetAddress, city, country I think I am less worried about getting different random data - if the API call is going to be slow, then I think I would rather keep things fast and just define standard default automatic values. Any better experience at your end? Or ideas for another service?

Hi @MarcV and welcome to the forums! A few comments. It's not a good idea to overwrite the $page variable because then the current page will refer to the page with ID#1004. Most of us use $p when referencing another page. You are not saving the page, so the changes are not sticking, but then you probably don't want them to stick because then they would affect all users. Can't you simply add a conditional at the top of template file for page#1004 that says to throw a 404 (throw new Wire404Exception();) if the page id is 1004 and the user's hostname is xxxxx? Does that help?

Thanks for the thoughts Raymond! Are you are talking about dummy pages that are not actually in the database, but are only rendered on the front-end? That sounds intriguing to me, and I think might be a cool addition to this module - will have to think more about how best to implement. Or, are you talking about adding real pages? I think it might be confusing the role of this module to get into generating pages. I think perhaps what I would recommend is using the "Add" mode of BatchChildEditor to create the pages, then if you have AutoContent installed, the dummy content will be added when the pages are rendered. I could potentially add an "Auto Add" mode to BatchChildEditor which created the x number of pages with random names to make this even quicker. The other reason I wouldn't want to add pages with AutoContent is the subsequent need to delete once you no longer need the dummy pages. BatchChildEditor makes this quick and easy.

@ZGD - you are not the first to report this: https://processwire.com/talk/topic/6102-batch-child-editor/?p=97690 I have my PHP settings (memory, execution time, etc) high enough that I haven't seen this, so the quick fix is to make those adjustments at your end. I do however have it on my list to modify the export script so it works in batches so this won't be necessary - thanks for the reminder!

Thanks for that - should come in very handy, especially for the address components of the MapMarker fieldtype.

Not sure your exact needs, but this module might also be of use: http://modules.processwire.com/modules/fieldtype-select-ext-option/ - it allows you to generate a dropdown/radio/checkboxes etc from an external database table.

Hi everyone, This is an early (but mostly functional) version of a module that I am experimenting with for automatically populating all empty fields on a page. It is designed for use during site development and should be uninstalled once the site is live. https://github.com/adrianbj/AutoContent (anyone have an idea for a better name?) It currently supports the following field types: Text - outputs "This is an example Field Label", where "Field Label" is the label for the field Textarea (RTE and plain) - configurable content from http://loripsum.net/ and embedded images from http://lorempixel.com Datetime - honors output formatting and returns random date/time with configurable min/max datetime Integer - honors min and max settings Float - honors min, max, precision settings URL - returns a random URL Email - returns a random email address Image - you can specify image category (people, nature, business, etc), and the range for min/max number of images to generate. Page - creates runtime selected child page content for output - not well tested yet. MapMarker - not well tested yet! I will be adding support for Profields and other selected 3rd party fieldtypes shortly. Highly configurable content is provided by: http://loripsum.net/ http://lorempixel.com/ https://github.com/fzaninotto/Faker Generated content can be localized to your region - very handy for addresses, people's names, phone numbers etc: Many fieldtypes are configurable via the Input tab on the field's config settings, eg: Textarea: Text: Images: Datetime: In general I am designing this to work with minimal/no configuration so you can install and have all fields on all pages on your site immediately populated for testing layout and styling without the need for manually adding dummy content. There is also a dummy page batch creator and deletor (automatically tracks and deletes just the dummy pages) available from the module config settings page. Please let me know if you think you will find this useful - trying to get an idea of how much time to put into support for additional field types.

Thanks horst - I am interested in putting some time into this - will have to see how my commitments pan out. I do think I could make significant use of it though, so maybe can justify it sooner than later. One additional idea would be to allow for injecting "ng-attr-fill" into the svg code for styling with angularjs expressions - I know, getting a little carried away

Another idea - what about storing the icon code in the db? You could maybe even have a module config tool for adding new icons - an upload field that takes the SVG from the uploaded file, and encodes it so it's ready for storage and usage in the module? Or maybe write the encoded content back to the file in the filesystem?

Looks awesome horst! What do you think about maybe defining the icons in a different file? Either for all the icons, or an optional, additional file that each developer can maintain for their own icons? I actually think two separate files might be nice - one in your module's directory so that we can easily contribute new icons via PRs, and the another one that sits under /assets/svg-icons/ that we can maintain ourselves.

If you want to stick with a password field you can do this: if($page->password->matches($input->post->pass)){

It looks like you are just wanting to require just a password, and not a username as well? And it looks like there is only one valid password per page? If so, then just use a text field so you can match them directly (since a text field won't be encrypted). Alternatively, you could use: https://processwire.com/talk/topic/8387-page-protector/ - you'll likely want to use the Login Template option. This will require a username and password, so it may be more than you need.

I haven't investigated very far, but I am seeing an array vs string error due to: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/PageFinder.php#L1182 There is a note in that file that I think might be related: // TODO Make native fields and path/url multi-field and multi-value aware So it is possible that support is planned but hasn't been implemented yet.

This should do the trick: $pages->find("(path=/news/),(path=/about/)"); And here is some more info on "OR group" selectors: https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=64049 Or, depending on your needs, you could maybe match by name rather than path: $pages->find("name=news|about"); Of course there is the chance that another page with name "news" or "about" may get created elsewhere in the page tree, so you could help mitigate this by supplying a parent of home as well: $pages->find("parent=/, name=news|about"); I am curious though what is wrong with using the ID - seems like it might be the safest option? Just be sure to add a comment above the selector so you know what they are referring to.

It was first base Ryan, second base Ryan, third base Ryan ...

@felix and everyone I have made some initial adjustments to make this module more versatile. It now has two config fields for setting up the JS video player of your choice and the player template code. By default it comes configured to use MediaElementJS, but you can easily change to VideoJS, JW Player, Plyr.io or whatever you prefer. Once configured all you need to do is: echo $page->video->play; With the default setup, you only need to upload an MP4 and it will work on all browsers/devices. I might potentially make it possible to also upload a WebM version so that you can play with HTML5 in all browsers/devices without the need for a fallback flash player on FF/Chrome, but I'll see if people really have a need for this. I would still like to make several refinements, but if anyone tests this version, please let me know how it goes.

Hi Zahari, This module should be getting a facelift soon - I'll be getting rid of the Sublime player and setting up mediaelementjs by default, but also making it very easy to switch to VideoJS, Plyr, JW Player - whatever you want really. I haven't installed ffmpeg-php on a Mac - only on my Linux box, but do these instructions help: https://www.drupal.org/node/1464236