Leaderboard

This week we take a closer look at the useful new page export/import functions that we’re currently building into the core: https://processwire.com/blog/posts/a-look-at-upcoming-page-export-import-functions/

I've been a bit like the proverbial plumber with a leaky tap, with a rather ugly site myself, but I've had a period recently with very little work, so I thought it might be time to give my own site Create IT a refresh. I've got more work to do on it, but it's enough of a step up that I'm not totally embarrassed by it now. My site was running on a CMS I've developed myself since 1999 using an obscure language Mivascript, that was actually quite popular at the time, and my first exposure to a server scripting language. To put that in context, the first version of Wordpress only came out in 2003, and to be honest my code looks quite messy in the light of modern programming best practice. I've decided I'd rather focus on adding functionality and content than maintaining an entire CMS myself, and I love Processwire for its speed and flexibility of development. I had to import my existing content which was in a mySQL database. Having written the system myself, I knew the data structure well, so the issue was how to replicate the functionality. My old CMS was started before the days of SEO and security got a great deal of attention so I had urls like index.mvc?article=6. I had to come up with a safe way to redirect these to knew Processwire URLS. The Jumplinks module came to the rescue there, as when I'd imported my data, I'd already imported the old page ids into a field in processwire, so it ended up being pretty easy to provide automatic redirects from the old URLs with just a single jumplink using a selector. The other thing I wanted to do was use Bootstrap, but customise it without creating a mess of overrides. AIOM+ came to the rescue here, with its built in ability to compile LESS files. Rather than messing around with any third party LESS compiler, I could just put the Bootstrap source directly into my project and include the LESS files directly. Processwire never fails to impress how quickly and efficiently it enables often quite complex things to be done.

Hi @arjen, Thanks for the reply. I have changed the code to match $this->wire() for fields, fieldgroups, and templates, and I am still getting the same results. [edit] Robin posted before I finished entering this reply. @Robin S, Thanks for the test. Yes I have to remove the orphaned fields manually when the uninstall fails to do so. I changed the uninstall to your code source and everything is correctly removed. I also left the field name and template name case unchanged for this test, but I'll change everything to lower-case to match the existing naming convention in the database. Even though the Add New Field option allows upper- and lower-case, and template names match the case of the php template file or whatever you enter for template names without a file. The only thing I can think of as to why it works now and not before is some typo present in my naming that isn't showing up in phpstorm. I agree with the lack of documentation too. I've spent three days writing this module and troubleshooting this install/uninstall oddity. I have copied so many forum topic links into module comments for my reference that it should be a book! Thanks for y'alls help. I appreciate it.

Hey, I've used ProcessWire for a while now but not made an appearance in the forum yet I just wanted to share the solution to a small problem I came across with Let's Encrypt (free SSL service). Let's Encrypt SSL certificates need to be renewed every few months to remain active. My web host does this automatically but needs access to a folder named ".well-known", which ProcessWire blocks by default because it starts with a dot. This results in a 403 error. To work around this, just add the following line to your .htaccess file, around line 150: RewriteCond %{REQUEST_URI} !^(/\.well-known) It should be the first condition in the section titled "Access Restrictions: Keep web users out of dirs that begin with a period". I also ran into another problem. Let's Encrypt accesses mail.example.com which is redirected to www.mail.example.com because I enabled the redirection in my .htaccess fie. So we need to exclude the mail sub domain from that rule using the following line as the second condition in the www-redirection section (around line 160): RewriteCond %{HTTP_HOST} !^mail\. [NC] I know it's quite a specific problem but maybe it'll help someone Googling the issue. I was curious, is there any way of redirecting to the www-version without having to exclude all your sub domains? The only way I can think of involves explicitly writing out your domain name in the .htaccess file and redirecting whenever the %{HTTP_HOST} starts with that name. But obviously that would lead to a loss of generality.

ok sure - i will try and make this short and as relevant to this topic as possible, but ultimately this does relate to the age old discussion of how to implement configurable pages that has many topics and long discussions on the forum, so this problem/solution is somewhat based on researching and trying every option and arriving at this as the currently best option for creating turnkey websites: The problem: You want to implement a user interface that allows site editors to create and update page sections; in some cases these page sections may be orderable and in other cases you might want to restrict the ability of the editors to change the order. You may also want the user to be able to change from one type of section to another similar type of section with ease and not having to have some complex instructions for how to do that. One example might be a callout - perhaps there are 3-4 different types of callouts, one is a full width, and another is a split box. Another option might be a hero section where options include static image, video, or slider. The user should be able to switch the type of section type without having to create a whole new section and copy their content and prefs to the new section. They should not be required to go to the settings tab and change the template and have to go through that process. Based on these requirements, any interface that asks the user to specify the section type (template) prior to adding the new section will not work - this means no repeaters, and no page tables that use multiple templates. The solution i use is to let users add a new section to the page table, and on the section template, they can select the type of section to use (a field). The 'section type' field is a page reference (single select), which pulls the options from a hidden branch of the page tree. The sections for any page are output by checking for the existence of a corresponding php file (where the selected option's page name corresponds to the file name of the php file) in a directory in the templates folder. Each section's php file renders the section, and is a completely self contained file that includes all of the necessary code to render the section. I use a theme engine that also allows any section to inject dependencies into the header or footer, and set/modify other theme options/variables. Based on your outlined fields, you have mostly common field requirements between your sections: Title [title] Subtitle [subtitle] Multiple background images [images] Links [links table or repeater] Title for area [title] Paragraph of text [body] Background image [images - use first one] Bullet points [body] Image [images - use first one] Links [links table or repeater] List of feature with a title/description for each [features repeater] Image [images - use first one] Text [body] Link [links table or repeater - use first one] News section title [title] Title [title] Description [body] Link/link text [links table or repeater - use first one] Description [body] List of images/links [possibly repeater, or images extra with url field?] The micro contexts system would simply allow you to change the field labels, descriptions, notes, order, visibility and required based on the page reference selection for the section type...

@rick, when I copied your install method to a test module and corrected the template names to lowercase all the templates and fields were created and assigned without problem. Not sure if the uppercase in the template names would have made a difference - I didn't test that, but probably best to avoid it in any case. Try this for an uninstall method: public function ___uninstall() { // remove fields from fieldgroups and delete $fa = array( 'field1', 'field2', 'field3', 'field4', 'field5', 'field6', 'field7', ); foreach($fa as $f_name) { $f = $this->fields->get($f_name); if(!$f) continue; $fgroups = $f->getFieldgroups(); foreach($fgroups as $fgroup) { $fgroup->remove($f); $fgroup->save(); } $this->fields->delete($f); } // delete templates $ta = array( 'template1', 'template2', ); foreach($ta as $t_name) { $t = $this->templates->get($t_name); if(!$t) continue; $this->templates->delete($t); $this->fieldgroups->delete($t->fieldgroup); // see http://cheatsheet.processwire.com/templates/methods/templates-delete-template/ } } In your testing, if you have been deleting templates via the API and not removing their associated fieldgroups you may have orphaned items left in the "fieldgroups" database table. You'll have to delete those using phpMyAdmin before you can create new templates using the same names. It's surprising that the $fieldgroups API variable is almost completely undocumented. It really should be added to the API reference.

First off I would suggest to call ProcessWire from one type of call. You use wire('fields') and $this->fieldgroups. I am not sure if $this will point to the module class or ProcessWire. You could check this out using a barDump in Tracy: bd($this); I would stick to $this->wire() so adding a new template: $this->wire(new Template); Or getting other stuff: $this->wire('fields'); $this->wire('templates'); $this->wire('etcetera'); As an alternative you could check out this example.

True. To avoid this add... if($this->config->ajax) return; ...at the top of the function. Alternatively you can add a linked stylesheet to the <head> instead of adding the styles directly to the Page Edit source. Something like: $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $page = $event->object->getPage(); // match to the relevant page(s) however suits you if($page->template->name == 'my-template') { $this->config->styles->add($this->config->urls->templates . 'admin-custom/my-styles.css'); } }); This is a good way to go if you package the function and stylesheet together into a simple module.

Hello fellow ProcessWire-ers. Here's another little project I've made: http://godesign.pt/ GOdesign is a, you've guessed it, design agency, in Portugal. I've been doing quite a few projects with them where they design, then I build. It's portuguese only, but it's just a design portfolio and little more. It was built with a modular approach that I've been applying to some projects lately. Building a project page you get a repeater, where at first you select the block type, and then the respective fields appear. That way the admin can do a block with a single image, two side by side, text on the left, text on the right, video, and so on... The approach is great, and makes me wonder how cool it would be to be able to create templates in PW that can be used in repeaters. Like creating pages, but in a repeater-like field instead of the actual tree.

Hi, As far as I know, since ProcessWire 3.0.29 we have RewriteRule "(^|/)\.(?!well-known)" - [F] there by default. See: https://processwire.com/blog/posts/pw-3.0.29/#summary-of-added-pull-requests

Hi @szabesz, I have dissected many modules, and used the method described in the related post to gather the properties, which is how I came to create the example. The problem is that the one api-created template functions correctly while the other (with the exact same code) does not. There is something wrong, different, out of order, or whatnot, that I am missing. Of course starring at the problem for hours narrows my tunnel vision even more. I need another pair of eyes, and more time during the day. Where does that line form? haha

@psy thanks for that! As soon as I have my schema's ready I'll post here as well. Thanks again.

==

@ngrmm just bumped the version to 0.3.2 including a little fix so it show up again, please let me know if it works @CalleRosa40 Just checked on pw 2.8.62 and 3.0.62, cookies are created as expected..have you checked console in dev tools? it should show something..and it could be interesting to check network tab in dev tools, too, to see if it actually sends the ajax request

@cjx2240 here's my 2cents: - for those configurable pages, i use a pagetable, in combination with the Micro Contexts module... this allows me to have 1 template for all of those items but to hide/show fields and change their order, descriptions, labels, notes and even conditional hide/show based on the 'type' of widget (e.g. section). this is working really well for me because on 'turn-key' site, you never know how many custom sections you will need to build, and it would be a drag to have to keep creating new templates; in this system you just need to add each section as an option (e.g. page reference for the section type) and then load the corresponding file using some code like this: if(count($page->sections_pt)) { $sections = ''; foreach($page->sections_pt as $section) { if(file_exists('./partials/sections/section-' . $section->widget_type->name . '.php')) { $viewBag['widget'] = $section; $sections .= "\n" . wireRenderFile('./partials/sections/section-' . $section->widget_type->name, $viewBag); } } $content = $sections; }

Limit Table works by hiding elements within the inputfield in Page Edit. You can make a custom solution for Repeater Matrix (or any inputfield) by using your browser tools to find the class/ID of the elements you want to remove, and hiding them with a display:none CSS rule. Add the custom styles selectively to Page Edit via a hook: $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $page = $event->object->getPage(); $out = $event->return; // match to the relevant page(s) however suits you if($page->template->name == 'my-template') { $out .= " <style> /* Put your custom CSS here */ </style> "; $event->return = $out; } });

@bernhard - sure, let me know what context this applies to - for example if you are viewing the help tab, or help modal on the page editor, or showing the help topic in the process module? I haven't worked with panels yet, so if you have any further details on how and when that comes into play, let me know how to replicate the issue etc..

Version 1.0.0: [New] The module contains a Fieldtype Select Options Countries:

I know this is a pretty old thread, but every time it comes to creating a Repeater through the API, I get LOST. @thetuningspoon's function illuminates a LOT of what happens behind the scenes when a new Repeater is made through the GUI - but I just keep wishing it was as simple as: $f = new FieldtypeRepeater(); $f->set('name', 'repeaterTest'); $f->add($repeaterField1); $f->add($repeaterField2); $f->save(); Because that isn't technically possible without setting the Fieldgroup or Template that will be used by the Repeater first, right? At the end of the day, I think we should improve the docs for Repeaters (https://processwire.com/api/fieldtypes/repeaters/) to include a section on creating a Repeater from scratch through the API so that this process is more easily understood. I am always referencing several Forum posts and parts of the docs in order to get through the spaghetti - having everything in one place would be great. Otherwise it would be awesome to have some functions as a part of the FieldtypeRepeater Class that cut down on the amount of API calls one needs to make in order to create one of these. Just my 2 cents.

Hi, here is a very useful tool that check your images in websites against responsiveness: https://github.com/ausi/respimagelint

https://processwire-recipes.com/recipes/resetting-admin-password-via-api/

Thank you so much apesia, soma and adrian. @soma and @apeisa - I followed your advise. Thanks again now it is working fine (happy). @adrian - Yes adrian I put news-pager-index.php file under template directory. Just to recap: if we need use external template file other than the template name we have to use altFilename property. In the normal scenario we can use name property if the template file name and template name were same. Here is the working copy thanks to processwire and friendly community members. It might be helpful to newbies like me. class NewsPager extends WireData implements Module{ public static function getModuleInfo() { return array( 'title' => 'News pager', 'version' => 001, 'summary' => 'News pager template', 'singular' => true, 'autoload' => true, ); } public function init() { //todo add some listeners } /** * Install the module * */ public function ___install() { // new fieldgroup $fg = new Fieldgroup(); $fg->name = 'news-pager-index'; $fg->add($this->fields->get('title')); // needed title field $fg->add($this->fields->get('body')); // needed body field $fg->save(); // new template using the fieldgroup and a template $t = new Template(); $t->name = 'news-pager-index';//Used different name other than file name /* * altFilename property will accept file-name or file-name.php * or even $this->config->paths->templates . 'file-name.php' * Note: template file needs to be placed under * template directory */ $t->altFilename = 'news-pager-index-file';//name of the template file which is under tml dir. $t->fieldgroup = $fg; // add the field group $t->save(); } /** * Uninstall the module * */ public function ___uninstall() { $templateNeeded = $this->templates->get("news-pager-index"); $fgOld = $this->fieldgroups->get('news-pager-index'); if ($templateNeeded->getNumPages() > 0) { throw new WireException("Can't uninstall because template been used by some pages."); }else { wire('templates')->delete($templateNeeded); wire('fieldgroups')->delete($fgOld); } } }