Leaderboard

A couple more options... At the top of the file for the template of pages you are including inside another page: if(empty($options['pageStack'])) throw new Wire404Exception(); if($page->url == $_SERVER['REQUEST_URI']) throw new Wire404Exception(); A related thread:

There have been a couple of these sorts of articles lately: https://80x24.net/post/the-problem-with-amp/ https://shkspr.mobi/blog/2016/11/removing-your-site-from-amp/

Quote: "Let's say that I'm using a _main.php file that serves as my primary document markup, like used in our current default site profile. It contains the main document markup, like this:" Ryan normally calls it _main.php (see: $config->appendTemplateFile = '_main.php') and this is where the skeleton of the HTML goes. This skeleton is extended and changed by writing code in the template files assigned to public pages, such as home.php. Otherwise you got it right I think.

Hi all. For a while now been wondering how many would be interested in a backend and frontend shop catalogue built on top of PadLoper? I've previously spoken to @apeisa about this and his take is that there are no plans to develop PadLoper in this direction but he's happy to support such efforts. The gist of the backend shop catalogue is to provide one place (think ProcessModule) where you can manage your PadLoper products - add, edit, delete, track sales, etc without having to set up the underlying structure yourself. The frontend would be like a shop/webstore profile, a frontend cart basically, that's customisable. The shop would be 100% powered by PadLoper. This means that to use the 'shop catalogue' would require that PadLoper is installed. These are just loose ideas at the moment for a pro module. This might or might not see the light of day depending on feedback. Anyway, would love to hear thoughts, thanks.

Hi @Eric7, Welcome to ProcessWire and the forums. Have a read here:

There's a couple of approaches Unpublish you block pages: You will still be access them via the API with include=all in your -Page template. You would have to handle 404s in this case Redirect: Redirect access to block pages to -Page. SEO issues? Etc...(I've gone totally blank but there should be another strategy, I think )

Hey @LimeWub, I found a soultion to your question. If you go to the template being used by slideshow and navigate to the "Access" tab, you can achieve what you are after. In my case (for the test), I simply unchecked view pages for guest, and selected "Redirect to another URL" which allowed me to keep the page from being accessed by someone not already logged in with the proper credentials.

Hmm...Tracy would have caught it, I believe .

Did you remember to activate pagination for the template of the page where you are using pagination?

# and everything after that are technically not part of the site structure, but fragments in the (same) page (see links to #id). I'd imagine that site crawlers treat them as different pages, because of all those single page apps miss-using that for actually different pages.

I see. Then the answer is yes. The "skeleton" of the markup is in _main.php, just like in the case of "site-default" profile.

v026 brings another "syntactic sugar" because the sweeter the better {1038|get:httpUrl} {$contactPage|get:title} {$gallery_items|getParent|get:httpUrl}

Hi OpenBayou, did you read this ? https://processwire.com/api/modules/markup-pager-nav/

I see - this should definitely be possible (using {all}) and page:1 or a relative/absolute link to your domain root. I will take a look at this when I'm back from work this afternoon.

You know, I don't use IRC, and I don't particularly like chat channels for technical things. So if y'all move information about processwire to IRC I won't ever see it, which only diminishes processwire's usefulness to me. It's already bad enough having no overall documentation and relying on forums for learning, siphoning off expertise to IRC will only make it harder to learn this system. $0.000000000000000000002

Done: https://processwire.com/about/chat/ I included a sensible (I hope!) intro to say why people should consider using the forums for most questions and answers, and the chatroom as a place to hang out or get help in a hurry if someone's there.

Hello I opensourced my Telegram bot called "Voxgram" https://github.com/NinjasCL/voxgram Now you all have an example of working with the Rest Helper and the Python Telegram Framework (I think the my python code is a mess) but anyway here you go :).

To be honest I'm not sure this will make things considerably easier to grasp for (new) people. I can already see people trying to use it as replacement for a templating language. I really don't think it's worth it just to not have a $main/$sidebar variable, especially for new people. I'd imagine it's more confusing than helping. I'd much rather would like to see a guide dedicated to examples of direct output -> delayed output -> separation business logic / view logic -> templating engine (twig/blade), what the benefits are and how to switch between them (e.g. same output in different strategies). Especially the third one is a kinda pet peeve of mine, because I went into the rabbit hole myself, where markup was so deeply coupled with processwire api stuff, that it was a nightmare to change anything. For me this seems to be more in line with your motto of teaching people how to fish.

The Fotomediale is a annual festival of photography for children's and youth photography in Freiburg, Germany. This small website provides information about the festival and its workshops. Because of the topic, this site is very picture heavy. Almost every page contains it own set of images displayed in the background. The images cycle through automatically, but you can also use the buttons on the edges (or if you want arrow keys on your keyboard ). If you want to see the images, you can collapse both the navigation and content area. The transitions between pages were made with Ajax and pushState, but you can also access them directly via their URL. To handle the large image backgrounds, all of the images are lazy loaded using lazysizes. The registration form was created using the API. www.fotomediale.de Modules used: ProCache Markup Sitemap XML Email Obfuscation (EMO) Tracy Debugger Regards, Andreas

Happy New Year! Looking back over the last year, it's been a really great year for the project, and wow has it gone fast! In this post we'll look back at some of what we've accomplished over the last year, and–more importantly–introduce and review our 2017 roadmap. Today we've also released version 3.0.47 dev, which doesn't add anything new feature wise, but does contain several optimization and bug fix comments. https://processwire.com/blog/posts/roadmap-2017/

Never mind, I found the errant code - PT2H changed to PT0H and all is well. Thanks!

Not sure about that one. Could be something to do with your server's time. It's hard to tell without knowing exactly how he's pulling in the facebook feed. Please start a new topic/thread regarding that question, thanks.

Thanks for the responses guys! I got it! (not sure how I had missed it earlier...) Anyway, I've attached the settings I'm using for the block. Very similar to what @louisstephens suggested Thanks so much for pointing me to the right direction!

I'm using this in a module public function init() { $this->addHookBefore("Pages::saveReady", $this, "cacheContent"); } protected function cacheContent($e) { $page = $e->arguments[0]; if($page->template->name == "templateYouWantToCache") { $cache = $this->cache; // delete the old cache $cache->delete("cacheName:" . $page->id); $cache->get("cacheName:" . $page->id, $cache::expireNever, function() use($page){ // code you want to cache $content = $page->title . "<br>"; $content .= $page->body; return $content; }); } } And in the template // since the cache already exists this will just get the cache // but in case no cache is found it generates it $cache->get("cacheName:".$page->id, $cache::expireNever, function() use($page){ // code should be the same as the one that preloads the cache $content = $page->title . "<br>"; $content .= $page->body; return $content; });

Have pushed a fix; please update to 1.5.46 and let me know if it works.

Unfortunately, I'm not able to determine why the httpUrl is being appended to the root URL. I'll need to look into this further, but it has something to do with preg_replace_callback which is at fault here. The method in question is supposed iterate through each source wildcard, applying any replacements to the destination. But as their are no wildcards in the destination, it should be changing anything. When you supply / as your destination, Jumplinks converts this to page:1 so it can get the full URL to that page. As it loops over the source, it's somehow adding that URL twice to the destination. I need to head out now, but will be back in a bit to investigate. I do know that Jumplinks 2 is not succeptible to this as it uses a completely different method, powered by FastRoute. I'll try to continue work on that Jumplinks 2 today. (To everyone who's been waiting in anticipation for it, I'm so sorry it's taken so long.)

Hello Forum members. I just wanted to confirm with you PW gurus on here that i got the thinking behind regions in the latest blog post right: https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/ So my understanding from the quick glance of the article is that if i were to use the new regions functionality it would in simple terms work like this: The referenced HTML in any of my other page template files would be inserted at the designated place in the home.php template file instead of replace it with all HTML in that page template file that was requested ? And the home.php template file would become sort of a View, that used HTML from the other templates files to change acording to the needs? So that i would only need to put the HTML that changed in my other page template files and have the "full" HTML markup in the home.php ? I just wanted to see if i got it right. Thx in advance. ProcessWire Official Markup Regions Documentation (New 2022-09-08) https://processwire.com/docs/front-end/output/markup-regions/

Thank you for the help getting my head around this Now that i grasp it, i can see how usefull this could be in the future

Doug G's concern was that documentation moves to IRC, not if people want to discuss their cats and dogs on #processwire, or did I misunderstand you? I don't think anyone sees the forums or chat as a solution for lack of documentation. Please treat this lack as a problem of its own and do not muddle it with communication/user support channels.

Looks like a genuine bug fell in here somewhere - all redirects with Page IDs appear to be broken on my side. Investigating now.

I wrote wrong, i mean home.php not main.php for the "/" home path.

Hi @EyeDentify I think you got it totally right, at least this is also my understanding of it. EDIT: I missed this one: "...full" HTML markup in the home.php" This "full" markup is supposed to be in "_main.php", but I suppose it was just a mistake that you referred to "home.php".

Did u see this as well?

yes kongondo i realy need this! i believe this is what many customers need and is going to be the next big step! please let me know if you develop this module.

Hello @MilenKo, I am glad you are making progress. Haven't read everything in this thread, but a here a few notes: In HTML5 there is an aside element available, especially for sidebars like yours. Using delayed output you could prepend for example a _init.php file in your site config containing often used variables. In the default site profile there is for example a variable for the homepage, so you can use this instead of $pages->get('/'). You could make your tags dynamic using a page field and store the tags in a dedicated page tree. Regards, Andreas

Is it possible to redirect all 404 hits to the homepage? I've just tried ".*" -> "/" and it appends the full url like this: http://domain.com/http://domain.com/ Tracker: I think most devs wouldn't like this feature but I'm not against it, provided it's OFF by default.

i can show a simple module to do this, the only thing delaying me right now is figuring out how to prevent the publish - I guess if you hook into saveReady, then you can check to see if the page status is published (since the request would have that set) and then if the image requirements are not met, you would set the status to unpublished, overriding the request; haven't tested this yet but will do so soon.. ok here is a try - note that once you install this module, you can keep adding stuff to it by adding your hooks to the init and then your functions below.

flydev was amazing

Hello guys! i'm here to solve the mystery of seavuel.com ! I'm the owner. I am planning to release a commercial site-profile for a hotel-website on codecanyon.net What do you think about the idea/project? I mostly think of it as a long-term project with regular updates and a low-price.

Actually, @Robin S' approach isn't a bad one either. I've just pushed 0.0.8 to GitHub that overrides some native methods of FieldtypeDatetime and adds InputfieldDatetimeAdvanced to work around some explicit integer casts by the core WireDatetime class. I haven't been able to test it extensively yet, of course, but it does look like everything works on 3.0.34 (high time to upgrade my 3.x test system now). I'm not completely sure if the module upgrade will run smoothly. In the worst case, switch the field back to a regular Datetime field, uninstall the module and WireDT, then re-install the Fieldtype module.

Sorry, it's apparently been too long since I tested the module with newer PW versions (turned out I was using an early 3.x release, but too much has changed since then), but I'm working on it. It's giving me a bit of a headache still, but I'll try to have it fixed over the weekend.

I'd like to contradict. The admin themes we have really need a css overhaul and cleanup (and maybe docs), but a prebuild framework is in my opinion not the way to go. Because it's not developed internally every special usecases the admin does have will feel like a hack to the framework. Framework + custom workarounds will always be bigger (more code / more maintainence) than a customized solution. It's also a matter of branding. True, one can add custom colors to UIKit, but in the end it's probably still noticable enough that it's UIKit. Also consider all the markup in core and 3rd party modules, which are needed to be supported the the admin theme. I doubt any prebuild framework is bendable enough to support that level of custom markup coming from our side.

It would just depend on what's being worked on. I generally don't push stuff to GitHub until I know it's solid. If working on something that's going to take a couple weeks to get to that point, then I'll avoid having it appear on GitHub because it wouldn't be ready. Since plans for 2017 include a focus on some things that may go beyond the usual weekly timeline focus, I'd say that weekly activity on the GH repo would reduce a lot when these things are being developed. Of course, activity on the core code wouldn't be reduced at all (likely increased), but the frequency of commits that appear on GitHub would be reduced. Plans are to keep it roughly as-is. But since it's now ~130 posts, it's time to add a few more things like categories, related posts, next/prev post links, etc. I also want to upgrade it to be more guest-author friendly, so that it includes authorship information like we have in the tutorials (example).

I can only concur that this has been a great year. It was nearly impossible not to get infected by the momentum of PW's development. Love (that's an understatement) the JS $pages API plan, and the pages export/import function could even be a solid base for native staging support, just by hooking into the proper PW actions and filling a staging actions table. You're absolutely right, @apeisa, PW is much more than just a brilliant website platform. Our intranet site really does some "heavy lifting", consolidating information from the ERP system, the DMS, personnel and operational time keeping, financial accounting and a few proprietary databases. That way, it also serves as the middleware for a big, distributed test run database. Like Sense, it drives a few chained workflows, e.g. for bridging the feedback gap between dunning proposals and our sales managers. All our intra-company course scheduling/booking runs on PW too, including supervisor approval, and it was surprisingly easy to implement. HR was over the moon with PW's ease of use. For 2017, we're planning a site that provides our customers with all the publicly available documentation for the machines and plant parts we sold them, requiring just a QR code scan on their side. Setting up a working (UIKit styled, multilingual) prototype only took me a few hours and really impressed our sales guys If 2017 is going to be anything like this year, it's going to be a blast. Thank you @ryan! A happy, healthy and inventive new year to everyone!

Great blog post Ryan, thank you! Great year behind and even better coming! What comes weekly news, I think maybe @teppo and PW Weekly could report interesting new stuff from dev branch - instead of full blog post by @ryan each week? Also I think what would really help PW as a community project is that modularity would be more easily seen from code repositories also. I mean separation of /wire/ from rest of the stuff, keeping admin as own project and making several core modules as their own projects (although they could be "essentials" that would always be installed with ProcessWIre). What comes to Avoine, I hope I found time to write case story about how we use ProcessWire as backend solution to our member register platform Avoine Sense. Sense was released early 2016 and it already hosts about 10 member registers that together hold about 150 000 members. Feature-wise Sense already has newsletters, custom reporting tool, invoicing, model based templates/fields, background jobs, client specific procedures build by chaining actions (ie. create excel, connect ftp, deliver file and finally send sms to admin), full read/write REST API with Oauth2 authentication, mobile application, embeddable login/edit forms etc... ProcessWire has been amazing platform for our application development (currently we have 4-5 developers working on it). I strongly encourage that you all consider ProcessWire as a viable alternative for serious application development also. It is perfect platform for building dynamic websites, but it is also pretty brilliant platform for application development!

I had to hit the 'refresh' button a couple of times for changes to show up (rather than uninstalling )

Sorry for the delayed answer, Pierre-Luc! Been busy with other stuff and this totally slipped my mind. What you've described there wasn't really possible without direct SQL queries until just a few moments ago. I've just pushed to GitHub an update to VersionControl.module (0.10.0) that adds new $page->versionControlRevisions() method. This isn't properly tested yet, but something like this should work: // current value of field 'headline' echo "Headline for current revision: {$page->headline}<br />"; // value of field 'headline' in previous revision $revisions = array_keys($page->versionControlRevisions(2)); $page->snapshot(null, $revisions[1]); echo "Headline for previous revision: {$page->headline}<br />"; // return Page to it's original (current) state $page->snapshot(); echo "Back to current revision: {$page->headline}<br />"; Since snapshot() returns Page object to given revision or point in time ($page->snapshot($time, $revision)) you'll want to make sure it's back to it's original state in case you're going to make changes and save the page -- otherwise the revision you fetched with snapshot will be returned from history once you save the page. $page->versionControlRevisions() returns an array of revisions for current page and can optionally take one param, $limit, to fetch only that many revisions if more exist. It's return value is in the form of array([revision] => [timestamp]), i.e. array(4 => '2014-01-01 02:00:00', 3 => '2014-01-01 01:00:00') etc. so in order to get just the revision IDs out of that I'm using array_keys() in the example above. You could probably also do something like this, if you want to make sure that Page doesn't get accidentally returned from history (this'll consume more memory, though): $revisions = array_keys($page->versionControlRevisions(2)); $page->previousVersion = clone $page; $page->previousVersion->snapshot(null, $revisions[1]); echo "Headline for previous revision: {$page->previousVersion->headline}<br />"; Not sure if you're still working on this, but this kind of feature felt useful so I'm glad you brought it up..

Try removing baseUrl from your renderPager options array. If you set it to an empty string, as you currently have, it will ignore your URL segments. The documentation says the default is "blank", which could lead one to believe it means an empty string or null. I quickly peeked under the hood of the module, and it seems the default is not really empty/blank; rather, it seems to detect the full current page URL including segements, so you can just omit it completely in the options.

$value = $pages->find( "title%=$q" ); $pa->import( $pages->find( "template=abc, …|…|…=$value" ) ); $pa->import( $pages->find( "template=abc, title%=$q" ) ); What should that do? You have to explaing a little more for a short minded like me. I have an example that shows how to construct your own pager using the PW PagerNav class: // include paginator class require_once($config->paths->MarkupPagerNav . "PagerNav.php"); $pa = new PageArray(); $res1 = $pages->find("template=xyz, title%=space"); $res2 = $pages->find("template=abc, title%=hal"); $pa->import($res1); $pa->import($res2); // config paginator $baseUrl = $page->url; $limit = 4; $start = ($input->pageNum - 1) * $limit; $total = $pa->getTotal(); $pagerNav = new PagerNav($total, $limit, $input->pageNum); $pager = $pagerNav->getPager(); // construct paginator markup foreach($pager as $link) { if($link->pageNum == $input->pageNum) $class .= "on"; if($link->type == "separator") $item = '…'; else $item = "<a class='$class' href='{$baseUrl}page{$link->pageNum}/'>$link->label</a>"; $pagerMarkup .= "<li>$item</li>"; } // output paginator markup echo "<ul class='pager'>" . $pagerMarkup . "</ul>"; echo "total: $total<br/>"; echo "start: $start<br/>"; echo "limit: $limit<br/>"; echo "<ul>"; foreach($pa->find("start=$start, limit=$limit") as $p){ echo "<li>$p->title</li>"; } echo "</ul>"; Also in my ever growing gist examples https://gist.github.com/somatonic/5420536