Leaderboard

I've read this a few days ago. While of course you could implement this behavior, this is what I missed in ProcessWire for a long time. A field like this matrix thing, where one could freely combine different preselected content-types. In the current dev version you could mimic this with PageTables, but it's still not quite as convenient, as it's in Craft, because most of the information is hidden in the page-lightboxes. Also you do have the hassle to always provide a pagename for each contentblock. I use PageTables on my own website at kobrakai.de/sense/, where I can freely arrange video-, image or issuu-content. But it seems so overkill to have a page / lightbox for only an image or a video-/issuuid, just to be able to freely change the order of the apperance. To me the shown matrix-field is kinda like the perfect mixture of repeaters and PageTables.

You are not already screwed if your writable files aren't executable or don't represent files that can blow up the site. Obviously, the intention is that nobody else can write to the writable files, but the reality is when designing a system we have to plan for the worst. Your environment and my environment may be well secured, but I try to think about the bigger picture out there where there are a lot of insecure environments. Security is #1 when it comes to ProcessWire. What are secure permissions and what are not is dependent on the server and not something we can detect. A security best practice is to get everything important out of any writable files on the file system and not have any single writable files that could take down the whole system. Meaning, I think it's acceptable for cache files, image and other independently served assets to exist as writable files, but the files we're talking about here are definitely out. Another reason we can't detect this stuff is because there are plenty of hosts running phpsuexec and the like where apache runs as the user and everything is writable by default. This tends to be okay, so long as there isn't also a copy of WordPress somewhere on the account. Basically, what are the right permissions for a given site comes down to the server, environment and host, and not ProcessWire. If someone is able to write something to some file on your account, that does not imply they can access the DB. That "someone" is usually an automated script and not a real person, or it's one of your account neighbors on a shared webhost. One of the things that regularly falls in my lap (for better or worse) is to fix hacked WordPress sites. Rarely has the DB been touched, while most of the writable file system has to be quarantined. I disagree. There is a direct connection of field schema to the data represented in the DB. Template files are not coupled to fields like that because you are talking about your code, not the system. You have to make your changes independently regardless of where they are stored. Changing a field doesn't automatically change a template file. But changes to fields are an end-point in terms of how they reflect on the database. I've run out of time for today so have to stop. But I want to be clear that PW is not going to regress to storing this stuff on the file system. I recognize there is a benefit to some developers in having files they can version control or migrate independently. I personally would find the drawbacks to far outweigh the benefits (I have to support this project for a large audience), but understand why some find it desirable. Like I've mentioned, I would consider in the future mirroring the data to files that you can version control and selectively migrate in the admin. I believe that would bring the benefits of what's been discussed here, without the drawbacks.

I've updated this module to version 3 which adds the ability to use headlines as page breaks and adds support for several shortcodes.

I hope that you like it.

Ohh wallpapers! I have one too!

The oranje already dancing:

TemplateEngineFactory The main idea of this module is to support the developer separating logic from markup. This is achieved by turning ProcessWire templates into controllers which interact over a new API variable to template engines like Smarty or Twig. The TemplateEngineFactory ships with a default engine "ProcessWire" that uses the internal TemplateFile class to render the templates (some of you may already be familiar with this concept). However, the module is constructed in a way that any template engine can be used, implemented as separate modules. Please check out the readme on GitHub for more details how it works: https://github.com/wanze/TemplateEngineFactory ... or in the modules directory: http://modules.processwire.com/modules/template-engine-factory/ Implementation of Smarty: https://github.com/wanze/TemplateEngineSmarty Implementation of Twig: https://github.com/wanze/TemplateEngineTwig Implementation of Jade (by dreerr, thanks!): https://github.com/dreerr/TemplateEngineJade How does it work? A controller (aka ProcessWire template) can have an associated template file which contains the markup to render. The folder where those templates are stored is configurable for each installed engine. If the Factory finds a template file with the same name as the controller, an instance to access the template is provided with a new API variable (called "view" by default). Over this API variable, you can set the dynamic variables that should be rendered. Hopefully the following example makes things clearer: // In controller file: /site/templates/home.php if ($input->post->form) { // Do some processing, send mail, save data... $session->redirect('./'); } // Pass variable to the template $view->set('foo', 'bar'); $view->set('show_nav', true); $view->set('nav_pages', $pages->get('/')->children()); As you can see, there is no markup echoed out. The corresponding template file is responsible for this task: // In template file: /site/templates/view/home.php <h1><?= $page->title ?></h1> <p>Foo: <?= $foo ?></p> <?php if ($show_nav): ?> <ul> <?php foreach ($nav_pages as $p): ?> <li><a href="<?= $p->url ?>"><?= $p->title ?></a></li> <?php endforeach; ?> </ul> <?php endif; ?> In the example above, "ProcessWire" is used as engine. If Smarty is the active template engine, the corresponding template file could look like this: // In template file: /site/templates/smarty/home.tpl <h1>{$page->title}</h1> <p>Foo: {$foo}</p> {if $show_nav} <ul> {foreach $nav_pages as $p} <li><a href="{$p->url}">{$p->title}</a></li> {/foreach} </ul> {/if} Note that the API variable acts as a gateway which connects you to the activated template engine. We can switch the engine behind without changing the controller logic! (I know that this is probably not a very common need, but it's a cool thing anyway ) For further information, please check out the readmes on GitHub. Please ask questions if anything makes no sense - sometimes it's hard to get my explanations Cheers

A quick tutorial how to create file downloads using pages You will be able to create a new page using template "PDF" (or any you setup), upload a pdf file. You then can select this page using page fields, or links in Wysiwyg. The url will be to the page and NOT the file itself. This will allow to keep a readable permanent unique url (as you define it), unlike /site/assets/files/1239/download-1.pdf, and you'll be able to update/replace the uploaded file without worring about its filename. Further more the file will also have an id, the one of the page where it lives. Clicking those links will download or open the file (when target="_blank") like it would be a real file on server with a path like /downloads/project/yourfile.pdf. You'll be also able to use the "view" action directly in the page list tree to view the file. Further more you'll be able to esaily track downloads simply by adding a counter integer field to the template and increase it every time the page is viewed. Since the file is basicly a page. This all works very well and requires only minimal setup, no modules and best of it it works in the same way for multi-language fields: Just create the language alternative fields like "pdf, pdf_de, pdf_es" and it will work without modifying any code! Still with me? ok PW setup Download folder: Create a template "folder" or "download-folder" with only a title needed. Create pages in the root like /downloads/project/ using this template. Setup the template for the pdf files 1. Create a new template in PW. Name it pdf 2. Goto template -> URLs tab and set the URL end with slash to no. (So we can have /path/myfile.pdf as the URL) 3. Create a new custom file field, name it pdf. Set its maximal count to 1 under -> Details tab. 4. Add the pdf field created to the pdf template. Easy. 5. Create a new "pdf" page using the pdf template under a download folder you created earlier. 6. Give it the title and in the name field add ".pdf" to the end (could also leave as is) Template PHP file for the pdf files 1. Create the template file pdf.php in your /site/templates folder 2. add the following code: <?php // pdf.php if($page->pdf){ wireSendFile($page->pdf->filename); } Done. To see the options you have with PW's wireSendFile() you can also overwrite defaults <?php // pdf.php if($page->pdf){ $options = array( // boolean: halt program execution after file send 'exit' => true, // boolean|null: whether file should force download (null=let content-type header decide) 'forceDownload' => false, // string: filename you want the download to show on the user's computer, or blank to use existing. 'downloadFilename' => '', ); wireSendFile($page->pdf->filename, $options); } Simple and powerful isn't it? Try it out. Some thoughts advanced Create as many file types as you like. It might also be possible to use one "filedownload" template that isn't restricted to one field type but evaluate it when being output using $page->file->ext, or save the file extension to the page name after uploading using a hook. One last thing. You can add other meta fields or preview images to the template and use those to create lists or detail pages. It's all open to goodness. Again all without "coding" and third-party modules. Further more you can use the excellent TemplateDecorator to add icons per template and have a nice pdf icon for those pages. This as a base one could also easily create a simple admin page for mass uploading files in a simple manner, and create the pages for the files automaticly. ImagesManager work in the same way. Cheers

I am having a lot of fun today (having worked out a game throttling kink with Soma last night - thanks mate) I have about 900 plus pages all about car manufacturers, models, servicing, prices and the rest. So what? Well, it is the way I have been able to put them together with PW and PHP So, I have a function that lists all the services like gearbox rebuilds, or body work repairs. On its own, on a normal page, it just links to the pages about those things. On a car manufacturer page it changes from Gearbox Rebuilds" to "Audi Gearbox Rebuilds" with an extra URL segment in the URL that adds /audi/ The function gets two extra arguments to work the magic: rightMenu($page->title,$page->name); Now on the gearbox rebuilds page it is suddenly all about Audi gearbox rebuilds with text changes all thanks to hanna code. Also on the manufacturer page it lists all the models for audi and gives servicing prices for each model. Prices are set globally (since most cars cost the same) but can be overridden individually if the client wants. Now I just need to add Ryans clever linking thingy for text and suddenly I will have everything cross linking all over the place. The Really, Really, Really amazing thing about this is that I have been able to code all this from scratch with so little knowledge that it is frightening, but there I am, staring at a 900 line functions file, stuffed with php and PW API, and I did it all. And it works! The reason is the API - to code this fully would be so overwhelming that I would not even consider it, assuming I even knew where to start. But the API wraps up so many complications is such brief statements, that suddenly it is not only easy, but clean, clear and understandable - even for an old has-been, burnt out, media bloke like me. The only down side is that the client is being so undercharged for this that it is criminal - but then, it is not his fault that I decided to get carried away and add 900 pages to his site.

Welcome! You just include(/path/to/file.php) http://php.net/manual/de/function.include.php You could also use a php switch() instead of if else switch($page->id){ case 1001: echo "..."; break; case 1002: include(...); break; case 1004: echo someFunction($page); // maybe a function default: echo ".."; } About the approach I'm not sure and don't see the whole picture, but experiment with different ones. There's no general "this is the best". Whatever makes sense and works for you. I think outputting content by id might be ok in one case, but maybe not so convenient regarding reading/maintenance and code compatibility. I usually try to avoid it. There's so many ways to build templates and output your code in templates, and it goes far beyond this question. And there's as many different opinions on what is good and what not. But some principals may apply always. Usually I find it more convenient to use different templates for different pages as much as possible.

Well you just set the fields from the other page, and the $page will still be the same page object just with new content (on runtime). $p = $pages->get("/somepage/"); foreach($p->fields as $f){ $page->$f = $p->$f; }

Anyone who has told you that you are The big lebowski? I like to create graphics that is all. I can see the resemblance.

My first post here, coming from mainly Wordpress. The holy grail for me is exactly the description below: That's really it, isn't it? For years I've been stuck between the lightweight PHP framework (like Codeigniter) versus full-on CMS (like Wordpress) thing. The former requires a lot of monotonous coding to get an api + admin set up, and the the latter gets you bogged down in superfluous features.

Anyone who has told you that you are The big lebowski? I like to create graphics that is all.

Okay, your PC is better than mine..... You are spending far too much time Studio Max (or something)

( http://makerfairehannover.com/ )

I'm really not sure what the issue is with writeable files in regards to security. If the server is compromised in a way that would allow an attacker to modify these files, then you're already screwed as they could modify the code as well. Also in that case they would be able to access the database. The only issue I can see is files having incorrect permissions modes, which could be easily detected and warned about in the admin interface. (Additionally, if I know that I will never want to make any metadata changes directly on the production site, I could set a configuration option (or something) to disable the editing interface for fields/templates, and then also make the files non-writeable. Though obviously this scenario won't apply to everyone.) We already have an issue of inconsistency: the template PHP code may not be consistent with the data structure. If the template/field config is stored in files this issue disappears. But with this model, if the metadata somehow becomes out of sync with the data, then the only real issue is going to be that some data might not be present (which would have been an issue anyway). In fact it's arguable that it's not really possible for it to become out of sync, since the schema files are the authoritative source. If a field has been added, then everything just works, apart from obviously old pages won't have data for the new field. If a field is removed, not a problem, it's just not used any more. The data would still be there but orphaned (see bottom of this post re: cleanup task). If a field type is changed, the old data is again left in the old fieldtype table, and everything should just work. The whole idea was to avoid needing to change the database schema at all. Changing the field/template configuration to something incorrect could break the site until it's corrected, but would not cause any data loss. Since the files on disk would represent the desired state of the data, not the changes required to achieve that state, destructive actions would not be performed automatically. I imagine a cleanup task would be necessary to remove old data which is no longer required (e.g. when a field is removed). This would be run manually from the admin interface, so user confirmation would still be required.

At some point, I'll setup fields and templates to maintain mirror copies of files on the file system for those that want to version control them that way. They are in the database for very good reasons, but that doesn't mean that they can't be on the filesystem too. It's just that the database is the better default place for them to live and be maintained from for the vast majority. I don't consider writable files particularly trustworthy in the grand scheme, so the master source would always have to be the DB, but the mirror files could certainly be monitored, versioned and migrated at the developers discretion. I have no problem with that so long as we're not letting the file system lead. Something to add here that I think gets overlooked is that PW is not just a development tool. In the majority of cases, the development phase is just a very short blip in the overall timeline of the project developed with ProcessWire (whether a website, application or whatever it is). While we put a lot of focus on the development tool aspect of PW, the big design decisions are made for the entire lifecycle, not just the development phase. CMSs have to be written for large scale realities and diversity across hosting providers, varying amounts of security and expertise levels. While files here seem beneficial from one perspective, that does not translate to a net benefit in the larger context. In fact it translates to something rather undesirable in the larger context. Having important data in writable files on the file system is something you try to avoid with a CMS. While they are a necessary evil in some cases, if you can keep writable data in the DB, it's going to result in stronger security over a broad installation base and over a broad time period. These writable files are often the weakest link on shared hosting accounts. They can be perfectly secure, but there's little doubt the DB is safer. When it comes to data that needs to be editable, I consider the DB a much more trustworthy storage mechanism for important data across a large set of installations. I'm stating the diverse reality of our big picture context and not any individual's server. Some of us are running on servers where it would make no difference at all from a security aspect, but that's not something we can count on. Outside of the situations mentioned in this thread, I think most would not find it desirable to have the field and template data that disconnected from the content it represents. I can imagine some real headaches with schema getting disconnected from the data. When I backup my DB, I like to know that I've got everything necessary to put it back together without having to chase down multiple files with multiple tools, not to mention possibly files in different versions. I don't want to open the door to having having schema files that are not consistent with the data that they are supposed to represent. Data loss is always a possibility with schema changes and should always be accompanied by a confirmation. Automation by movement of schema in files (whether by git or SSH, FTP, etc.) is problematic for a lot of reasons. The issue described about one person's changes overwriting another's may be a potential real world case, but is a non-issue for most of us because we don't migrate those kinds of changes at the DB level, nor do I recommend doing that. I understand that there are challenges for a team of developers having multiple versions of schema, or developers that want to migrate schema changes to a live server in an automated fashion rather than re-playing those changes themselves. I actually think less automation is ultimately a safer solution here, even if not as convenient for some. Though I'm still very enthusiastic about continuous integration projects and doing anything I can to support them. But I do not support moving storage away from the DB as our primary storage for these things. I understand using the file system may seem like a smart choice in certain contexts (and I don't disagree on them), but in the larger context it's not a wise choice. I'll do my best to find ways to mirror the data to files for those that might want this or may benefit from it.

new german updates for actual PW dev 2.4.7 (11 July 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--fieldtype--fieldtypepagetable-module.json wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json wire--modules--process--processmodule--processmodule-module.json pw-lang-de-dev-update.zip

I discovered Processwire some weeks ago and i love it. I´m implementing 3 sites for my customers. I´m working on my first module, wallpapers,etc. I hate e-commerces or social sites made with Wordpress. Wordpress is a blog cms (44mb approximately). A lot of plugins, widgets and third-party themes that are not necessary in processwire or other cms. I love this community and the Processwire´s code and I hopes it will be the wiiner of a lot of rewards soon.

ProcessWire doesn't generate output, so SEO is as good as your own SEO skills. And ProcessWire is blazing fast, that SEO part you get for free.

: Summary of Germany - Brazil Prost

Here is a companion module (my first public module). Accordion Textformatter I've had this kicking around for a while. After you released Pagination, I figured I would update it and get it out there. Same idea essentially, but creates collapsed "accordion" content instead of pagination. Hope you don't mind, I leaned heavily on some of your code for the markup pattern. I wanted to make them essentially interchangeable (not that you ever would).

Thanks for making this! I was just trying it out in 2.4 and the draft creation works fine but the ability to "publish" and remove the draft appears non-existent. Something to look at if you want to bring this module up to the current release, which I sure hope to see.

As a quick heads-up I've just updated the module (twice, as it turned out that Joss' problem was related to certain regexp not expecting .co.uk TLDs..) and it should now work with the new Google Maps URL format. The problem is that this new format is more difficult to work with than earlier one, so I'm doing some ugly tricks (such as relying on old maps URLs) to keep things working. This is not a good solution in the long term, which is why an extensive rewrite of this module is going to be required soon, unless there's some solution I just haven't thought about yet. I've added a new checkbox to module config, titled "use coordinates". If this is checked, new maps URLs will be embedded based on coordinates, which is accurate but also replaces place name with those same coordinates. If it's not checked, location name will be used instead, which is far less accurate and for Finnish place names, for an example, practically didn't work at all. Like @Hani pointed out above, old Maps URLs still work -- which is a very good thing, since at least it means that old content should (for the time being) remain intact

Kind boring sport you have here on earth. On my planet we also play a kind of "football", but it's called "airball". There's 42 players and the playing field is 3.1415 square kilometers. We use hover-boards and the ball is levitating. The goal is a circle and if the ball enters the goal, one player of the other team has to drink 1 cup of slime that contains 50% alcohol. Pretty damn fun. *hickup*

Ha ha - good one Martijn. Yes I may live in Spain (17 years now) but I will always stay a Dutch guy I always put my bets without doubt on the Netherlands when it comes to football. Talking about it, I am not the only Dutch guy here. Heck there are even lots of dutch bars and restaurants here. I have learned to know lots of dutch people here. We always read dutch newspapers to know what is going on in "Holland" and have long discussions. Spanish locals call us "cabezas de queso" which means "kaaskoppen". In some dutch bars here dutch people now show up with orange wooden shoes which are "klompen" in orange color specially for the Dutch - Spanish football. It is going to be a long orange week-end here

@Marty: I do this by using a module. It's a copy from somas PageListShowPageId. the PHP code is public function init() { $this->addHookAfter('ProcessPageListRender::getPageLabel', $this, 'addPageArchivnummerLabel'); } public function addPageArchivnummerLabel($event) { $page = $event->arguments('page'); if('album'==$page->template) { //$event->return = str_pad(count($page->images), 3, '0', STR_PAD_LEFT) . " " . $event->return; $event->return = $event->return . ' <span class="jhpPageListArchivnummer">' . $page->archivnummer . '</span> ' . ' <span class="jhpPageListImageCount">' . count($page->images) . '</span>'; } } and the CSS is .content .PageListItem > a span + span.jhpPageListImageCount:before { content: 'count: ' !important; } .content .PageListItem > a span + span.jhpPageListArchivnummer:before { content: '' !important; } .content .PageListItem > a span + span.jhpPageListImageCount, .content .PageListItem > a span + span.jhpPageListArchivnummer { font-size:0.9em; background-color:#EEE; color: #777; padding: 2px 5px 1px 5px; border: medium none !important; border-radius: 3px 3px 3px 3px; }

Or use this script I created to create and send a zip to browser. https://gist.github.com/somatonic/6427247 /* creates a compressed zip file */ function create_zip($files = array(),$destination = '',$overwrite = false) { if(file_exists($destination) && !$overwrite) { return false; } if(is_array($files)) { foreach($files as $name => $file) { if(!file_exists($file)) unset($files[$name]); } } if(count($files)) { $zip = new ZipArchive(); if(!$zip->open($destination, $overwrite ? ZIPARCHIVE::OVERWRITE : ZIPARCHIVE::CREATE)) return false; foreach($files as $name => $file) { $zip->addFile($file,$name); } $zip->close(); return $destination; } else { return false; } } // get a language to export json files $lang = $languages->get("de"); $files_to_zip = array(); // "language_files" = file field on language page where json's are stored foreach($lang->language_files as $f){ $files_to_zip[$f->name] = $f->filename; } $zip = create_zip($files_to_zip, $config->paths->root . 'language_files_de.zip' ,true); if($zip) wireSendFile($zip); // send file to browser (/wire/core/functions.php) This would be put in a template file. Have fun. While doing this we might need a wireCreateZip() function in core as we also got a wireUnzipFile().