Leaderboard

Today a new version of FormBuilder has been released in the FormBuilder support board (our 50th version) and it has a lot of interesting new features, which we’ll take a closer look at in this post— https://processwire.com/blog/posts/formbuilder-v50/

Hi, Here is a short tutorial on my vision of routing in ProcessWire. https://www.spiria.com/en/blog/web-development/tutorial-routing-in-processwire/

@Jonathan Lahijani Good idea, I need to add those to mine too. Note that %= is the default/assumed operator, so you can make it even simpler (if you want) by just entering this: search engine optimization seo The thing you have to consider here though is if "seo" can appear as part of other words? The %= operator is a partial match operator without boundaries (same as in $pages->find), so it'll match words like Passeo, Osseo, Seoul, Seola. Given that, for matching "SEO", you probably want to perform a full word match, i.e. ~=seo

Love it. The appending the form ID to the subject line is very convenient. I relied on using a hook for this for the last however many years. Nice to see it baked in. Thank you for Bootstrap 5 support as well. New spam features will be very helpful. I will immediately be adding these rules: %=search engine optimization %=seo ?

@thetuningspoonI have forked this at https://github.com/MetaTunes/AdminPageFieldEditLinks Changes to : Show 'view' links for locked page fields in case of multi-pages. Add 'new tab' as alternative to modal for edit view (configured in field input settings). Bump version to 3.1.4

The next dev version of ProcessWire is in progress but I'll wait till likely next week to bump the version. So far there are 6 new pull requests added since 3.0.179 and 2 issue resolutions, plus some other updates, with plenty more on the way. A lot of focus this week has also been on FormBuilder updates which include new spam filtering options, improved save-to-page options, improved Combo field support, new entries actions (and the ability to add more via modules and hooks), framework updates, and various minor bug fixes. This version has a lot of nice improvements and I'm hoping to have it ready for you in the next week or so. More details soon. Have a great weekend!

@ryan, regarding the update to ProcessWireUpgrade, could you please add an option to skip this interstitial screen? Because it doesn't add much value and just requires an extra click. If you are visiting the Upgrades page it already implies that you want to load the latest core and module versions to check if there are any upgrades available and the few seconds needed isn't going to be a big deal to you. Thanks.

Lol yea my excitement got ahead of me before thinking that through.

It seems to be fixed. I don’t know why. What I did was copy the Source markup from the CKEditor field into Vim and scour it. Since the content had a lot of link anchors, I added new lines around each one so that I could see them separately. But then… I found nothing unusual. I added blockquote tags around one paragraph that was a quotation, and I switched a few em tags to cite since they were book titles, and I changed a few straight quotes (") and apostrophes (') in the markup to the curly versions (“, ”, and ’). I pasted the result back into CKEditor's Source panel and saved the page. And that fixed the problem. Even though the problem is solved for now, it would be great to learn more about what went wrong, how it went wrong, and how we could prevent this again. Thanks in advance for any guidance! P.S. Is this the right sub-forum for this issue? I chose API because I thought that it was related to the interaction between my page reference field and the template markup, but that doesn't seem to be the case.

Hi MarkE, Thanks a lot for your response. with the latest DbMigrationPage.class.php eveything went fine. I was impatient to try this module that adds a set of features that I was realy missing in PW. Hope the module will go on the PW module page at some point. Thanks again. Bye

@adrian I think the problem here might the wrong format importing (the separator precisely) and not the widths themselves. @Norman_12 Your question shows that you don't have an understanding of how a csv file works. Please have a look here https://support.microsoft.com/en-us/office/import-or-export-text-txt-or-csv-files-5250ac4c-663c-47ce-937b-339e391393ba. This is not related with Processwire at all. I don't know if you're a new web developer or the owner of the website doing some DIY, and I'm personally fine with any of those, but be aware that we're a bunch of seasoned developers offering you some valuable time, and we'll need to draw a limit somewhere.

CSVs don't have widths. You are using Excel to view a CSV. If you want a properly formatted Excel file, it's pretty trivial to write an API script to export a series of pages to an Excel file with something like https://github.com/PHPOffice/PhpSpreadsheet which lets you format the spreadsheet almost however you want.

In "CSV fields separated with" you must must add the character that you want as the csv separator. That would usually be a comma "," or a semicolon ";"

Actually it already has a second parameter to provide a file to take the content from. This means you could add a skeleton folder to your module holding the initial markup and the module will copy that content to the templates folder: https://github.com/BernhardBaumrock/RockMigrations/blob/3844b697be393b98dbc9a47b55370c4fa521c20b/RockMigrations.module.php#L1817 One could also make it sync files or add the file having a single "include" to reference the markup from within a module folder. But I didn't want to overcomplicate things ?

Most of the time I do not have anything in template file other than the namespace too as I use it as a controller. And unlike Wireframe I do need this file to avoid error, so this is not useless addition.

Hi Ivan, good question ? My workflow is based on RockUikit - a module for Frontend Development similar to WireFrame. So I need the file solely for making the site visible on the frontend. Markup is placed in a different location. Now that you are asking I realize that this might not be the most helpful addition for others. Anyhow I'm just keeping you updated so maybe someone will pick up some inspiration or have suggestions or input for me ? But in general my workflow is now a little bit like "everything is a module" ? And RockMigrations does everything related to template/field/page creation ?

Thanks everyone, this has all been really helpful!

Hi @thetuningspoon. I have done a hack to display the edit links for multi-page situations where the field is locked. I've also added a quick module config to display edits in modal or as a new page - ideally this would be on a per-template basis. I'll do a fork once I am happy with testing.

So it seems to be server-side at this point. Your setup overall looks totally fine if it's running within a hosted environment or Laragon/XAMP/MAMP... Try to install ProcessWire... look what comes up next... in most cases there shouldn't be any problems. Can you tell us more about the environment, the hosting company or whatever you use? Maybe there is somethings special about that environment. IONOS (1&1) are some kind of special - for example.

Just a totally different approach in terms of ... creating a new template of some kind. Whenever I start a new project I look up possible definitions, and standards I could need and use within that project. For example schema.org, microformats, and similar... events, corporations, business, personal data, whatever... most of the time I find things I could use from all around the web. In some cases I call our chamber of commerce and similar for details about things they save, have to save or need to save about companies of all kind. Sometimes I even talk to my accountant, my lawyer and other similar "institutions"... whoever can help me. Sometimes the niche even has standards defined I can use and therefore I use them (for example: book stores). Then... whenever I set up a new templates for whatever data-object I need to save... I keep it flat... I don't care if a template has 10 or 100 fields... (books are a perfect example here). I need those details each and everywhere therefore I don't want to work with if/else, case, joins or whatever to get my details. I only reference small bits and only those I really have to and want to reference (authors of books, form of organization, and similar). Just my two cents.

Actually I think that @Jan Romero's fix would address the problem, as I could just lock the field rather than restict access. However, it seems to me that fix only works for single, not multiple, pages. I'll take a closer look...

v0.0.64 adds a new method $rm->createViewFile('yourtemplate'); that creates a file /site/templates/yourtemplate.php That might sound like overkill, but when used with class constant and OOP that makes it clear and easy: <?php namespace RockTeam; use ProcessWire\Page; use ProcessWire\RockMigrations; use ProcessWire\RockTeam; class TeamPage extends Page { const prefix = RockTeam::prefix; const tpl = self::prefix."teampage"; const tags = RockTeam::tags; /** * Triggered in RockTeam::migrate() */ public function migrate(RockMigrations $rm) { $rm->migrate([ 'templates' => [ self::tpl => [ 'tags' => self::tags, 'icon' => 'users', 'fields' => ['title'], ], ], ]); $rm->createViewFile(self::tpl); } }

I don't think there is a "best practice" written down somewhere for this sort of scenario. I agree it can be confusing to figure out the "right solution" when there would seem to be so manyw ays to achieve the same. If all the values from the identifier are okay with being a text type value, I would go with a Table field with two columns, a Page Reference that fills its options with the "catalogue" of "possible IDs" and a text field that acts as the field for the actual value, this way you can have whatever fields you want on each organization, and you can do stuff like: $pages_with_purls_identified_orgs = $pages->find('template=organization, ids_table.id_type.name=purls'); This also guarantees you can also add new identifiers in the future very easily and consistently. You could do almost exactly the same with repeaters. Why table and not repeater? I just prefer the interface of the table field, I think it's less clunky visually when few fields are involved and has a more snappy feel. If each identifier would need more data added, I'd go for a repeater, but since it seems it's just an ID name and the actual value, table field seems enough. Repeaters would also have the "overhead" of loading an extra page on memory per repeater, since each repeater item is a processwire page. Although another scneario, what if the value of each identifier is a different type, then the table field would not work as nicely. Say you need DOI to be alphanumeric and ORCids to be integers, maybe for this case a repeater could work, with the same catalogue of identifiers, except that you create two additional fields (one text type, one integer type) and show them conditionally depending on the value of the page reference field where the type of identifier is selected. Please take this idea with a grain of salt, just something I came up with right now. It might be a hassle to manage the relationship of "identifier - type of value" on the actual code, or it might be worth the trouble, or there might be a better solution out there ?

@kongondo keep up the great work. For me it would just be great to play around with this and service the ecommerce requests that I get, even in a basic capacity knowing that a fuller feature set will come later so I am not too fussed about advanced features at this stage.

Hi everyone. It's been a while. A little update. There has been a delay, again, unfortunately! Lockdown hit really hard. There were also a number of technical issues but these have since been resolved. Finally, a number of you (having seen the preview videos) strongly expressed the need for the Padloper UI to resemble the ProcessWire admin theme even in the alpha stage. The message I got was that this was more important to them from the get-go than having advanced Padloper features. I accepted their reasoning but this came at a cost. Padloper 2 has been re-themed to look like the ProcessWire admin. Given that we are using third-party libraries to build Padloper 2, this took a lot of time. Focus was placed on basic features only, for now, in order to expedite the first release of Padloper 2. This means that some advanced features will be missing from the first release of Padloper 2. As for a release date, I was hoping for a 'spring baby'. That won't happen. I am now working hard toward a 'summer baby'. Screenshots Have a nice and safe day.

Format Datetime fields as Carbon instances. You can find the latest release and the complete readme on Github. Installation composer require daun/datetime-carbon-format Usage All Datetime fields will now be formatted as Carbon instances instead of strings. Some examples: // $page->date is a Datetime field // Output format: j/n/Y echo $page->date; // 20/10/2020 echo $page->date->add('7 days'); // 27/10/2020 echo $page->date->format('l, F j'); // Monday, October 20 echo $page->date->year; // 2020 echo $page->date->diffForHumans(); // 28 minutes ago Frontend only The ProcessWire admin seems to expect datetime fields to be strings. This module will only return Carbon instances on frontend page views. Date output format When casting a Carbon instance to a string (usually when outputting the field in a template), the field's date output format will be respected. Links GitHub • Readme • Carbon docs PS. I remember reading about a Carbon module in a recent newsletter, but couldn't find it anywhere. Was that you, @bernhard?

In case you want it a little more simpler $pages->setOutputFormatting(false); $pag = $pages->find("template=basic-page"); foreach($pag as $p) { foreach($languages as $lang) { if($lang->isDefault()) continue; $p->set("status$lang", 1); $p->save(); } }