Leaderboard
Popular Content
Showing content with the highest reputation on 08/19/2020 in all areas
-
In the midst of something else right now, so just a quick overall impression: I like where you're going with this! A tutorial type getting started section has been on my todo-list for a while. Not sure if this is that, or perhaps a "light version", or something? Anyway, I'll give this a bit more thought once I've got some free time, definitely a good starting point ? Edit: just wanted to add that I've been working on a new release for Wireframe. It's going to be a pretty big update, and after that's out I should have some time to revisit the docs.3 points
-
Hi @teppo finally did some more testing, this was my experience: Installed the module, smooth Created default site structure, smooth Set alternate template file for home.php, smooth Empty frontpage --> what now? https://wireframe-framework.com/getting-started/ stops at this step! Ok, it does not stop, but it leads to https://wireframe-framework.com/docs/ -> this is all great informations, but it does not help getting a quick grasp of how to output something on the frontpage... Please don't get me wrong. Your docs are great, but for me (and maybe others) I think some small improvements can make the experience even greater. Maybe something like this (based on my efforts from today): --- Here's a rough, unpolished tutorial for getting started with wireframe and getting the concepts on the road: Follow https://wireframe-framework.com/getting-started/ until the end Set alternate template file for home.php Create /layouts/default.php and visit the homepage --> you'll see the default layout <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Default Layout</title> </head> <body> <h1>Wireframe default layout</h1> </body> </html> Congratulations, that's your first layout! Now add some php variables: <p>My name is: <?= $view->myName ?></p> Of course, why should the layout know the name? We need a controller that tells the view what value is in the myName property! Create /controllers/HomeController.php <?php namespace Wireframe\Controller; class HomeController extends \Wireframe\Controller { public function myName() { return 'Bernhard'; } } What about my favourite CMS? <p>My favourite CMS is: <?= $view->cms ?></p> <?php namespace Wireframe\Controller; class HomeController extends \Wireframe\Controller { public function myName() { return 'Bernhard'; } public function cms() { return "ProcessWire"; } } Ok, I got it - and that's great stuff! ? Now set the alternate template for "basic-page" to "wireframe". Visit a "basic-page" site (eg the 404 page) and you'll see the default layout: The variables are empty, because the HomeController is only loaded on the home template and that's for some good reasons. Read about views in the docs: https://wireframe-framework.com/docs/view/views/ Partials to the rescue ? We modify the default layout: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Default Layout</title> </head> <body> <h1>Wireframe default layout</h1> <?php include $partials->name ?> <?php include $partials->cms ?> </body> </html> And the partials: // partials/name.php <p>My name is <strong>Bernhard</strong>.</p> // partials/cms.php <p>My favourite CMS is <strong>ProcessWire</strong>.</p> Let's make that dynamic! // name.php <p>My name is <strong><?= $name ?></strong>.</p> // cms.php <p>My favourite CMS is <strong><?= $cms ?></strong>.</p> // default.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Default Layout</title> </head> <body> <h1>Wireframe default layout</h1> <h2>Viewing template "<?= $page->template ?>"</h2> <?= $partials->name(['name' => 'Bernhard']) ?> <?= $partials->cms(['cms' => 'ProcessWire']) ?> </body> </html> Note that the partials are now echoed instead of included and we added the line that outputs the template of the viewed page! Note though, that partials are really just for simple chunks of code. At best even static ones. As soon as things get more dynamic, start using components instead of partials: https://wireframe-framework.com/docs/view/components/ What do you think?3 points
-
Alternatively, @franciccio-ITALIANO, given that you are on a local site... echo $pages->get(2)->name; in any template file of a page accessible in the frontend should do it.3 points
-
@franciccio-ITALIANO You can get it from DB in the "pages" table. Row where id = 2.2 points
-
I'd recommend Laragon too. And WinSCP instead of Filezilla. If you have the budget, get a good IDE as well - my recommendation would be PHPStorm by JetBrains. In order to profit from IDE hints, you can use the pages()->find syntax instead of $pages->find (just an example - I don't have time right now to search for the docs or blog/forum posts explaining this - here it's called "API variables as a function"). You can get rid of an FTP client altogether, if you configure PHPStorm to automatically upload files upon save, which is a big time-saver. These days, I'm sure most (all?) of JetBrains' functionality can be had with VSCode as well, but I'm not sure if there are still significant differences (probably means installing a few plugins).2 points
-
I agree that the concept of output formatting could be better documented - questions about it come up regularly in the forums. @ryan, it would be helpful if there was a page explaining output formatting in the "Getting started" documentation. The key thing to take onboard is that if you are going to be setting and saving values to a page, you must set output formatting to false before you do anything relating to that setting and saving. In your case, you are getting the value of a field that you will later modify... /* get the images object array for the Page */ $myPageImg = $page->images; ...before you have turned off output formatting for $page. If you do... /* get the images object array for the Page */ $page->of(false); $myPageImg = $page->images; ...then when you save $page, the changes you make to $myPageImg will be saved to the field value. Another thing: assigning a field value to a variable like this ($myPageImg = $page->images) when you intend to later modify that field value is probably not a good idea. You can get away with it for an images field because the value of an images field is an object, and objects in PHP are assigned by reference. But the same would not be true for any field whose value is not an object, e.g. a text field. When you assign the value of a text field to a variable you are assigning by value, meaning that changes made to the variable are not simultaneously applied to the field value. To illustrate... $page->of(false); $images = $page->images; // $images is an object assigned by reference $images->add('https://www.site.com/image.jpg'); $page->save(); // Changes to $images will be saved to $page->images $page->of(false); $headline = $page->headline; // $headline is a string assigned by value $headline .= ' foo'; $page->save(); // Changes to $headline will NOT be saved to $page->headline So in your case, there's really no benefit to assigning $myPageImg = $page->images near the start of your code - it just increases the chance of confusion. You'd be better to make changes to $page->images directly: //... $page->of(false); while($file_headers[0] == 'HTTP/1.1 200 OK'){ $page->images->add($file); $affixnum++; $file = 'https://www.site.com/pictures/' . $page->title . "_" . $affixnum . $extension; $file_headers = @get_headers($file); $page->save(); echo $file . " added. <br />"; } //...2 points
-
Ok all work I discover it, thanks! :D1 point
-
It doesn't hurt to do this, but most of the time it's not necessary. When you change the output formatting state for a page, this only lasts for the current request. On the next request PW is going to automatically set the output formatting state depending on the context the code that's executing - to quote the docs, "By default, output formatting is turned on on the front-end of the site, and off on the back-end (admin) of the site." So probably the only case you would need to explicitly turn output formatting on after you have turned it off is if you had some code in a template file that was setting values to $page, and then later in that template file you are also outputting $page values to the front-end. But I think that would be quite rare, because most of the time when you are using the API to set page values you'll be doing that from a script separate from any template file that's outputting to the public front-end.1 point
-
Althought Laragon is a great choice. You can also use Docker if you want ? Here I made a simple config for PW https://github.com/joyofpw/docker ?1 point
-
There's an open issue in the old PW repo about the inability to sort by the "sort" subfield of a Select Options field: https://github.com/ryancramerdesign/ProcessWire/issues/2049 Looks like the "title" and "value" subfields don't work either. I've opened a new issue here: https://github.com/processwire/processwire-issues/issues/1231 @rash, in the meantime, if sorting by title is critical to your site perhaps the best thing would be to replace your Select Options field with a Page Reference field. When you've created the Page Reference field and added it to the relevant templates you could execute some API code in the Tracy Debugger console to transfer the Select Options field values to the Page Reference field (match option title to page title).1 point
-
+1 for Laragon ?1 point
-
I tried them all => go for Laragon => fast => easy config easy ui https://laragon.org/why-laragon/1 point
-
@NooseLadder ... or you take the easy way and get you a full copy of Laragon! It has everything you may need or not. Including One-Click-SSL-Certificates in your local dev environment to use and test full https protocol. And much more. ? see what others mean: site:processwire.com/talk laragon1 point
-
Hi @NooseLadder, and welcome back! There are a number of xampp related posts on the forum that will help get everything set up and running. You can find them searching google like this: site:processwire.com/talk xampp Filezilla would be used to copy (sftp) files to a production server. You might use whatever IDE you prefer to access your localhost document root until such time as you want to go live. Hope this helps.1 point
-
You should also take a look at Repeater Matrix https://processwire.com/store/pro-fields/repeater-matrix/1 point
-
Have your tried sorting by the value instead? See Separate Option Values. If you have defined only titles so far, you can just add the values without having to change existing pages (since the values are stored by ID). Not entirely sure, but sorting by value might work (sort=direction.value). In any case, I have also found that the Select Options fieldtype is kind of lacking in selector support, and searching / sorting by values and titles does not always work. I now prefer custom page templates with page reference fields in most situations for this reason, they are way easier to use in selectors.1 point
-
I believe the option field is set up as the following: id=name|Title. You are trying to access a Title that doesnt exist, so you would need to add to your existing set up like: 1=north|North 2=west|West 3=south|South 4=east|East I was mistaken after rereading the docs (sorry about that). It is set up by id=title by default, but you can add a separate title to the value (my apologies).1 point
-
Everything is possible in ProcessWire. ? For example, you could create a "max_children" integer field and add it to the template of any pages you want to limit the children of. Then use this hook in /site/ready.php: $wire->addHookAfter('Page::addable', function (HookEvent $event) { /** @var Page $page */ $page = $event->object; // If page has the "max_children" field, and the field isn't empty, and the number of children is at the maximum... if($page->hasField('max_children') && $page->max_children !== '' && $page->numChildren >= $page->max_children) { // ...then don't allow child pages to be added $event->return = false; } }); But this is not to say it's the best solution, just that it's possible. ?1 point
-
Thx, I pushed a fix for this by rounding width and height directly in getBlurhashDataUri1 point
-
I discovered Wireframe on Sunday after exploring the GitHub repo for the ProcessWire Composer Installer project that you mentioned in the latest PW Weekly. The documentation you've written for Wireframe is just awesome ? - engaging, comprehensive and clear. I have a short question and a long question... Does it make sense to use Wireframe together with Markup Regions in any way, or would a developer choose Wireframe or Markup Regions but not both? The long question relates to what you said here: I take this to be a reference to the superiority of a MVC approach versus the "default" approach of mixing business logic and UI logic together in a PW template file. I'd like to hear more of your views on this because you didn't talk about it much in the documentation, probably because MVC and the separation of concerns is discussed in plenty of other places around the web. But I was wondering if you think a MVC approach is always the way to go, or if is something you would weigh up the pros and cons of taking into account the parameters of each specific project, e.g. the scale and complexity of the project, if a team will be working on the project, etc. Personally I use Markup Regions and don't use any separation of business logic and UI logic into different files or folders. From time to time I think about changing to an MVC approach because so many people seem to recommend it, but when I weigh it up I don't see enough advantage versus disadvantage for the kinds of projects I work on. But maybe I'm overlooking something so I'd appreciate your comments. The main benefits of MVC as I understand it are... 1. If you have a team of people working on a project, maybe with different skill sets (e.g. a front-end dev and a back-end dev), then it lets each person focus on the parts that matter to them. For example the front-end person can focus on the view file without having to see any business logic which might distract or even be unintelligible to them. This totally makes sense to me and if I worked as part of a team this by itself would make an MVC approach worthwhile. But in my case I do everything alone from start to finish - design, front-end, back-end. 2. The business logic doesn't "belong" in the same file as the markup - it's better to keep it separate and it makes it easier to update a site. This seems more contentious to me, and perhaps depends on how much business logic there is. If I have some variable that I'm using within the markup I find it very handy to have the definition/construction of that variable present alongside its usage in output. So I'm not left wondering "what was it that I put into $related_products?" and needing to navigate to some other file to find out. Now if there were heaps of business logic it might start to feel like clutter within the markup, but when I look at the template files for my projects in most cases there's actually very little business logic present. Maybe that's partly because PW is quite elegant in that you can do a lot with a few lines of code, and partly because most of my projects are not very complex. But even if I do have a lot of business logic I find that placing it at the top of the template file is no problem at all. If I need to work on it I'd rather just scroll up than open another file, and I can use my IDE to collapse any blocks of code that I don't need to focus on. Would you say that MVC is an approach that is more suited to complex projects rather than simple ones? Things like layouts and partials that are offered through Wireframe are cool, but those are also possible with Markup Regions (layout = _main.php) and built-in PW methods (partials = $files->render). I have no doubt that Wireframe is a powerful tool, but do you see it as being the right solution for all projects or just some projects?1 point
-
Do not agree with you, @bernhard for a couple of reasons. 1. Choosing ProcessWire over WordPress or some other more popular solution is a hard decision. It is often made because of this forum friendly support before one finds the beauty and power of the system. 2. Every answer we post here helps someone who googles for it later. And even answering the same questions later in time helps to prove the answers still exists and there are people still caring to answer. And often there are more new ways to solve the already solved problem, so the got to be mentioned in this forum. I can see @Nvim came here to learn about ProcessWire, to compare it with other solutions he knows about. Just maybe in a year or two he (or she?) will be the author of a new e-commerce module for PW, who knows)) If he does not stop here, the discovery of ProcessWire may become the beginning of one of the most exciting adventures for him (her?) as it was for me and so many others here, who perfectly know and have used systems like WordPress, Drupal, Joomla or MODx.1 point
