adrian

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

Actually, it does extend Inputfield: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module#L15 but since you are using it from a different module it doesn't know to autoload these because they are not in the same folder as your new module. I think you might need to share the code for your new module so we can see where things might be going wrong.

I did a couple of WP sites back in the day and this was my experience - except that I found it was never a perfect fit, so it was never great I think if you are happy quoting a budget price and saying no to those little changes then you can get by with WP, but I am always embarrassed to say I can't make a change that the client wants and when WP makes these changes so hard, I just don't think it is worth it. I actually find development of even simple sites easier and quicker with PW.

Often you just need to do this: public function init() { parent::init(); } The parent::init() is the trick. Here is a comprehensive discussion on it: https://processwire.com/talk/topic/1416-inputfieldmodule-doesnt-autoload-their-jscss/

Those php notices shouldn't prevent the module from working. Admittedly they should be fixed, but are you sure that the module is no longer working? If you disable debug mode you shouldn't see the errors.