Leaderboard
Popular Content
Showing content with the highest reputation on 10/22/2016 in all areas
-
This week we've got a new dev branch version with several updates which we'll merge to master soon. This post also includes a useful recipe on how to log all outgoing emails sent from your site. https://processwire.com/blog/posts/processwire-3.0.38-core-updates/5 points
-
I usually use url parameters to create/remove such fields (eg. ?name=myModule&action=addFields and &action=removeFields). You can open two browser tabs and just hit F5 in each to add/delete.2 points
-
Hey guys, I'm new here, and I'm loving ProcessWire and the community spirit so far. We're just about to start using ProcessWire for our new clients requiring PHP solutions. Moving in a Rails direction, structure in our projects is becoming more and more of a necessity. As such, I've tried to employ some MVCish techniques in creating a boilerplate for ProcessWire for getting projects going quickly. One of the primary goals of this structure is to make it easier to separate logic from markup, and to prevent tags from being split over templates. Keeping `body`, `html`, and structural markup open and close tags in the same file greatly reduces cognitive overhead, and reduces opportunities for mismatching tags to exist. This approach also reduces duplication, and is great for keeping files small, focused, and organised. The main structure of the boilerplate is well defined, and ready to use in production. The repo is available here: https://github.com/fixate/pw-mvc-boilerplate (link updated 2014/01/17) Structure Although not completely MVC (using classes for controllers feels redundant, there are no models, and a full MVC approach will require a fair amount of customisation), it is heavily MVC inspired. Additionally, the structure is an extension of Soma's delegate approach. File structure: ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── errors ├── partials // markup not specific to any particular template ├── views // layouts specific to a template ├── _init.php // used to load global and template-specific controllers ├── main.php // the 'alternate template' for all templates . . . **NB: This structure has largely been updated and improved - see the UPDATE - 2014/01/17 at the bottom of this post! Controllers Controllers hold template specific variables and functions. There is also a global controller responsible for making global fields, such as SEO fields, available everywhere, as well as being responsible for the actual delegation. Template logic should be handled as much as possible from within controllers. Views Views are responsible for handling markup and output. Views have available to them both the global controller, and their own controller. Logic should be, as much as makes sense, handled in a controller, with the view pulling the results in for display. Partials Partials hold markup not specific to any particular template on its own, such as the `<head>`, header, navigation, scripts, or footer. As with views, it is best to keep these as logicless as possible. _init.php _init.php is responsible for making controllers available to views. Controllers are only included if they exist - sometimes a template-specific controller may not be necessary, in which case you won't need to create one. main.php main.php is the default layout (equivalent to layout/application.html.erb in Rails) into which everything is rendered. This file has been kept small deliberately to let partials and views manage more fine grained markup structures, while this file serves the main site structure. A call to render_view(), defined in global-controller.php, is responsible for delegating rendering to the view of the current template. Additionally, there is a constant defined in globals-controller.php useful for serving different assets depending on if you are working in a local environment, or if your site is live. This is useful for preventing Google Analytics from running in a dev environment, or for using unminified scripts for debugging. This boilerplate eliminates the need to do much configuration when beginning a project, apart from having to change each template's alternate template in the admin. I hope this will assist in quickly organising and developing new projects! ------------------------------ UPDATE - 2014/01/17: ------------------------------ All files for rendering are postfixed with .html.php in good ol' Rails fashion. main.php has been removed in favour of mvc.php. mvc.php requires config/boot.php which then handles which controllers, views, etc. are used the main layout is now found in views/layouts/application.html.php - like Rails again. partials are now kept inside views/ each page template can have its own optional controller, or simply inherit functionality only from ApplicationController ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── core // core mvc files - base controllers etc. (project specific stuff does not go here) ├── errors ├── views // folder for template files, layout files, and partials ├── layouts // application layout ├── partials // markup not specific to any particular template ├── mvc.php // the 'alternate template' for all templates . . .1 point
-
I love images Really! Thanks for the update, especially for the docs, now it is high time to read it. I've been trying to follow the development, but you have added so much stuff that it is hard to keep up with you1 point
-
v083 is up with a small little tweak to Misc to open the Home/View site link in a new tab (topnav). More importantly the documentation is updated with almost 30 images so it should be visually more appealing1 point
-
Hm, well - regarding "thousands of pages": There was this blogpost once: https://processwire.com/blog/posts/find-and-iterate-many-pages-at-once/ about the new findmany() function: https://processwire.com/api/ref/pages/find-many/ - but from my understanding, this only applies if you really want to retrieve and do something with that many pages. In an encyclopaedia application you will of course search inside of manymany pages but you mostly only retrieve one or a small subset. I would assume (though I am not an expert) that the findMany() case does not apply here. The actual link will actually be the other way around. The synonyms don't know anything about their relation to someone else. That's why I was referring to the tagging: You have the entries and they point to synonyms: plane → aircraft, ufo, flying saucer, … but with your application logic you can create that link. Assuming: entries plane car fork ... synonyms airplane automobile ufo flying saucer ... Then, for example you get a query for "airplane": <?php $incoming_query_term = "airplane"; $entry = $pages->get("name=$incoming_query_term, parent=entries"); // see if there is an entry if($entry instanceof NullPage) { // no entry? $synonym = $pages->get("name=$incoming_query_term, parent=synonyms"); // get the synonym $entry = $pages->get("synonyms=$synonym, parent=entries"); // get the entry which has that synonym in its synonyms page field // eh, should also work, combined and short: $entry = $pages->get("synonyms=[name=$incoming_query_term, parent=synonyms], parent=entries"); } I guess your tagging should work kind of the same? edit: Mh, reread your original post - I think it would be more complicated to have the synonyms in a field. Maybe it feels stupid to have extra pages for the synonyms but I think it is the better solution. The downside is maybe that database queries take longer - but since processwire has the findMany() method now I don't think it is any problem to handle that many pages. One consideration might be helpful for rendering the list: Without this you would have to retrieve the entry for a synonym for every synonym by code like $pages->get("synonyms=THIS_SYNONYM.id") ... You could link from the synonyms to the entries by giving them a page field, too, where you store the linked entry. You could create that link with a hook automatically every time a synonym is created, so that every synonym has an entry-link. The problem here is to keep the links coherent. But then it would be very easy to render the list: Find all entries and all synonyms to one PageArray (probably paginated then, findMany?). Sort by name. Render them accordingly to their type: Entries become direkt links to the entry, synonyms become that "aircraft → plane" output.1 point
-
The module url, eg. http://domain.com/admin/module/edit?name=myModule&action=add_fields The use $this->wire('input')->action == 'add_fields' .... . No need for template.1 point
-
Thank you. It works perferctly.1 point
-
update: i still (or again) think that this feature would be very helpful! for example i need to create some fields via api for my new module. it would be great to test this via the console. one window to create the field, one to delete it. that way i could test things very quickly without losing track. what do you think, @adrian ? edit: i solved it by implementing 2 methods in my module and then calling them from 2 different browser instances (1 on default browser, 1 on incognito) like this: // default $m = $modules->get('mymodule'); $m->tmp_create(); // incognito $m = $modules->get('mymodule'); $m->tmp_delete(); the methods look like this: public function tmp_create() { $log = $this->wire->log; $field = new Field(); $field->type = $this->modules->get('FieldtypeTextarea'); $field->name = 'test'; $field->save(); $msg = "field {$field->name} successfully created"; $this->message($msg); $log->save('rocknotes', $msg); d('done tmp_create'); } public function tmp_remove() { $this->deleteField('test'); d('done tmp_remove'); } i like this approach even more because i can write the code in my IDE now sorry for my monologue1 point
-
Hi, "echo $entry->categories->title; //not working" Does not work, since "categories" is not a Page object, but a collection of Page objects, a PageArray: http://processwire.com/api/arrays/page/ What you need is the code snippet you used on the page but this time the collection can be accessed via $entry, because you named it as such: foreach ($entry->categories as $category) { echo "<a href='{$category->url}'>{$category->title}</a>"; }1 point
-
Or just untick "Enable CSS source maps" in the Console settings (F1 in the Console).1 point
-
That seems to be the more fitting solution.1 point
-
I'd rather like to see the reference to the map being removed from the css file. Sass maps are there for development, but not for production usage.1 point
-
Hi leegold, I know exactly what you mean: Ive been there ! So from the same experience I can say with Processwire it is like coming home, and can promise you that your search for the perfect cms is over, processwire is simply it, stick with it and you will see for your self. The first thing you should do from here is to make your self familiar with that Processwire is a decoupled system and everything "is a page" ! The back end is really a page tree that can hold anything. Took me a while but once you get your hand on this and start to connect it with the api of processwire you will see that everything makes so much sense. Processwire is unique because with it you dont make websites "the cms way" but your way ! Just start making a couple of websites following processwire tutorials: https://processwire.com/docs/tutorials/ And here are some goodies to start with: https://processwire.com/api/templates/ https://webdesign.tutsplus.com/tutorials/how-to-install-and-setup-processwire-cms--cms-25509 http://processwire-recipes.com/ http://processwire.com/talk/topic/2296-confused-by-pages/ http://processwire.com/talk/topic/5667-help-a-noob-get-started/page-2#entry55820 https://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/ Welcome to Processwire.1 point
-
An article from April describing a strategy for deploying PW using Robo task manager http://antonioandra.de/articles/deploying-processwire-with-robo/1 point
-
I've had the go-ahead from @ESRCH and have now pushed this to the module repository. Repository Link1 point
-
Basicly you have one folder for templates by default. This is configured to be in "site root" + templates/ You are able to overrule this setting from the site/config.php as follow $config->urls->templates = $config->urls->site . 'mytemplates/'; $config->paths->templates = $config->paths->site . 'mytemplates/'; A trick i use a lot when developing in a live site is to duplicate the template folder and rename the copy to templates-dev. Then make sure i have an other domain (or subdomain) pointing to the hosting, for example dev.domain.ext and for the live site on www.domain.ext With the following code i can access the development templates while normal visitors keep getting the default templates. /** * Development: Alias for template-dev access * */ if($_SERVER['HTTP_HOST'] == 'dev.domain.ext') { $config->urls->templates = $config->urls->site . 'templates-dev/'; $config->paths->templates = $config->paths->site . 'templates-dev/'; $config->debug = true; } You can make up all kind of 'rules' to go by when overruling the templates folder with php from the config.php file. For example serving the same site with different layout and code for mobile on m.domain.ext /** * Mobile: Alias for template-mobile access * */ if($_SERVER['HTTP_HOST'] == 'm.domain.ext') { $config->urls->templates = $config->urls->site . 'templates-mobile/'; $config->paths->templates = $config->paths->site . 'templates-mobile/'; }1 point
-
Hi Adrian, Thank you so much. Yes that is it. Here is the working piece : /* Create new field using API */ $field = new Field(); // Set type as FieldtypeTextarea $field->type = $this->modules->get("FieldtypeTextarea"); // Set inputfield as InputfieldTinyMCE. Thanks to Adrian $field->set('inputfieldClass', "InputfieldTinyMCE"); // name of the field $field->name = 'footer_region'; // set label $field->label = 'Footer region area'; // Save ! $field->save(); Thanks again Adrian & the community1 point
-
You might want to have a look at this module of my coworker which does exactly what you've mentioned: It separates the "view" (mostly logicless) templates from something called "data providers" (controllers) and adds some logic to define reusable chunks. Plus: It also plays nice with this one which lets you use twig for the view templates.1 point
