Leaderboard

Already in the works and making good progress ? Great 2 posts, @Robin S! Thank you for all your contributions and always positive and helpful comments. It's really great having you here! ?

I tend to run all my posts through an online spell checker, just to catch any silly mistakes before they go online. Usually it does a decent job, but sometimes it doesn't quite get the context right. Today's suggestions included – among other more-or-less sensible options – "Wiretap" (for WireHttp), and "Bodybuilder" (for FormBuilder). Then again: since we already have "Admin on Steroids", perhaps a Pro-module called Bodybuilder is just the next logical step? ?

I think that's a brilliant idea, so definitely going to my todo list – thanks for the suggestion! ?

After forgetting the class name of the wonderful AdminPageFieldEditLinks module for what feels like the 100th time I decided I needed to give my failing memory a helping hand... Autocomplete Module Class Name Provides class name autocomplete suggestions for the "Add Module From Directory" and "Add Module From URL" fields at Modules > New. Requires ProcessWire >= v3.0.16. Screencast Installation Install the Autocomplete Module Class Name module. Configuration Add Module From Directory Choose the type of autocomplete suggestions list: "Module class names from directory" or "Custom list of module class names". The latter could be useful if you regularly install some modules and would prefer a shorter list of autocomplete suggestions. The list of class names in the modules directory is generated when the Autocomplete Module Class Name module is installed. It doesn't update automatically (because the retrieval of the class names is quite slow), but you can use the button underneath when you want to retrieve an updated list of class names from the directory. Add Module From URL If you want to see autocomplete suggestions for the "Add Module From URL" field then enter them in the following format: [autocomplete suggestion] > [module ZIP url] Example: RepeaterImages > https://github.com/Toutouwai/RepeaterImages/archive/master.zip Awesomplete options The "fuzzy search" option uses custom filter and item functions for Awesomplete so that the characters you type just have to exist in the autocomplete suggestion item and occur after preceding matches but do not need to be contiguous. Uncheck this option if you prefer the standard Awesomplete matching. Custom settings for Awesomplete can be entered in the "Awesomplete options" field if needed. See the Awesomplete documentation for more information. https://github.com/Toutouwai/AutocompleteModuleClassName https://modules.processwire.com/modules/autocomplete-module-class-name/

@stanoliver Great ? Array elements that are declared without a key are implicitly numeric in PHP, so the following declarations are equivalent: $colors = [ 'red', 'green', 'blue', ]; $colors = [ 0 => 'red', 1 => 'green', 2 => 'blue', ]; You can even mix numerical and associative arrays, but that only leads to confusion in my opinion, so I would avoid it.

@MoritzLost Thanks a lot it works! I was just not aware of the fact that I could treat "everything" as an indexed/numerical array.

These were for MarkupMenu, an aria-label within template strings that I wanted to be translatable ? Not sure if I've ever tried this before either; didn't occur to me that it wouldn't be possible, but makes sense now. Anyway, the separate config file idea actually works quite nicely for me in this case. Ready.php would've been a good solution as well ?

Just to clarify, which part don't you understand? The $data object is an associative array, so you can access the colors using the respective key: $colors = $page->meta('myData')['colors']; // ['red', 'green', 'blue'] The $colors array is an indexed / numerical array (i.e. it's not associativ), so you can access each of the colors using the numerical key of the position you want: $colors = $page->meta('myData')['colors']; // ['red', 'green', 'blue'] echo $colors[0]; // red echo $colors[2]; // blue Or are you stuck on how to use the meta method itself?

Don't see anything bad with that. What strings do you want to be translatable? Never needed translatable strings in config ? Would ready.php be too late? Or a separate module's init()? You could also set $config->... = $this->_(...); there

Perhaps using something like $str = function { return if (function_exists('__')) { return __('key'); } ), or something along these lines? Just a quick idea from mobile ?

@horst Yeah, I just went and reread the ProFields page which I should have done earlier. I'll probably need to resurrect this thread later, but I think I have enough of plan now to start experimenting. Thanks again for the reinforcement!

Yes it does. For example I often use the Textareas ProField to collect a lot of small textpieces in separate inputfields, but it creates only a single table in DB. On the screenshot you see two db fields / tables, contact and map:

I'm not sure your questions, though. For dynamic documents such as tickets, enquiries etc, I always use this format for page name to make it easier: date("ymd-His")."-".$user->id."-"custom-name or updated version it will avoid a clash page names and easy to find them for future use.

On a slightly serious note though: There are CKEditor plugins for spellchecking. I think AOS has one of those (SCAYT) built-in. It's quite handy. Among other things, you can choose to ignore a suggestion, or add your own phrases to the dictionary. (Of course, this won't work with plain-text fields)

Not sure about the blogging modules, as I don‘t know them. For me this looks like a good fit for urlsegments. Look up the API docs for it, I‘m on mobile. Using this, each of your docs template additionally need a date field, if the user should be able to specify the version date manually. If it should be assigned in an automated way, you can use the page creation_date, (or modified one).

I've been working on this a looks like it WILL require a change, as it now requires you update your payment journey to use PaymentIntentions, e.g. setting a intent to pay at the beginning of any payment checkout before actually requesting card information, address, email etc etc... I'm currently having to do this for my clients and adding support for Stripe Elements. Love this to be robust butI'm simply not a very good backend dev so muddling through it. Will release what I have when it's done hopefully in a week.

Just add this plugin: https://ckeditor.com/cke4/addon/wordcount Or use AdminOnSteroids module which comtains this plugin.

I have no experience with this Tribe events thing, so can't speak for that, but for the bulk of the content I'd recommend skipping the database export idea and going with the built-in REST API. While the REST API has its quirks, going directly to database for exports is going to be a major pain in the a*s in comparison. Not entirely unlike exporting ProcessWire content with raw SQL... ? It would be best to have a separate copy of the site at hand first, but after that it's basically as simple as installing the ACF to REST API plugin (which adds ACF field data to the REST API results) – and of course making sure that the REST API is enabled in the first place. You should be able to query and export all your pages, articles, and any custom post types with this method. Once you have the data, importing it to ProcessWire is going to be a breeze. (Note: based on some quick googling the Tribe events plugin also provides REST API support. I haven't used this, but it looks promising.) Also, in case that idea won't pan out, you can always rely on existing solutions, such as WP All Export (which provides a GUI for exporting content, including ACF data). Admittedly I haven't worked with this plugin before, but it's the companion plugin for WP All Import, the de facto standard plugin solution for complex imports. WP All Import is a bit of a monster and can feel clunky (hence devs often prefer custom imports for long-running, often-used, scheduled stuff), but for one-off cases it's a really handy tool. -- Edit: in case anyone is wondering, the WP REST API was first announced on June 17th 2013, which would be a week or so after Ryan started this thread. It didn't make it's way into the core until 2015, and even then it was for a very long time considered "a work in progress". It's been more than five years since this thread was started, so it shouldn't come as a big surprise that some things have changed ?

https://github.com/processwire/processwire/pulls There are still pull requests from 2016... Please @ryan could you take a look at the PR repository just like you did with the issues over the last weeks? There are many simple ones that really just need to be merged (like https://github.com/processwire/processwire/pull/143/commits/80aa0ac2e6383b32a4d0a932d5bec78a8fb5bf14 ). It's really frustrating if one tries to contribute and this contributions just seem to be ignored ?

Do you do design websites as well as develop them? If you do then my experience has been that there is plenty of work available from businesses and organisations who care about and understand the benefits of high-quality bespoke design and development. Yes, there are many out there who think that a $40 Wordpress theme is good enough and don't want to pay above the minimum - if job satisfaction is important to you, you don't want those people as clients. You'll hate the client, hate the finished website, and end up hating your job. You say you also work in the charity sector - I think that is a good sector to target as a specialisation and maybe you can make use of your contacts there to get started. Most of my clients are not-for-profits, mainly environmental organisations. I have found them to be excellent organisations to work with - friendly, sensible people, happy to take advice and willing to let you get on and do your work without a lot of interference. Another benefit is that these organisations often fund their projects from grants. This makes them less price-sensitive. To be clear, I'm not talking about gouging them on price - just that you can quote a fair price and they base their funding application on that and there's no grizzling and bargaining over cost like you can get in the for-profit sector. I live/work in the middle-of-nowhere rural New Zealand, I have never advertised or done any kind of promotion, and have been fortunate enough to always have a steady stream of work. And believe it or not, in the ten years I have been doing web work I have never had a client request a Wordpress site. I think positive word-of-mouth is key, and the great thing about it is that good people tend to know other good people so you generally avoid those Clients From Hell. To get good word of mouth you need to exceed expectations - set yourself high standards, have meticulous attention to detail, and deliver that bit extra. Best of luck with your career!

TLDR: Buy ProFields I don't understand why that brief list of fields is a "mess and a nightmare". I know the general advice given is to reuse fields where possible but I think people sometimes take this suggestion a bit too seriously. Create the fields you need and forget stressing about whether you have perfectly optimised the reuse of fields. If you have less than, say, 100 fields in your site you really have nothing to worry about. I think I saw a post recently where Lost Kobrakai was talking about a site of his with over 800 fields. But ProFields... You mention client editing experience, so I take that to mean you (like me) earn an income from developing websites. With that in mind here are some things to consider when making your decision whether or not to purchase ProFields... Have you thought about how lucky we developers are that we can earn an income with virtually no overhead costs? With so much fantastic open-source software made available to us at no cost we are in a very fortunate position. We could design and develop websites entirely with free software if we so choose. Hell, if we wanted we could go to the landfill and probably pick up a free old computer that would be perfectly adequate to develop a website on. Now think about the carpenters and dentists and all those other professions that must purchase real physical tools (that wear out) in order to earn a living. £100 doesn't go very far if you need to buy a table saw. On the topic of open-source, think about what Mr Ryan Cramer has provided us with in ProcessWire. People with his level of skill do not need to be contributing their time for free to open-source projects - they are in very high demand for all kinds of lucrative work. Purchasing a Pro module from Ryan is a way to show appreciation for the generous work he puts into PW. PW is not just great free software, it is great software full-stop. You mention previously having worked with Drupal and Craft CMS. Time is money, so think of all the money you have saved by the quick development workflow that PW allows vs Drupal. And Craft CMS costs USD$299 per website and is still not as powerful as the PW core. Ryan's Pro modules are insanely good value for money. The price that you can purchase a dev license that allows you unlimited use of the modules is more than reasonable. For comparison, here is one of the most popular addons for Concrete5: http://www.concrete5.org/marketplace/addons/block-designer-pro There is no unlimited license, and a license for 5 installations costs USD$276.25. And it requires "Block Designer" so that's another USD$120 for 5 installations, bringing the cost to USD$396.25. I haven't used it but it looks like it is basically the equivalent of Repeater Matrix. But probably not as elegant. And with ProFields you get another four modules bundled in. For unlimited use. For USD$129. Hope this has helped make the decision a little easier.