Leaderboard

Welcome to PW Just very very quickly (it's past midnight now, and I should really get some sleep): If you add a new field to a template, you have to add code to output that field. Depending on direct or delayed output strategy (several echo() vs. $content .= concatenation and just outputting it once) - you need to simply add either $content .= $page->my_new_field or $page->my_new_field "move things around in the template": PW doesn't care about your field order you're using inside your templates. You have to define yourself what you want to do with it - that's the nice thing working with PW (one of a million).

I don't think you need a full webshop system such as Padloper or Snipcart for 4 products. Make it easy on yourself and use PayPal buttons - your work will be finished in 30 minutes.

Well, there are many tutorials out there. Since I don't know which ones you already have read, I'll just urge you to read (or re-read) these basic overviews: http://processwire.com/about/what/ http://processwire.com/api/ The "holy trinity" (imho) in PW consists of: templates pages fields The API glues it all together. Once you realize how those things play together, it'll click. Now, and this is what most people might confuse: Pages inside the PW admin (page-tree) don't have to represent typical "web pages". Pages can be used for simply creating attributes for a select dropdown in a template, as a reference. They don't need to be published (publicly visible). Templates can store any number of fields - if you're just building "normal" websites, these would be called "page type". But you can also control permissions with templates (and much much more). The hierarchical page-tree seems simple at first (some folks might think "so what?"), but you can use the page/parent-children relations for all sorts of stuff, like categories. If you're building web apps / sites for an international audience, you'll be surprised how simple and thought-out the multilang handling is made inside PW. Lots of systems force you to create a JSON/XML file for strings that are not directly editable in your template (button/form/JS strings). With PW, everything is editable right inside the PW-admin. PW selectors are powerful. Everything is relational. You can query, fetch, cross-reference anything easily (fields, pages, sub.field.values etc.). You can build your own custom modules or dashboards, and don't even bother with a "classic front-end". People have built huge CRM systems or similar where everything is happening only in the so-called backend. For lots of people, the "click" comes when they realize how bloat-free PW is. It doesn't assume anything. It gives you lots of freedom, and people accustomed to frameworks with a steep learning curve, at first don't really see the benefit of it. Because most ppl tend to think "more complicated probably equals better". So, perhaps ask yourself what exactly do you plan to build. Ask questions here, and we'd be happy to point you in the right directions.

It has been said here many times that PW is like a dream PHP/MySQL API with a free admin on top. The ProcssWire admin has no explicit connection to the frontend unless you make it so. You could for example have a completely hardcoded HTML frontend page, and an admin that does nothing but serve as a CRM tool. The frontend is completely up to you; You may be confused because it comes with a free/default/demonstration front end, but nobody really uses that frontend. You will see the value of it when you have clients using the CMS for content management (from simple to extremely complex content), which is what the admin is for. If you have clients who will never use the admin, and only the developer, well that is your own unique set of circumstances, and no assumption should be made that everyone else does it this way. Therefore your definition of who is using the CMS admin is making a vast assumption, and you have also made the assumption that the admin is somehow 'behind the scenes' when in reality it can be behind the scenes, or it could be 'the scene'.

Hi, first of all, welcome to the PW forums, and may I say what you are doing is exactly what I envision myself doing in retirement, still coding but for fun and learning. ProcessWire is not a WYSIWYG editor where you just move the items around and the change is reflected on the frontend. Moving around the fields in the template editor only changes their position when you are editing them in the page editor (i.e. Home > Edit). Now to change the output, you do have to change how it is "hard coded" in the template files, as that mostly is how websites are written. There are "WYSIWYG" CMSs out there like Concrete5, where you can drag and drop the "sections" of a website, but I assure you, you're better off with PW as I was working with Concrete5 back in 2012 before finding ProcessWire and never looked back. I hope this helped a bit, and that you enjoy working experimenting more with ProcessWire. Cheers.

Maybe processwire could harness tus for chunked uploads. Integrating the existing js/php components into processwire might be simpler than writing a custom backend for resumable.js.

Maybe it is easier (even better?) to instead bootstrap ProcessWire inside your WP and use ProcessWire to create ProcessWire pages. https://processwire.com/api/include/

@fermion As a reaction to your hosters answer: The setlocale() function only has an effect if the locale you are trying to set is installed on the server, and locales do not have the same name on every system. Some linux distros or windows use different names. If for example the "de_DE" locale isn't installed and you call `setlocale(LC_ALL,'de_DE');` then the default locale would be used instead. That's why there are different namings for a language in my code. On linux you can find out which locales are installed with `locale -a.

I'm an old programmer (as in Algol, Fortran, Cobol, PL/I, C, Perl, etc.) just learning web development for an idea I have as a hobbyist/retirement project. So the database side of things is no problem, nor is PHP per se', but the way everything fits together in ProcessWire is giving me trouble. I realize this is likely a completely stupid question, but I don't understand some of the most basic mechanisms in ProcessWire, most likely because I'm starting web development, not from the ground up, but using a CMS framework, I guess. I've gone through several of the tutorials, installed ProcessWire on both a shared hosting server and my personal WAMP (see how I'm already throwing around FLA's like I know what I'm doing?), and trying to build my understanding of the workflow, but I can't figure out why (seemingly contrary to some of the tutorials), I can move fields around on the home template that comes with the Intermediate Site Profile, even add new fields and include them on the Home Template and Page, but these changes never show up on the browser page. If I make changes to content, titles, etc. of existing fields, they show up, but changing the order of them doesn't affect the output at all. It appears that this is because that's all specified in the _main.php file, but I don't understand the capability of being able to move them around in the Templates, if they're hard coded in PHP... I'm sure there's something somewhere in one of the tutorials I've already read that covers this and I just missed it, but at the moment I'm completely baffled as to what's going on... If there's a "basic-er" tutorial somewhere on how all this stuff fits together, or a good overview of the concepts that I should go through first, I'd be grateful if someone could point me towards it.

Hey guys, for some reason the forum has not been notifying me of new replies in this thread, so I apologize for my absence. @Robin S Thanks for the info on the new InputfieldPage::renderReadyHook method. I will update the module asap. I think that as it stands right now, the module does work in a repeater as long as the main page also has a page field that is using the module. The problem is that the js and css assets are not included by the repeater. @Ipa it looks like the javascript for these two modules is conflicting. I am not familiar with HelperFieldLinks. Can you explain its purpose? Also, can you get me a larger screen shot of this in context of the rest of the field? I don't think this would be too difficult to add. Good idea.

You should note that while the template editor is mainly for the developer, the page editor where you actually put content is mostly for the users (writers, ads/seo managers,business owners, etc). So the value is that you could have a functional and customized content editor with just a few clicks. It is also important to note that ProcessWire is a content manager. For me, and for most cases i think, this is much more "valuable" than a WYSIWYG front-end because while front-end design trends/frameworks come and go, the back-end would remain the same. It would be much more wasteful to support all of these trends/frameworks with drag-and-drop support only for them to be unpopular in a few months. And it's also been argued countless times that a well-crafted website design is many, many times better than a "customizable" but inescapably bloated front-end. I still cringe remembering the markup regurgitated by Dreamweaver and the likes. Not to say that the concept is without merit, but it does not fit all use cases, and goes directly against ProcessWire's unopinionated nature. Would you mind giving other examples? I've been using ProcessWire for some years on a daily basis, and I haven't once thought, "hmmm, this doesn't do anything, we should just remove it". That being said, each project is still unique, and if you think the way ProcessWire works is inadequate, that's where modules come in. Or other CMSs, for that matter. For me the strongest reason for choosing ProcessWire is simple: with what it does it does so well, and with what it doesn't it doesn't stand in the way.

Hi, and welcome. The answer to your question is 'Well, yes, probably.' Give us a bit more of an idea of what you are trying to do and we will try for a more detailed answer.

I don't share the opinion that the installer ist the best thing possible. There could be more improvements, for example the locale setting that you mentioned. Or displaying the installer in another language. But as ProcessWire is Open Source everyone can submit ideas or fixes. If you don't speak English so well, use an online translator such as https://www.deepl.com/translator, which is the best one I know and submit your ideas to this forum or on https://github.com/processwire/processwire-requests

Not sure as well, but maybe has something to do with '/' being the only saved page with a NullPage as a parent? echo print_r($pages->get('/')); // result // ProcessWire\NullPage Object ( ... ) And in the database, home's parent_id is 0, and it does not have an entry in pages_parents. Upon further digging, I also found that home is the only result when querying for "has_parent!=1", and it is hard-coded. Anyway, if you require home to not be in the result, maybe just exclude it from the query? $childrenOfHome = $pages->find("has_parent=1, id!=1");

Thanks @adrian, I'll have a think about those things. I realise now that I have made a lot of changes myself to FieldtypeMapMarker for different projects - every time I use it I find something that doesn't really suit me or work too well. Maybe I should go through all of that and consolidate it into my own fork. Then we could possibly look at where it makes sense to combine our forks together.

@Roych I pasted your code of the first post and it has syntax errors, so you should sort those out first. I recommend you follow guidelines such us: https://www.ntchosting.com/encyclopedia/scripting-and-programming/php/php-in/ In the article there is the "Possible yet not recommended usage:" section. Do not do that For example, do not do this: <?php foreach($pages->find("parent=1034") as $item) { echo "<li><a href='index.htm#' data-filter='.{$item->select->category}'>$item->title</a></li>"; } ?> instead: <?php foreach ($pages->find("parent=1034") as $item) : ?> <li> <a href='index.htm#' data-filter='<?= $item->select->category ?>'> <?= $item->title ?> </a> </li> <?php endforeach; ?> Much cleaner and a harder to make mistakes. But most importantly, do not mix coding styles

It is possible to output fields in your template file so that you can change the field order in your template and see the change reflected on the front-end. You would loop over the template fields and then output the markup relevant to that field. You could do this with a long if/else structure to check the name and/or type of the field... foreach($page->template->fields as $field) { if($field->name === 'title') { echo "<h1>$page->{$field->name}</h1>"; } elseif($field->name === 'images') { // ...etc } } But it would be tidier to set up render files for each field (see here and here) and then output the markup with... foreach($page->template->fields as $field) { echo $page->render->{$field->name}; }

If you gave us some more background infos about the "big picture", I'm sure we could come up with more ideas. e.g. Is it always the same CSV you want to parse/display? Does your client frequently upload CSVs (updates)? Are you doing this in just one particular place, or in dozens of other areas / pages? How big are those CSVs? There's a great module (Handsontable) by @bernhard that you could use. The client could copy+paste from Excel to PW, and with little code you could display that as an HTML-table. If it's data that don't need to be synced every day (with a cron job), you could do a one-time CSV-to-PW conversion (build a page that holds data/fields equivalent to the CSV data structure), and then let the client update this data inside PW. re: speed / performance / caching etc. If the server has to process a huge CSV every single time the page is requested, you could run into problems. So... depending on your needs we might suggest going this route or another, and avoid to have bottlenecks, and probably making the UX for your client better. re: Hanna Code https://modules.processwire.com/modules/process-hanna-code/

These days rarely but one never knows

I think you need to concentrate on parsing the CSV file with a library like this one. Or also this function is built in PHP which takes a string as input: http://php.net/manual/en/function.str-getcsv.php

Check your log for errors or timeouts. Do you have Tracy installed? At this point it would be your best bet to see whats going on. I've experienced this before with PageReference fields trying to load thousands of pages into a combobox options (instead of using ajax load). That's the only thing that comes to mind without any more details.

Or Stripe Checkout: https://stripe.com/checkout https://stripe.com/docs/checkout (Integrating Checkout, etc.) https://stripe.com/docs/checkout/php Edit: http://modules.processwire.com/modules/payment-stripe/

Got to agree with Kongondo: if that is doable for you, i.e. both sites sit on the same server, bootstrapping ProcessWire is probably your best bet. Otherwise I'd recommend checking out the REST API site profile and/or ProcessGraphQL. To my best understanding both provide the ability to create content via the API, and both have some sort of authentication mechanism available. Authentication is basically the main thing here: it's really easy to create a ProcessWire page that takes POST requests and creates pages etc. but you don't want, under any conditions, that to be publicly available without some sort of authentication. This is why I'd recommend checking the existing solutions first, and only rolling out your own solution if it's absolutely your only option

This has always been the case as far as I can remember. Similar to rootParent of home: $h = $pages->get(1); echo $h->rootParent->id;// outputs 1 You'd think home shouldn't have a root parent, but it does. I think both were intended, but let's see what @ryan says.

@theo I think that is something that should be reported. Could you open an issue on Github, so Ryan could comment is it intended behavior or a bug?

You don't want to remove the || placeholder used to render the entries. Edit: Ah I see, there's a problem of <li>'s inside a <div> within a UL isn't valid HTML and Browsers moves them out of the <div>. Unfortunately there's not way to render such a thing in MSN. Bootstrap is really strange... why can't they just have normal nested UL's...

Yeah, I think that would be great - I think we need one feature-rich version going forward that has all these improvements. I don't expect Ryan will accept a PR, but I do remember sometime ago he suggested I could take over this module if I wanted - personally I don't really want to because I already have too many to support, but perhaps if we both had commit rights on the main repo we could share the load?

Hi @Robin S - glad you're finding the fork useful. 1. I can't see a difference in behavior from the main repo - it looks to me like the lat/lng get populated when creating a new page, but not the address field. I think this actually makes sense to me because I think it's really just designed to give the site editor a local starting view, rather than an exact address. Am I missing something? 2. Happy to incorporate the AJAX fix - thanks. 3. I honestly don't mind the spacing. It is applied differently in default and UiKit themes which makes it a bit of a pain. Probably changing the <p> to <div> as you suggested might make this a little cleaner. Perhaps you'd consider a PR to my repo so you can get it looking how you'd like it - better to have someone tweak this who has a definite opinion on it 4. I am looking at this now - agreed that this should be fixed, but I noticed a bit of a dilemma - currently I trigger the geocode request like this: if($street.val() && $city.val() && $state.val() && $postcode.val() && $country.val()) { $addrComponent.blur(function() { geoCodeAddr(); }); } In other words, don't trigger it until all subfields are complete (except the additional_address which isn't added to the address which gets geocoded anyway). So if you're in a situation where not all subfields are filled out, it won't geocode. I don't really want to have a manual geocode button - would rather it was automatic - what do you think? As for submitting a PR back to the main repo - I don't think there is really much point - I have a 4 year old PR there already which has been ignored Not that I want to have multiple forks of modules floating around either, but not sure what other option there is.

Thanks for this fork - a very useful enhancement. If you think you might submit a pull request I saw a few things that could be good to include. 1. The default address setting in the field config doesn't work in this fork. Maybe it needs separate fields for street, city, etc? 2. Perhaps you could integrate this fix for ajax-loaded inputfields: https://github.com/ryancramerdesign/FieldtypeMapMarker/issues/19 3. Because the inputfield places the text inputs inside paragraph tags, there is an excessive amount of vertical space between rows of inputs (in the default admin theme at least - I didn't check the others). Solutions could be to change from <p> to <div> wrappers, or to add a rule to InputfieldMapMarker.css to reduce the margin on paragraphs. Edit... 4. Would it be possible to avoid the trailing commas in the Address field if some of the components aren't filled out?

Just as a heads up if someone needs database testing: I am trying a different approach at the moment: I simply added a database configuration to the config.php which is used if PW is called from PHPUnit. in config.php if(isset($_ENV['UNITTEST']) && $_ENV['UNITTEST'] == true) { $config->dbHost = 'localhost'; $config->dbName = 'db-test'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->httpHosts = array('localhost'); } and my PHPUnit configuration.xml looks like this <phpunit ... some settings here ... > <php> <env name="UNITTEST" value="true" /> </php> </phpunit> maybe this will save someone a headache in the future

I disagree, Horst. It seems, that the most participants in this thread are convinced, that the installer (and that's what I like to talk about) has the best functionality, which is possible. In my humble opinion an installer should protect the superuser from warning after the installation. I think the usability of an installation process around language issues is ideal, when during the installation process the user has to decide about that. Example: We recognize, that your computer is located in Germany. 1 Do you like to use the language [German] (menu to choose another) for the GUI of the backend? [OK] 2 Do you like to use the language settings of PHP for [German] (menu to choose another)? [OK] * 3 Do you like to use the language [German] (menu to choose another) in your first website? [OK] That's all I suggest. That behaviour is good practice in many software I installed in the past. I hope you regard my arguments not at all as an "ungratefulness" from a newbie. The contrary is true. Because I appreciate the project a lot, I think is worth to be honest and give a constructive criticism. *Of course the questions 2 and 3 could be written in that language which has been choosed in question 1. But of course only than, when the project has enough resources for translation work.

Thanks to all that have been helping us to wrap up issue reports on GitHub in preparation for the next master version of the ProcessWire core. Unless any major issues surface, most likely 3.0.95 (next week) will be the next master version. Like last week's version 3.0.93, this week's version 3.0.94 continues along the same path in clearing up new and existing issue reports, and fine tuning little details for the master branch. If you come across any new significant issues please submit them in the issues repository. Or if you opened an issue awhile ago and we haven't fixed it yet, please check that the issue is still applicable and reply to let us know. No blog post this week because I don't have anything else new or interesting to write about other than this. But I am definitely getting excited about having a new master version ready. There's no doubt, this is a really nice upgrade relative to the current master 3.0.62. Have a great weekend!

The Fotomediale is a annual festival of photography for children's and youth photography in Freiburg, Germany. This small website provides information about the festival and its workshops. Because of the topic, this site is very picture heavy. Almost every page contains it own set of images displayed in the background. The images cycle through automatically, but you can also use the buttons on the edges (or if you want arrow keys on your keyboard ). If you want to see the images, you can collapse both the navigation and content area. The transitions between pages were made with Ajax and pushState, but you can also access them directly via their URL. To handle the large image backgrounds, all of the images are lazy loaded using lazysizes. The registration form was created using the API. www.fotomediale.de Modules used: ProCache Markup Sitemap XML Email Obfuscation (EMO) Tracy Debugger Regards, Andreas

Inputfield::renderReady was made hookable as Inputfield::renderReadyHook in PW 3.0.44. So the module could be updated to hook after InputfieldPage::renderReadyHook instead of before InputfieldPage::render - then it will work with repeater fields. That would add a requirement of PW >= 3.0.44, or else the module could check the PW version and hook different methods depending on the version.

As workaround for PageFieldEditLinks inside Repeaters, I've hacked this. Just place the code below in templates/admin.php. (Adjust 'my_template'). if ($page->name=='edit' && $input->get->id) { if ($pages->get($input->get->id)->template->name=='my_template') { $config->scripts->add($config->urls->siteModules . "AdminPageFieldEditLinks/AdminPageFieldEditLinks.js"); $config->styles->add($config->urls->siteModules . "AdminPageFieldEditLinks/AdminPageFieldEditLinks.css"); } } Place the above before: require($config->paths->adminTemplates . 'controller.php');

I have launched my martial arts website at https://merpatiputih.com.au/ As a martial arts instructor, my problem was how to track student attendance, payment, course modules, and exercise /health progress report etc. and from my part, I need to publish the class event, schedules, location, and exercise modules for that event. For public viewers, I just simply use blog profile module and UIkit. It's very easy and quick to set-up. The purpose of this site is for a logged-in member where from their mobile they can check-in to the available class a day before, and update their health record after the class. For user front-end, I'm using <region> and delay output. I found this method is really efficient to manage the HTML output, clean and simple. Less headache with templates structure. Below are the functions and modules of this web apps: For Course sessions I'm using page reference, Profields Repeater Matrix and Schedule Pages Module. Profields Table to generate the student records and reports. Calendar for recurring class sessions through the year based on student ranks, selected by user Roles. I only need a simple calendar function (a quick search from the Internet) that able to receive a month and year input. Then, by using region, events field, Profields Repeater Matrix and URL segment it was reduced my time to code complicated function for the event schedule. The only thing here that I have to manage in date calculation is the time format, in Australia we use d-m-y. The tricky thing to get Next month (month + 1), I have to modify it to the first week to get a proper next month. To avoid inquiry about forgot password or username, student logs in via Facebook Login module. Here is the screenshot of student report:

Wow @Zeka. Nice find.

Hello @abdus, congrats on your really great venture. Much appreciated. Is there any news about your newsletter module?

I had a need to do this and there were some requests in the Table forum so... LimitTable A module for ProcessWire CMS/CMF. Allows limits and restrictions to be placed on selected Profields Table fields. For any Table field you can limit the number of rows that may be added and also prevent the use of drag-sorting and the trashing of rows. If a limit has been defined then there is an option to show all (empty) rows up to that limit. This module does not support paginated Table fields. Usage Install the LimitTable module. The module configuration screen should be self-explanatory. You can add rows in the module config as needed using the "Add another row" button. Please note that limits and restrictions are applied with CSS/JS so should not be considered tamper-proof. Module config: The effect of the above config in Page Edit. The empty rows up to the limit are shown because "Show all rows" is checked. https://github.com/Toutouwai/LimitTable https://processwire.com/modules/limit-table/

The CSV format is so simple you can easily create a template to generate the right output. As an example: <?php header('Content-Type: text/csv'); header('Content-Disposition: attachment; filename="export.csv"'); $items = $pages->find("template=basic_page"); echo "title,url" . PHP_EOL; foreach($items as $item) { echo "\"$item->title\",\"$item->url\"" . PHP_EOL; }