Leaderboard

Hi neonwired, so you added the live domain to the config.php like this, right? $config->httpHosts = array('www.livedomain.tld', 'livedomain.tld');

Some people think cucumbers taste better pickled.

Update 2. Wrapping Thanks! Having a look where this wrapper comes from, I found another hook which fits the module needs much better. `<div class="InputfieldImageEdit__additional"></div>` is part of the core (wire/modules/Inputfield/InputfieldImage/InputfieldImage.module). ~/Projects/pw/wire ❯ ag __additional modules/Inputfield/InputfieldImage/InputfieldImage.module 600: <div class='InputfieldImageEdit__additional'>$additional</div> 634: <div class='InputfieldImageEdit__additional'>$additional</div> Having a further look, `$additional` comes from a hookable method which is just perfect for this module $additional = $this->renderAdditionalFields($pagefile, $id, $n); /** * Render any additional fields (for hooks) */ protected function ___renderAdditionalFields($pagefile, $id, $n) { } Using this hook and rewriting a bit, the HTML looks now this way: <div class="ImageData" style="width: 77%;"> <h2 class="InputfieldImageEdit__name"><span contenteditable="true">align-left-2x</span>.png</h2> <span class="InputfieldImageEdit__info">143 bytes, 44×30 </span> <div class="InputfieldImageEdit__errors">..</div> <div class="InputfieldImageEdit__buttons">..</div> <div class="InputfieldImageEdit__core">..</div> <div class="InputfieldImageEdit__additional"> <div class="InputfieldImageEdit__additional--custom">..</div> <div class="InputfieldImageEdit__additional--title">..</div> <div class="InputfieldImageEdit__additional--foo">..</div> <div class="InputfieldImageEdit__additional--orientation">..</div> <div class="InputfieldImageEdit__additional--link">..</div> </div> <input class="InputfieldFileSort" type="text" name="sort_images_34c8cc73419393a219a5cb218ebcc4b2" value="0"> <input class="InputfieldFileReplace" type="hidden" name="replace_images_34c8cc73419393a219a5cb218ebcc4b2"> <input class="InputfieldFileRename" type="hidden" name="rename_images_34c8cc73419393a219a5cb218ebcc4b2"> </div>

@Robin S Thanks for your feedback! 1. Label vs. Strong I'm totally with you, semantically it should be a label but I had a reason why I wrapped it inside a strong tag: If you have a multilingual installation, the label of the extra field is no longer the title of the field, it'll look something like this (core behaviour, I tried to stand as close as possible): <div class="InputfieldImageEdit__core"> <div class="hasLangTabs langTabsContainer"> <div class="langTabs ui-tabs ui-widget ui-widget-content ui-corner-all"> <ul class="ui-tabs-nav ui-helper-reset ui-helper-clearfix ui-widget-header ui-corner-all" role="tablist"> ... <li>...</li> ... </ul> <div class="InputfieldFileDescription LanguageSupport ui-tabs-panel ui-widget-content ui-corner-bottom" data-language="1010" id="langTab_images_34c8cc73419393a219a5cb218ebcc4b2__1010" aria-labelledby="ui-id-13" role="tabpanel" aria-expanded="true" aria-hidden="false"> <label for="description_images_34c8cc73419393a219a5cb218ebcc4b2" class="detail LanguageSupportLabel">English</label> <input type="text" name="description_images_34c8cc73419393a219a5cb218ebcc4b2" id="description_images_34c8cc73419393a219a5cb218ebcc4b2" value=""> </div> <div class="InputfieldFileDescription LanguageSupport ui-tabs-panel ui-widget-content ui-corner-bottom" data-language="1012" id="langTab_images_34c8cc73419393a219a5cb218ebcc4b2__1012" aria-labelledby="ui-id-14" role="tabpanel" aria-expanded="false" aria-hidden="true" style="display: none;"> <label for="description1012_images_34c8cc73419393a219a5cb218ebcc4b2" class="detail LanguageSupportLabel">German</label> <input type="text" name="description1012_images_34c8cc73419393a219a5cb218ebcc4b2" id="description1012_images_34c8cc73419393a219a5cb218ebcc4b2" value=""> </div> </div> </div> </div> For each language you'll have a label and input field wrapped inside a div tag. The label is the currently selected language. If you haven't only the description field, it's important to mark the field with a title. I chose the `<strong>` tag because it looked the best comparing with headlines. I didn't want to add additional css or inline styles. This is how it would look using h1-h4. The `h1` looks most similar to the label, but I don't want to use `h1`'s because semantically it doesn't make any sense at all. One opportunity would be to use a `label` element if it isn't a multilingual site and a `strong` tag if it is one. What do you think? 2. Wrapping You're right, I'll fix it. 3. type="text" vs textarea At the moment as soon as a textformatter is applied, `type="text"` will be changed to `textarea`. The idea behind this was that some textformatter like "NewLineToBreak" or "NewLineToListItem" doesn't make that much sense applied to an one liner input element. This could be an additional setting, but I'm not quite sure if it's necessary. I tried to keep it as simple as possible

The name property is not translated, it is a unique identifier for a page together with the parent_id. You should not build urls manually like this, you should use the following method: $page->localUrl() See: https://processwire.com/api/ref/page/ Edit: The name is translated as well, but calling $page->name always returns the (unique) name of the default langauge. Use $page->localName() to get the translated name of a language.

Actually, it's pretty nice running your API call through the Tracy Console - save it as a snippet so you always have it on hand. This way you can easily see the results of the selector as well as the SQL query used to generate them. PS I think this is the thread that was mentioned regarding teppo's version: https://processwire.com/talk/topic/9408-is-there-a-way-to-convert-a-selector-in-sql-using-pw-engine/ although I think it's actually longer.

$page->children("start=2, limit=2") Although I don't really see the reason to do that when css columns make it so easy. Also, rather than that, you should probably do an in memory selector to reduce unnecessary db calls, so: $children = $page->children(); $children->filter("start=2, limit=2"); Also, if you haven't discovered TracyDebugger yet, the console panel is the perfect place to test and learn this stuff:

Just testing this out now... it's really great! Going to use this on all sites from now on. One thing i'm testing is that i changed the CSS to show the json for the settings. Then i added a field called settings_import: $field = wire('modules')->get("InputfieldTextarea"); $field->attr('name', 'settings_import'); $field->attr('id', 'settings_import'); $field->label = __("Import Settings Config", __FILE__); $field->attr('value', $data['settings_import']); //$field->columnWidth = 34; $field->collapsed = Inputfield::collapsedYes; $fields->append($field); then i added this, right after this line 222 $json = (isset( $data['settings'] )) ? json_decode($data['settings'], true) : ''; if(isset($data['settings_import']) && $data['settings_import'] != '') { $json = json_decode($data['settings_import'], true); $data['settings'] = $data['settings_import']; $data['settings_import'] = ''; } now i can import all of the settings from one site to another without having to re-create them...

Hello, If you go to "Edit", you should have a tab where the user can delete the page.

Website: https://gatorade.com.do/5v5/ Modules: Form Builder, Lister Pro, Profiler pro, Tracy debugger, Procache (still not installed) It's a simple landing designed to handle registrations to a Gatorade Tournament, but it's kind of cool to see a big brand like Gatorade running Processwire.

This module provides a solution for keeping various site settings in one place (titles, slogans, api keys, emails, addresses, etc.). Features - Admin can create unlimited number of settings - Settings can be grouped - Admin can set setting label, notes, property name, field width and type - Settings can be of type text, checkbox, radios, select, email, url, integer How to use In module configuration create as many settings as needed. Customize their label, type, width and provide a name you want to use in a template files (property name). After that admin can set those settings on "General Settings" page in "Setup" section. Every time you wish to output eg. site name you can use $settings->site_name or wire('settings')->site_name or $settings->option2 to get value of 'Check it' as seen on the first screenshot. (Checked checkbox returns 1). You can change global name ($settings) to something else in module configuration. To get basic markup with all settings and their values use $settings->render(), usefull to check returning values (esp. select/radios - their values are sanitized as page names). Current limitation: -no way to change order of settings, -new settings can only be added at the bottom. Multilanguage To make fields multilanguage aware create a field with a same property name with '_languageName' appended. Example: Your site has two languages: default and french, create site_title and site_title_french fields. Put in a template $settings->site_title. If a user has set french language, this module output site_title_french, otherwise site_title. Please notice that render() function is not language aware. https://github.com/pmarki/ProcessGeneralSettings

Sounds really good. Would happily purchase. The backend being pre-done is much more interesting to me than the having a front end template.

Just a reminder that these are not design literal mockups, they are base styling and default looks. Think of them as functional wireframes.

And some people like to discuss about taste, so they can find something in common

Just to let you know that I was able to add links to the slides. Thank you for your help.

No sorry, I had to do a dirty workaround that meant looping thru records. Nothing elegant and it's a concern for me moving forward if I have very large datasets. I got into a real mess with urlSegments and then having to build the Url for both the languageSwitcher and also the Breadcrumbs in a _main.php. Honestly, Processwire is a really smart piece of code ( i'm very new to it ), but in all my experience coding, when things go this wrong, it's normally because I am not doing something correctly, or I have badly thought it through. I will return to it in a little while as I need to make head way on other parts of the site. If I find something that works better, then for sure, I'll let post it here. Good luck!

Hi Beate, Congrats on the migration also this is how it goes, First you need to go the your Fields and see the name of the fields that hold the comments, then all you need to do is to $fields->find("comment_field_selector,sort=date,limit=AMOUNT_OF_COMMENT");

For pages not using the title field (which you can achieve with: Setup > fields > title > advanced tab > turn off global flag), you can do a couple of modifications: Do this commenting out in importPage function: /*if(!$page->name) { $this->error("Unable to import page because it has no required 'title' field or it is blank."); return false; }*/ Then in importPageValue you can construct a naming scheme or just use the id (after the else statement): $page->set($name, $value); $page->name = $page->id;

Thanks for your suggestion @panx and welcome to the forums . I would like to point out that this is now part of the core since a couple of versions back so the module is no longer necessary for newer installs.

Otherwise you could download this module: http://modules.processwire.com/modules/process-page-delete/ and you will have the following icon for your customers

Hi Manlio, Are you sure you've set a name in different languages? So if your page is called 'Prodotti' in Italiano, is it 'Products' in English? ~Harmen

your search action should be to the search page, e,g, <?=$pages->get("template=search")->url?> that's why you are experiencing those issues you reported.

Ah yes - sorry, my fault about the php modulus approach - you need to count the number of items and divide by three and do a ceil() to make it an integer and use that number because it is breaking on rows and not actually columns. To be honest, I don't really see the point in using the PHP approach these days since css columns is well supported. As for the first column having the dot list-style-type - do you want them all to have dots, or none? It looks like perhaps you have another css rule that is interfering, but I am sure you have that figured out by now.

And regarding cards, i think they can be nice, but used as fieldset container rather then per field, and maybe only in nested fieldsets.

Use the "Create Users Batcher" action in the Admin Actions module (https://processwire.com/talk/topic/14921-admin-actions/) .

Marc, it sounds like you've got a bottleneck somewhere. You mentioned a remote DB connection, and maybe there's something to to that. You also mentioned Windows (I'm in unix), and it's certainly possible there's something platform specific going on. Here are some things you can do to narrow in on where it might be. Edit your /index.php file and before the line that says this: $config = ProcessWire::buildConfig($rootPath); Add this: Debug::timer('pwboot'); Now edit your /site/templates/_init.php file (or whatever gets called first) and add this at the top, after the "namespace ProcessWire;" (old school and rough, but gets straight to the point): die('Boot time: ' . (Debug::timer('pwboot')*1000) . ' ms'); Now you can get a sense of how long it takes ProcessWire to boot, before it hands off the request to you. This should give you an indicator as to whether you need to look at the modules you've got installed, or whether you need to look at the API calls in your templates. Hit reload several times in your site (front-end) to get a sense of the average boot time. On my oldish Macbook Pro and PHP 7, running the site-default profile with no 3rd party modules installed, these are my average boot times: ProcessWire 3.0.52: 53 ms (opcache off) ProcessWire 2.7.3: 104 ms (opcache off) ProcessWire 3.0.52: 35 ms (opcache on) ProcessWire 2.7.3: 35 ms (opcache on) As you can see, without PHP caching the code, ProcessWire 3.x boots nearly twice as fast as ProcessWire 2.7 (at least in my environment). Interestingly, if PHP's cache is enabled, then the boot time is identical. But when Soma said above “ProcessWire is getting slower and slower each iteration”, this is a blanket statement that is the opposite of reality. ProcessWire is getting faster and more optimized with each version. What's real is that clearly something about the conditions present in his environment and your environment is reducing performance, and that needs to be narrowed in upon. So the next steps will be to determine if it's something about the server, something from a module, or something going on in the template file(s), like some specific API call that might be common among your installations. Now go to your Chrome dev tools, Network tab. Hit reload several times like you did before (same URL). Note the first request in your Network tab. Take this time and subtract the time you recorded above. This represents (roughly) the time required to load PHP before it gets to ProcessWire. With opcache off, my PHP takes about 100ms before it loads ProcessWire's /index.php file. If I enable opcache, then I'm seeing almost no overhead from PHP at all. Meaning, Chrome dev tools is showing 40ms or less. I'm guessing that your remote DB connection is going to mean your boot times are significantly higher than if it was local. So maybe you shouldn't be looking for the same boot times that I'm seeing here. But hopefully you can get a better idea of whether the times you are seeing are related to the boot process, or what happens after the boot process. If you are seeing it in the boot process, then uninstall all 3rd party modules and test again. Or go one-by-one until you can narrow in on which one it is. If still seeing a slow boot then we might need to start looking at potential Windows platform issues. If your boot times seem reasonable, then the next step is to start debugging in the template files. Let me know what you find and I can suggest the next steps.

@cosmicsafari. Welcome to the forums and ProcessWire. You will need to include your Foo.php file in your module ( MyModule.module). ProcessWire doesn't know about it and will not include it for you. You can require it outside the class or in its __construct() or function init() methods (I think either of the three should work). $dir = dirname(__FILE__); require_once($dir . "/Foo.php"); Maybe it was just a typo, but module files end in .module (that's the extension, not .php)

damn... I totally missed this topic but it looks like as if nothing happened so far Any further plans for a meetup? Currently "regular" might be a tricky thing for me but let's have a beer anyways ...

Maybe this is the issue?

In my opinion there are two sides to this problem: Many client's know WordPress and ask for it specifically, which in turn means that the companies building sites find it an easy product to sell. Even if the client doesn't know WordPress, they just need to be told that it's the most popular CMS out there. "You can't go wrong by choosing the most popular product in the market." Many web developers first dive into the CMS world via WordPress. Once they know it, it's tempting to use it for everything. Even if it's a struggle to create anything more complex with it, they a) don't know that there are better alternatives, and b) going with another system would require a whole lot of un- and re-learning. I try to advocate for ProcessWire every chance I get, mainly because I believe it's truly a great product, and fits many needs amazingly well. Obviously it's not for everyone, and in fact I have once or twice actually recommended going with WordPress instead. Funny you should mention this, as I was literally just today thinking about how the commercial modules fit the ProcessWire landscape, and once again came to the conclusion that it was a smart move from Ryan to make FormBuilder as cheap as it is. If you think it's "not very cheap", you probably don't really get how much it does for you Before Ryan released FormBuilder we were contemplating building our own form module, but just thinking about how many things such a module has to handle makes me shiver. It's a heck of a lot of work to build a module as flexible as FormBuilder, and making it easy enough for anyone with no technical expertise to build complex forms is not easy either. Agency license for FormBuilder is $289, and I can pretty much guarantee that building a module like that on your own will cost you at least ten times that amount. On the other hand we were considering buying another commercial module a while ago. The cost for a single license for that particular module turned out to be four digits, and eventually we decided not to buy it. I've been working on a module that matches our needs specifically, for a cost that is notably lower than we would've had to pay for the third party module. We're planning to release this particular module as open source when it's finished. It's true is that you generally can't add a completely new feature to a site, let alone build a new site from the scratch, without at least some basic dev skills. That's also not the market we're in. I think those who want to do that would be much better off with a DIY website builder platform such as Wix or Squarespace. This kind of thing is not really the forte of WordPress either – building a complex site from (sometimes) badly written, barely compatible plugins requires a whole lot of work, at least in my experience This depends on your definition of a "big company". Avoine is, in my opinion, the best example in this category – they've done some pretty amazing stuff with ProcessWire. Everyone in our line of work should know them, at least. I'm not an official spokesperson for my company so I prefer not to go into more detail, but at Fonecta we also use ProcessWire in some of our projects. You've probably heard of us before. If you're into command line tools, check out wireshell. Depending on your setup there are other solutions too, probably the easiest being the built-in multisite support, where multiple separate sites share the same core code.

@flydev Take a look at https://github.com/jubos/fake-s3 and https://github.com/jserver/mock-s3 I have not used them.

Ah man, this is awesome. It'll make it a lot easier to use Processwire as the CMS for a front-end not built on Processwire. =D

Hey @bcartier and everyone who is following. I implemented a basic language support. Nothing really changed, except now with LanguageSupport enabled in your ProcessWire app, the GraphQL api will return the content in whatever language the user is assigned. In addition, when Language Support module is activated, there is a language field in your GraphQL api. So you can request the exact language you want. It looks like this. { language(name: "de") basic_page{ list{ title summary } } } You need to put the language field on the top. Well, not exactly on top but just before fields that return translatable content, like title, headline, body etc. It's because GraphQL processes requested fields from top to bottom and it will not know what language you want till it gets to language field. Did you also know that in GraphQL you can query same field multiple times with aliases? Here, take a look at this { basic_page_default: basic_page{ list{ title summary } } language(name: "de") basic_page_de: basic_page{ list{ title summary } } } Curious what will be the response? Try this with site-languages profile and find out.

Yes and no Maybe this time you could keep it a bit more organized like this 4 part tutorial: http://blog.mauriziobonani.com/processwire-basic-website-workflow-part-1/ as opposed to the journal style of this thread. If you take notes first and later on write the parts of a series one-by-one, then it can be more "tutorial like".

Multilanguage can complicate things a lot and most non-techie people doesn't even recognize that. At one of my workplaces they asked me to place 3 language flags to the header - they thought it's just as easy like that