Leaderboard

Hello World

Here's a tip for making your global settings / global options page easily accessible in the admin, without having to create a custom process module or going to the page using the pagetree. Let's say the page name of your settings page is called "settings" and it's directly under home. Now, create a *new* page under the admin page in ProcessWire. Use the "admin" template. Call this page "settings" as well. After saving, it will now give you the option to choose which process module this admin page will utilize. Choose "ProcessPageEdit". Now you will have a link in the main navbar to this Settings page, but when you go to it, it will error saying "Unknown page" + "the process returned no content". What you need to do is make this page load the /settings/ page you originally made. Using the special "/site/ready.php" file (create ready.php if it doesn't exist), you can add the following line of code to it: if($page->template=="admin" && $page->name=="settings") $input->get->id = $pages->get("/settings/")->id; Now go to the Settings page in the navbar. Nice, easy and "official" feeling.

Because it's important. Things might not work exactly same for logged-in users, let alone superusers, as they do for guest users. Permissions, for an example, are one important consideration, and many sites also have separate login details, admin tools, etc. visible only when you're logged in. In other words: if you render a page for caching while logged in, that's a potential problem right there. How much this really matters depends on the case, of course, but it's better to be safe than sorry, especially when we're dealing with assumptions that affect a) security, and b) a huge amount of ProcessWire users out there. As long as a given site is even moderately popular, meaning that it gets anywhere between tens and hundreds of page views each day, one visitor taking couple of seconds longer to render a given page (and that would already make it an *extremely* heavy page) makes little difference. You need to consider the big picture here. While the "every visitor matters" approach is admirable, and very much true, when you put things in perspective, single page load taking slightly longer isn't going to bring your site instantly crashing down or drive your users away for good. *Don't succumb to the trap of over-optimisation.* Most likely there are a lot of other things you could do with that time that would benefit your site much more. You need to put things in perspective here. In my humble opinion you're sacrificing a lot of time to do something that won't make noticeable difference considering the big picture. If that makes you happy, then by all means do it, of course Hardware may be cheaper now than ever, but it's still far from free, and while you can run a small site for relatively cheap, you need to consider scalability too. Large and/or more popular sites require more resources, which in turn means more costs. So far I've never heard a client say "I don't care about costs at all". Quite the opposite, actually. In the end, one part of your job as a developer is keeping the costs low for the clients you work for. Again, you need to put things in perspective. User experience is extremely important, but resources matter too. Every choice you make has pros and cons, and you need to keep those in balance. Admittedly user experience is much harder to measure than resources and their costs, so the decisions are not always obvious.. What you're saying here is roughly how it works, though especially in larger use cases caching everything on each page save could literally render the site unusable. At the very least it could mean that each save action is extremely slow, which is not a good thing either. There's a lot more to cache expiration than this. ProcessWire makes it easy to use content from other pages, and output lists of pages, etc; these need to be considered when selecting which pages the cache is invalidated for. In many cases it's not nearly enough to just invalidate the cache for the page you've saved. One might also be pulling content from other sources, and outputting content that is time-sensitive (such as dates, events, etc.) Hope this helped clarify things a bit!

: Guys, this is sooooo cool !!! Having seen the modifications done to the bike, and checked with google, this is not fake, but for real !! Discharge from coding for 4 minutes and enjoy watching this => It actually starts at 1:12 .

They are pages. Look for them under "Repeaters" inside the admin page in the tree. Repeater pages are under a page with the name "for-page-1234" (1234 is the ID of the page that holds the repeater field) under a page named "for-field-123" (being 123 the id of the repeater field. You can see it o the URL when editing the field). This means that you can easily get all pages from a repeater field in a page by using the selector: $pages->find("parent=/processwire/repeaters/for-field-123/for-page-1234") Or even construct that selector dynamically when needed: $pages->find("parent=/processwire/repeaters/for-field-130/for-page-{$page->id}")

I was going to answer, but Teppo did before. Good I still would like to say that all you're questions had quite obvious answers and that you asked them in a quite rough way, in the context of being the one that's using an excellent free tool, asking these questions to the one that provides this tool to you for free (repetition intended) and takes the time to give such complete explanations to every question that comes up. Anyway, if you're worried about guests, just make sure your editors are the first guests after saving a page, by telling them to do it.

… and yet another update this time I imported "my" 4000 users as normal pages, no roles, no password, just the data. And guess what? The lister is running fine and snappy. Next up is a test how the "users" behave in the lister if I use the systems "user" template, not a custom one, maybe I can narrow down what's causing the timeout.

You don't need "home" and you need the name of the "Admin" page in it's place. By default, the name of the Admin page is "processwire" so you would want: parent=/processwire/repeaters/for-field-112/

To create a sitemap.xml you can use Pete's Sitemap XML module, or you can create a template file and page to do it for you. This post explains how to create a template to do it for you. The benefit here is that you may find it simpler to tweak a template file than a module, though either is a good solution. Here is how to do it with a template file and a page: sitemap-xml.php <?php namespace ProcessWire; /** * ProcessWire Template to power a sitemap.xml * * 1. Copy this file to /site/templates/sitemap-xml.php * 2. Add the new template from the admin. * Under the "URLs" section, set it to NOT use trailing slashes. * 3. Create a new page at the root level, use your sitemap-xml template * and name the page "sitemap.xml". * * Note: hidden pages (and their children) are excluded from the sitemap. * If you have hidden pages that you want to be included, you can do so * by specifying the ID or path to them in an array sent to the * renderSiteMapXML() method at the bottom of this file. For instance: * * echo renderSiteMapXML(array('/hidden/page/', '/another/hidden/page/')); * */ function renderSitemapPage(Page $page) { return "\n<url>" . "\n\t<loc>" . $page->httpUrl . "</loc>" . "\n\t<lastmod>" . date("Y-m-d", $page->modified) . "</lastmod>" . "\n</url>"; } function renderSitemapChildren(Page $page) { $out = ''; $newParents = new PageArray(); $children = $page->children; foreach($children as $child) { $out .= renderSitemapPage($child); if($child->numChildren) $newParents->add($child); else wire('pages')->uncache($child); } foreach($newParents as $newParent) { $out .= renderSitemapChildren($newParent); wire('pages')->uncache($newParent); } return $out; } function renderSitemapXML(array $paths = array()) { $out = '<?xml version="1.0" encoding="UTF-8"?>' . "\n" . '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'; array_unshift($paths, '/'); // prepend homepage foreach($paths as $path) { $page = wire('pages')->get($path); if(!$page->id) continue; $out .= renderSitemapPage($page); if($page->numChildren) $out .= renderSitemapChildren($page); } $out .= "\n</urlset>"; return $out; } header("Content-Type: text/xml"); echo renderSitemapXML(); // If you want to include other hidden pages: // echo renderSitemapXML(array('/path/to/hidden/page/'));

Hi folks! I'm about to add my new module FieldtypeAssistedURL to the repository. You find the source code on github and hopefully in the modules repository soon. Here an extract from the README.md: This module offers you a new field type AssistedURL Field, providing and input field for storing absolute and relative URLs. The field type adds a button to open the URL chooser dialog known from the CKEditor link feature without the tab navigation bar for specifying link attributes. Using the URL chooser dialog the editor may select URLs from internal pages or uploaded files via a search field with auto-completion, a page tree control, and a file selector control. Please feel free to post suggestions and any form of feedback here in the forums or on github. Wumbo

Words of encouragement from the Pub's amateur psychiatrist (Read best in a soft spoken, German accent) Ah, you are here because you have been reading things in this forum about pages that have left you confused, disorientated, befuddled. You thought you knew what a page was - you have been thumbing through them, folding them, studying them, wrapping things up in them and scrolling up and down them for most of your life! A page is this solid item - this great lump of data stuffed with things. But now you have come to Processwire, and everything you thought was true, simply isn't any more. For in Processwire pages are completely different - they are not great gulps of information, but tiny little things, nothing more than a link to the more interesting world of fields and templates; just a little blip of data in your huge fascinating database. Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value. It can seem crazy to use such an iconic thing like a page for such a mundane and trivial task! But don't worry and fret, don't lose sleep or pace the floor as you think the reputation of the noble page is being crushed! In Processwire, they are fulfilling their duty to the full - and the more slight the task, the more they bound up to the wall and jump up and down shouting "use me, use me!" And, as a bonus, they can even be used for content - for all that stuff you thought was a page, but in Processwire isn't! So, don't be put off by the Processwire page - use it for everything! it is much smaller than you think, takes up hardly any space at all, is well behaved and only will do its thing when it is called. In fact it is hardly a page at all .... and then again, it is also so much more!! Better now? Joss Freud

Do a post with javascript with the ID of the page to a not cached page. On the not cached page get the incremental number of the visited Page (an integer field) and save that plus 1 back to the Page that is viewed.

You can actually select repeater pages by their template: $pages->find("template=repeater_fieldName");

Thanks a lot! I didn't find that post. Thanks for you tip. Came up with this: $today = date('d.m.Y'); $events = new PageArray(); $items = $pages->find("template=repeater_dates, date>=$today, sort=date, include=all"); foreach($items as $item) { echo $item->date; echo $item->parent->title; } works fine for me

Thanks, guys. This all works great! And I can choose the label to be the title field within the repeater... ALL GOOD!

Hello Marth

Hi Richard. Guess what? The repeater rows ARE pages They are stored under the Admin area in the page tree. So they could technically be selected in a page field, but I'm not sure how the titles would be handled or how you would select for all pages if the repeater appears on multiple pages. It would probably be a bit clunky, but you might be able to get it to work they way you want if you play around with it. I think the better way to go would be using a PageTable field, and then hiding the page list somewhere out of the way in the page tree. You would have more control that way. But then you'd have to use the modal windows for updating values, which may not be what you want. EDIT: Since you can specify a field other than the title to be visible in the Page select input and all of the repeater pages that use the same repeater field are (I think) stored together, maybe repeaters would be the more elegant solution for this after all. Just keep in mind that "plain old pages" are always the more flexible and scalable option if your needs change down the road.

Julia, can you tell us about your experience with PW on that host? I removed the link from your answer, you're too young to link.

I'm using Windows at the office and my macbook at home for work. Both worlds have their pros, cons and tools I'm missing on "the other system". I'm also using conemu for quite a while and found it to be the best console for Windows (in combination with cygwin). On Mac there is a similar tool: totalconsole. I configured both to scroll down from the top of the screen on shift+^ (quake players might remember that keys and style ). My primary editor on both machines is sublime text 3 with the same setup. This makes switching systems every few hours a real no-brainer (apart from some system dependant shortcut/keybinding stuff).

Hi Webrocker, I have a site with more than 3,000 pages representing individuals which are displayed in a Lister, and it seems to handle it without issue. What is your limit set to in the Lister's settings? If you try to display all of those pages at once you will definitely have a problem. But if set to ~50 you should be good, and Lister will automatically paginate the results for you. I find that filtering the pages is still very quick even with all those potential results.

Hello kazu and welcome to the forum! If you'd like to output submenu for the current page, change the code like so: // iterate children of a current page object foreach($page->children as $item) as $item) { if($item->id == $page->id) { echo "<li class='current'>"; } else { echo "<li>"; } echo "<a href='$item->url'>$item->title</a></li>"; } And here's how to put it to the main menu: foreach($homepage->and($homepage->children) as $item) { // class name for item wrapper $class = $item->id == $page->rootParent->id ? 'current ' : ''; if($item->hasChildren()) $class .= 'parent '; // open item wrapper if(!empty($class)) { echo "<li class='". rtrim($class) ."'>"; } else { echo "<li>"; } // item link element echo "<a href='$item->url'>$item->title</a>"; // markup for possible childs if($item->hasChildren()) { echo "<ul>"; foreach($item->children as $child) { echo "<li><a href='$child->url'>$child->title</a></li>"; } echo "</ul>"; } // close item wrapper echo "</li>"; } If you like to have 'current' class for submenu items also, change the child markup of foreach loop to match with the first example.

39 bugs....come on your kidding me. You're using a free CMS/CMF wanna some important Requirements and don't want to spend little money on it.... like BernhardB wrote code it yourself or bring in some work to contribute and/or as an exchange get help from some experienced coder. I'm not a pro so i'm dependent on help sometimes, too.....but i always do it in the same order search->ask->decide (buy or search for a programmer to give a helping hand)->contribute first (testing, translating, co-working)->get help->search..... This order should not be the only right way (that don't exist) and maybe we misinterpret your post (may some wrong insistence in the !! and the short words). So sort up your requirements and think what this end result of software should do for you/or your client and at least what is this achievement of your UI Interface build with PW worth for you and/or your client....and then decide what is to do. For shure there are other options but none is fitting your requirements like Lister Pro - so i thought to adapt any other free available solution to your needs whould cost more than 39$....but this depends on your hourly rate. best regards mr-fan

From your explanations I'll conclude your new to programming, at least in php. I'd would advise you to first try some basic entry-level php tutorials, before moving on with processwire, as you won't get far without a basic understanding of php as programming language. To create those php files I would suggest you to use a real programming text-editor (notepad++ is quite nice for beginners, but there are plenty of other ones). This will get you syntax highlighting an other useful features, which help you to find the inevitable errors you'll be making in the beginning. About your more specific questions. The folder to put your files into is …/site/templates/ from the root of your processwire installation. I don't know where you installed processwire, but this can be done locally as well as on a server. As long as a template – created in the backend interface – doesn't have a corresponding template.php file in that folder you cannot view that page in the frontend as processwire won't know how to display the data you filled out in the backend. So about your new page, which did display data: I think that you created a new page of a template, that was already preinstalled by processwire. Those preinstalled templates do also already have corresponding template.php files in place and therefore show up in the frontend. The guide is there to tell you how to move further by creating own templates, that look different from what's already installed. P.S. Please do not open new threads if you've already one about kinda the same issues. Also please try to avoid writing in uppercase text.

Yes this is possible. However since preventing it is not "natively" supported by ProcessWire, you need to trick it a little bit. This can be done in many ways, but here's one wire()->addHookAfter("ProcessPageEdit::buildForm", function($e) { if(!$this->input->get->modal) return; $form = $e->arguments(0); $field = $this->modules->get('InputfieldHidden'); $field->attr('id+name', 'ProcessPageAdd'); $form->append($field); }); Providing a native way would be very simple since the closing of the dialog is controlled by a single variable called closeOnSave in InputfieldPageTable.js. You could also modify the buttons and whatnot. Also submitting the form in a regular way (e.g. by hitting enter) also prevents the modal from closing. The example I provided tricks the InputfieldPageTable.js to set closeOnSave to false by just adding a hidden field to the form with the ID "ProcessPageAdd" (https://github.com/ryancramerdesign/ProcessWire/blob/576a5d30153f045daa94a136a6ba981650632b26/wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTable.js#L52). Edit: Added a litte more information

Whether cached at view or save, t's exactly the same amount of work either way. Though caching at save potentially creates more work. Whether we're talking about template cache or ProCache, there are a few reasons why it's better to do it upon first view, rather than upon save. Pages are only cached for guest users. If we performed an automatic cache after a page save, it would be within the context of the user editing the page. This is not a context we want to cache. You want the page to be cached within the context of a real page view, not from something automatic or behind the scenes. This ensures that any other modules that are part of the render process also get to participate. You may save a page multiple times in a short period of time (don't we all?). If it gets cached on every save, you are potentially using a lot more resources than if it was just cached the first time it was viewed from a guest user. If we regenerated on save rather than view, that would be a whole lot of extra saves that have to be performed in the system (a save uses a lot more resources than a view). Keep in mind cache files automatically expire after some period of time (defined by you). You can't rely purely on a save() for knowing when data is stale or not, as your site may be pulling data from multiple pages or other resources.

Nikoka, Can you edit /site/config.php -- locate the line that says "$config->debug = false;" and change it to true. Then try to load a page in your site. You should get a more specific error message. I am guessing that there was some change at the server that affects PW or the database index needs a repair or something simple like that, but let me know what you find. OR, you can check /site/assets/logs/errors.txt and see what it says at the bottom of it. For security, you can't access this file from your web browser, so you'd have to do it from the file system (FTP, shell, etc.) Please reply to let me know what you find, Ryan