Leaderboard

Function Allows all admin-side text areas to auto-expand as they are used. Description Following on from tpr's mini-tutorial, I went ahead and wrapped it up as a module. I'm re-posting it here in the module's forum and will submit it to the module repository to prevent it from becoming one of PW's "ghost" modules - modules for PW that exist on github (or elsewhere) and have a relatively obscure link from the forum or a blog post somewhere else. Links The module on Github. The module in the module repository. Version History 1.0.0: Initial release.

If your week starts on sunday $d = strtotime("today"); $start_week = strtotime("last sunday midnight",$d); $end_week = strtotime("next saturday",$d); $start = date("Y-m-d",$start_week); $end = date("Y-m-d",$end_week); and then filter your pages like this: $results = $pages->find("datefield>=$start_week, datefield<=$end_week"); where datefield is whatever date field you are trying to filter.

Thanks for the input, guys. So here's what I ended up doing in case anyone stumbles across this in the future: I found a post by Ryan via search which explains how to set up 301 redirects via .htaccess in PW (I ran into the error which is mentioned there as well). You can shorten Ryan's rule there by using “[R=301,L]”, but other than that, that's how it works. I now have about 50 “plain” rewrite rules (redirecting foo.html to /bar/) and about 10 using a regexp. I don't notice a performance hit (I have no way of measuring properly, though; it's shared hosting), also 2 people working at hosting companies have assured me that RewriteRule should not affect performance (on a properly configured Apache).

Greetings, Christophe: I see where you're at with this! For a long time, I've been emphasizing the framework aspects of ProcessWire, and I have even made direct comparisons between ProcessWire and Laravel and CodeIgniter. I use those "other" frameworks from time to time, and I am always struck with how I can really do the same things in ProcessWire, but in less time, with more fun, and feel like I am part of a better community! Along these lines, check out this adventure... -> https://github.com/hettiger/larawire Thanks, Matthew

I read this today and I had to leave a comment that I was surprised that ProcessWire wasn't listed http://enews1.websitemagazine.com/q/GQHrt4sSbvpmSnbdz04dmYi1NrvF1N_P5r4tMHaRJ3-7-dKGhUTURRhbb

The topics I linked to should be able to help you (@see my edited post above yours). The code at the first link is pretty straight forward and solid... Edit: If you don't want to use a function and you'll have no more than 2 levels, you could probably get way with this: <div class="collapse navbar-collapse navbar-right"> <ul class="nav navbar-nav menu navbar-right"> <?php $out = ''; $root = $pages->get("/"); $children = $root->children("limit=7"); $children->prepend($root); foreach($children as $child) { $out .= "<li><a href='{$child->url}'>{$child->title}</a></li>"; if($child->numChildren) {// @note: you could do some more checks here; foreach($child->children as $c) { $out .= "<ul>"; $out .= "<li><a href='{$c->url}'>{$c->title}</a></li>"; $out .= "</ul>"; } } } echo $out; ?> </ul> </div>

Just tried the AutoGrow CKEditor plugin and works fine (PW 3.013, CKEditor with Lightwire theme). You can add options like these to the "Custom Config Options" to the CKEditor PW field settings: autoGrow_onStartup: true autoGrow_bottomSpace: 20 Or to "/site/modules/InputfieldCKEditor/config.js" if you prefer: CKEDITOR.editorConfig = function (config) { config.autoGrow_onStartup = true; config.autoGrow_bottomSpace = 20; };

This is a simple addition to the admin to automatically resize textareas according to their content. It doesn't work with CKE fields tough. All it needs is a hook in ready.php + copying autosize.min.js to the "site" folder (or elsewhere if you feel so). /site/ready.php: // autosize textareas in admin $page->addHookAfter('render', function ($event) { if ($this->page->template != 'admin') return; $autoSizeJsUrl = wire('config')->urls->site . 'autosize.min.js'; $js = <<< HTML <script> var autosizeTextareas = document.querySelectorAll('textarea'); if (autosizeTextareas.length) { $.getScript("$autoSizeJsUrl", function () { autosize(autosizeTextareas); }); } $('.langTabs').on('tabsactivate', function(event, ui) { var textareas = ui.newPanel.get(0).querySelectorAll('textarea'); if(textareas.length && window.autosize && window.autosize.update) { autosize.update(textareas); } }); </script> HTML; $event->return = str_replace('</body>', $js . PHP_EOL . '</body>', $event->return); }); Edit: fixed updating textareas on activating language tabs (heights weren't updated)

As mentioned before, I went with RewriteRule in .htaccess, which works well. I'm not sure anything else would have worked here because in addition to being multilingual, the original site also used different page titles in both languages, i.e. /foo.html in German could have been /bar.html in English. I have only skimmed the thread you linked to, so I'm not sure if Jumplinks could manage that.

I've accomplished that using the module Jumplinks. See this thread and let me know if it helps: https://processwire.com/talk/topic/8697-jumplinks/?p=113416

Those tools don't support multi language.

Perhaps not yet, but it could become... They talk about Laravel, October CMS, using a framework or plain PHP... it could be an opportunity to present ProcessWire (which has advantages of a CMF/CMS and advantages of plain PHP, etc.). I'm open to put this post elsewhere (I wasn't sure where to put it).

I don't think this is related to processwire but the environments you are using. What processwire version are you using ? This way of moving from dev to production is not recommended as it doesn't check your production environment. Install a fresh new installation of the same processwire version on the production server and see if this installation goes error free. This will tell you if processwire matches up with the production server environment. After that, replace the site folder on the production server with the site folder from the dev server. Empty the database on the production server and import your database sql file from the dev server. See how that goes.

Find attached the first Alpha Version of the Module ProcessSetupPageName with Multilanguage Support. I tested it under various circumstances and it is doing fine with one exception: Until now it doesn't work together with 'Page Name Extended' (since PW 3.0.12) which allows UTF8 Page Names. Module requires PHP >= 5.4.x Download from here: EDIT: Removed link, download last version from here: https://github.com/kixe/ProcessSetupPageName/archive/master.zip Would be nice if you could test it and give a feedback to me. Thanks in advance.

See Ryan's comments here: https://github.com/ryancramerdesign/ProcessWire/issues/432

Since you asked for 'created' you can swap datefield in the example by @Alxndre' for created (we also have 'published')

If you take a view on what day a week starts on, you can use the PHP function strtotime() to get the timestamp of the last time that day happened and format it using date() to get it as a string for use in your find/filter selector. For example, if you decide a week starts on Monday, then this should get you a value you can use in selectors... $when = 'Last Monday'; $timestamp = strtotime($when); $date = date('Y-m-d', $timestamp); //echo "The date $when was $date\n"; Untested, YMMV.

Maybe it would be possible to simply require a forum account to be able to submit drafts (or in the beginning to create user accounts manually for the people wanting to help). It doesn't have to be open for everyone at anytime in my opinion.

Thank you very much for your answers @kongondo, you helped me a lot Also, an excellent solution for bootstrap navigation: https://processwire.com/talk/topic/5680-bootstrap-3-navigation-with-multiple-leveltier-fix/?p=55504 Again thanku you Processwire is awesome

Maybe you are looking for WireHttp::download() ? https://processwire.com/blog/posts/august-2014-core-updates-3/#new-download-capabilities-in-wirehttp-class "...First it attempts to use cURL..." Never used it though, just guessing. Sorry if ti is not the one you need.

I decided to look into this. It's definitely related to PW 3 vs 2. For 3.x you need this instead: $hooks = array_merge(wire('pages')->getHooks('*'), wire('hooks')->getAllLocalHooks()); In Tracy I just used a conditional based on whether: wire('config')->version is >= 3

Hi PW Fans, I´m developing a little webapp in cooperation with an local tax consultant. Not really styled so far, the focus in this moment is setting up the functions and logics. General needs: - accounting - rudimentary client organization - invoice management - creating invoices - multi user possibility with different page-permissions Done so far: - accounting The app meets the needs of german bookkeeping for small business. Also it could be used for the so called "Kleinunternehmer" by just setting a checkbox. Well, the next thing to be done is a export function for "Datev" a german tax software. If somebody is interested to beta test the suite just put your hand up and I will send a copy (Attention: no multilanguage. Everything is in german). Some screenshots:

https://processwire.com/talk/topic/1036-markupsimplenavigation/?p=8998 First post of this thread there's a link to an gist with an example to output bootstrap like html. But it's just an old example I worked out back then. I never used bootstrap so can't tell if it's still working with newer versions? (one of the reason I avoid frameworks )

Now available as a module on Github.

In case someone knowledgeable enough wants to give an answer here: http://programmers.stackexchange.com/questions/314496/open-source-project-framework-or-core-php (I've found this indirectly while reading the book jump start php environment.)

Don't use SessionHandlerDB module. Or uncheck "Track IP addresses in session data". Check what you get from $session->getIP(true). It might be related to IPv6 (https://github.com/ryancramerdesign/ProcessWire/issues/1596).

Thanks for the answers adrian, Christophe and teppo! I also think "blocks to create unique page structures on the fly" is the right answer. However, in this case Concrete5 is NOT one step above ProcessWire in this area, because we are talking about two completely different concepts regarding frontend development, so they should not even be compared in this manner I think. Maybe that is why I didn't get close to decoding this sentence

I'd say that it's definitely about blocks: concrete5 makes it quite easy to create unique page structures on the fly. It's not like we couldn't do something similar with ProcessWire, but in the case of concrete5 it's a built-in, original core concept, and thus it's no surprise that they excel in this area. Some of their UI's still look really ugly and amateurish, but putting that aside, it's a great product in many ways. That being said, personally I'm not such a huge fan of this strategy. I'll admit that it does empower the content editor and give them a lot of sway on the way the site looks, but that's actually a double-edged sword: sometimes it works out just fine, but sometimes the site ends up being a total mess. Especially for sites with a bunch of content editors and a lot of content, a well planned structure and information architecture is a must I remember looking into concrete5 a few years ago, the main reason being the way they handle page blocks. Their concept is nearly identical with our old in-house CMS (page blocks, content areas, all of that) and when we decided to move on, concrete5 seemed like the obvious choice. For various reasons we ended up with ProcessWire instead, and I'm glad we did.

The Module is in the scope of the class, so you need the wire scope. All ProcessWire variables have those functions so things are reachable. That's for the wrapper. The bodyHTML method can be used in a template, so it's up to you what you do there.

I agree. And I'd like to suggest "Publish + Add new" to "Publish + Add Another" as it is a bit more clear in suggesting: "Another of the same template". One more thing, maybe it's a good thing to change the button to be like this example attached. Not advanced users may find it easier to understand.

jonithlnljani how ? wolud makes.infinite ploop no ? or how u.say in englich. circle jerkey or.recurses no ending.samasaras likes when trimmer beard in.bathroon w 2 mirror & u see millonions of willys

Welcome to the forums! The $user variable is already taken in the globally accessible wire/fuel object, so don't use that. from your module you can set the var as follows (in your before page render hook): $this->wire->set('foo', 'bar'); in your template you can call it like any other wire/fuel variable (like $user, $page, $session etc), since the they are passed to templates automatically: echo $foo; // 'bar' More on THE fuel/wire: https://processwire.com/talk/topic/3876-using-fuel/ Soma:

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

For anyone else who runs into this issue, a quick, temporary fix is to hack the LanguageFunctions.php file. For all three functions in there, you'll need to wrap each with a check to make sure the functions haven't already been declared. For example, the first function: if (!function_exists ('__')){ function __($text, $textdomain = null, $context = '') { ...snip... } } My best guess is that this not recommended as a permanent solution since it may cause issues with WordPress. And of course, ProcessWire upgrades will overwrite the hack. Best solution? Don't use Wordpress. For reference, here's Ryan's awesome Blog Profile for ProcessWire. http://modules.processwire.com/modules/blog-profile/

Yep, basically what Martijn said. Go to Setup -> Fields -> Add New Field Add a name and label for your field and change the Type dropdown to File Under the Details tab you will see allowed filetypes and PDF is in the list - alter the list to suit you Change Maximum Files Allowed to however many you want - perhaps 1 in this case? Save your changes Add to your template That's it really.

Here's how I setup 301 redirects in my .htaccess files. These redirect directives should go probably above ProcessWire's, but after the "RewriteEngine On" directive. Here's a 301 redirect from one directory to another (/old/ to /new/): RewriteRule ^old/?$ /new/ [R=permanent,L] Here's rewriting /old.html to /new/dir/: RewriteRule ^old.html$ /new/dir/ [R=permanent,L]