adrian

Thanks for clarifying that. I just committed an updated that adds a new "Excluded Pages" option to the module's config section, so you can add as many pages to this as you want. Interestingly while testing, I noticed that for non-multilanguage sites you actually have to have the settings tab disabled to even get the name of the homepage to change with this module at all because in most cases it uses JS to change the name and the name field isn't available unless Settings is disabled. Anyway, please let me know if this new option takes care of things at your end.

If it wasn't for mobile app development I probably never would have made the switch to Mac, but now that I have, I probably won't go back, just because of the UNIX base and also because I am now comfortable with the toolset I am working with. That doesn't mean I am thrilled by Macs - in my mind they are just a different set of problems

Hi @gebeer - I can certainly add an option like that, but I am curious about the behavior you are seeing - is it a multi-language issue? When I change the title of the homepage, the path to it and all child pages does not change because the name of the home page is never used in the URL. Maybe I should add a checkbox to the Settings tab of all pages to disable name changes when checked?

Ryan has been notified of this thread, so hopefully he will be able to give you an answer shortly. Although I see that you mention "ImageExtra" - is the problem only related to sites with this module?

This seems to work on all inputfields for me: $this->addHookBefore('Inputfield::render', function($event) { $field = $event->object; $field->setAttribute('ng-model', $field->name); }); EDIT: Oops - well and truly beaten Can't afford to sidetracked in the middle of replying with when @LostKobrakai is online!

From your post it sounds to me like you are talking about migrating content from one PW site to another - is that correct? If so, it should simply be a matter of migrating template files and the DB. If however, you are talking about migrating a WP site to PW, we do have a migration tool: https://github.com/NicoKnoll/MigratorWordpress

Hi @mr-fan, I think those notices were just a side effect of upgrading from an older version of BCE, but regardless I just committed some changes that should fix them - thanks! Please let me know if you come across any others. PS - thanks for all your support for this module - both testing and promoting it in other threads!

I haven't used them, but is pwired maybe referring to CSS image filters: https://css-tricks.com/almanac/properties/f/filter/

Absolutely no apology necessary - I am honored that you featured it and completely agree that early attention and testing is a great benefit to myself and any potential users, so thank you for including it and for PW weekly and everything else you do for PW!

I thought I had better make some improvements after teppo's very generous, but slightly premature publicity in PW weekly this morning I really wanted the images working better, so you can now specify how many images to randomly generate. Also, images are now cached so even though the first view of a page may be a little slow (while images are grabbed), subsequents loads will be as fast as normal. I will be plugging away at this module as I find inspiration for new fieldtype support, and snippets of time when procrastinating, but please let me know if you have any specific requirements for auto content generation.

Another small update that swaps out placeholder.it for lorempixel which means you can now have real images and you can even configure from their categories to tailor the images to your site: Abstract Animals Business Cats (although I almost want to remove this option) City Fashion Food Nature Nightlife People Sports Technics Transport I also fixed the image output - I had forgotten to return a pageimage, rather than a path. EDIT: because this now returns a pageimage, the images are copied to the page's files folder so I have added a cleanup routine to remove all images when the module is uninstalled. I thought I had previously created a pageimage at runtime without it being added to the assets/files folders, but for reason I don't seem to be able to do that - did I imagine that?

Macrura - very cool - I hadn't thought of using it that way and will actually need similar buttons in an upcoming project so might just consider using this module to do it! The trouble I am having with PW lately is that there are so many great new ways of doing things and it's hard to keep track of them all

You should tell Mark Z. about this - he could have saved himself a fortune on hiring expensive developers - he could have gone with the local Mom and Pop web designers. PS I assume you are kidding

I am glad that you appreciate my answers and I am happy to help, but as diogo pointed out, all this info is already available in the forums. One thing that might really help you to learn is to use google to search these forums - the built-in search for IP.Board forums is pretty useless. On the overhead of using pages - that really isn't true in most situations. And Profields is a multifaceted product, but the Table field component definitely reduces the number of pages - everything for a field instance is stored in one database table. Can you point us to any CMS that could run Facebook? They have created there own version of PHP to handle their needs!

Actually the pages approach of PW scales incredibly well and is actually one of its most useful models allowing so much flexibility. BUT, in some cases if you don't need the flexibility of the pages approach you can make use of FieldtypeOptions to categorize things. You could also use Profields Table if it better suits your needs. For quickly populating pages for use as categories, here are some helpful modules: http://modules.processwire.com/modules/process-page-field-select-creator/ http://modules.processwire.com/modules/batch-child-editor/ http://modules.processwire.com/modules/process-batcher/

Beautiful!

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?