Leaderboard

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.

Every time i read about some new amazing feature in a CMS, it's always stuff that is a totally natural part of Processwire and has been around and used by us PW folks for ages. Read this for example. http://alistapart.com/blog/post/longform-content-with-craft-matrix And always, always!, there's some Wordpress guy in the comments saying: "You can do that with wordpress!". Yes, of course you can, but only with a bunch of ugly hacks and tweaks and 37 plugins that may play nice together if you're lucky. I have split emotions about this. A bit of sadness - Processwire should be given much more attention and recognition. At the same time, I feel lucky for having discovered it. What about you guys?

Hello guys Just committed a larger update to 0.1.0: lots of cleanup and major changes, but still backwards compatible some fixes to tag parser as there were issues with multi language major rewrite of the image results table to get rid of bundled jQueryDataTable and Fancybox (saves a lot of files and resources that where not necessary) now uses PW MarkupAdminDataTable with custom ajax overall nicer and solider UI integration into PW new admin theme other small improvements and fixes To update, just replace the module folder with the new one. There's a lot of files deleted, so don't just merge. So a lot of changes behind the scenes you won't notice much, but also UI wise it's much nicer now. It should works nice and I think requires PW 2.4 now. Not tested in 2.3, but mainly I think the use of JqueryMagnicfic Lightbox script (in core 2.4) now for image preview zoom. Otherwise it should work the same. I removed alpha status, whatever that means. After all it's not meant to be the solution to all problems people might have with PW's media management. It's a nice little helper tool to upload images and create pages from them. In the end it's all saved in a form you could even uninstall ImagesManager and plug your own to handle the data. It can also be seen as a resource. I'm not sure I'll add it to the modules directory.

The great thing about ProcessWire and all the great tools/modules associated with it is that I have been motivated to relearn PHP, HTML, CSS and Javascript. I have never had so much fun as in the last year. Hanna Code specifically with Ryan's original Foundation 4 profile made learning too easy. I have now gone on to other CSS Frameworks with no fear. I still got the API, functions, modules and many other things to learn in ProcessWire. I can't say that I am bored with ProcessWire. From my point of view, It's great to be an old geezer. I embrace it because it doesn't keep me from learning new and exciting things.

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.

+1 Couldn´t have said it better. Coming from all kind of cms'es (modx) out there that I tried out in the past, I ended up with processwire. No third party framework bounded to a cms architecture but api using php directly as language and framework. Giving you all the playground and freedom you can wish (and speed)

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.

I hope that you like it.

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.

( http://makerfairehannover.com/ )

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.

Yes, exactly. It's (still) a blogging platform, but for some reason considered a cms. It's like slapping a monitor onto a typewriter and calling it a computer. Well, almost

Didn't install this module, so maybe I tell something it's already in . Maybe add an option to make the trigger configurable. I prefer to use the <hr> tag for example. This way, people can click on a button to add the functionality.

First, Thank you for creating this. Maybe this is a real stupid question, but here goes --- wouldn't it be better if you used some other trigger than 5+ hyphens to activate this? My thinking is that if you changed it to something that did not conflict with the Pagination Texformatter, we could then possibly use both on a page?

I found, that the title tag is still an extremely important element. Try it out by amending keywords in the tag from time to time and see how your site performs. With every new site I spent some thinking and effort on the browser title with mostly very good results.

Martijn is absolutely right in both points he makes. Here are a few of my own thoughts... There are some things that we can control directly - 'On-page optimisation', and that is where PW and a bit of thought & skill can make a real difference. (I'm not talking about spammy keyword stuffing or anything here.) Reading around the subject, it is clear that things Google likes include (in no order of preference) Fast loading pages - PW helps out of the box but there are plugins for minifying code & caching for example. There are also helpful post on here about .htaccess tweaks to help loading speed. Clean, (semantic?), error-free markup. Responsive designs. Microformats / schema.org markup. Indications that a site is 'for real' - a contact email, a phone number, a postal address etc. Links to actual, related social accounts (Twitter, FB, LinkedIn etc.). This kind of thing (including obvious old-school stuff like meta title and description tags) is not difficult and I firmly believe can give you a head start in the search results. This article http://www.thesempost.com/google-rewrites-quality-rating-guide-seos-need-know/ talks about revised Rater Guidelines and mentions things like offering readers other content related to the page they are on (so called 'Supplementary Content'). With a bit of programming (and we have discussed this subject here before) that is again something that can be built in. There's a bunch of other ideas in there. It isn't too much of a stretch to expect that, without doing too much traditional link-building, a site incorporating some of these ideas could launch, and with some social promotion, start gaining valuable organic, editorial links very quickly. I firmly believe that any site not taking advantage of these (relatively) easy optimisations is not making the most of the opportunity.

Hi Kae, About processwire and seo: https://processwire.com/talk/topic/45-url-schema/ https://processwire.com/talk/topic/4957-seo-optimization-module/ http://modules.processwire.com/modules/piwik-top-keywords/

Especially small clients should get as much value for their investment as possible. Hoster as 1&1 do deliver exactly the opposite. Especially if they manage the site by themself, good support on the hosters side is really key, in my opinion.

This Textformatter allows you to designate areas in a single textarea to be converted to a collapsed accordion list. The markup pattern for this module is based on the Pagination Textformatter module with the idea that they could be interchangeable. Github Page Simple Demo To define an accordion item Put 5+ hyphens '-----Your Title Here' on a single line (within paragraph tags) to specify a title for the accordion item. The paragraphs below will be collapsed. This is the same idea as the Pagination Textformatter, however titles are not optional. If you just put the dashes, the item with be automatically titled "Untitled". To end an accordion To end a group of accordion items and return to regular textarea content, put exactly 5 slashes on a single line '/////' (within paragraph tags). This is only needed if you want to end collapsed content and return to regular textarea content. Notes I've been using this on a production site for nearly a year, but before Ryan released the Pagination Textformatter it was using with a totally different markup pattern to designate the accordion items. It should be pretty stable, but consider it a beta release. Markup pattern inside a textarea (Nearly identical to the Pagination Textformatter) ----- Accordion Item The paragraphs beneath each accordion item are collapsed by default and open when you click on the title specified above. You can use multiple paragraphs, and any other content allowed in the textarea. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec odio. Quisque volutpat mattis eros. Nullam malesuada erat ut turpis. Suspendisse urna nibh, viverra non, semper suscipit, posuere a, pede. ----- Another Accordion Item Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec odio. Quisque volutpat mattis eros. Nullam malesuada erat ut turpis. Suspendisse urna nibh, viverra non, semper suscipit, posuere a, pede.Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec odio. Quisque volutpat mattis eros. Nullam malesuada erat ut turpis. Suspendisse urna nibh, viverra non, semper suscipit, posuere a, pede. ///// The 5 slashes above signify an end to the accordion group above. You only need to specify the end of a group if you want to return to regular textarea content. You can continue to use the same pattern to collapse content into accordions as many times as you wish. Results in the following markup: <dl class="accordion"> <dt> <a href="#accordion-item">Accordion Item</a> </dt> <dd> <p>The paragraphs beneath each accordion item are collapsed by default and open when you click on the title specified above. You can use multiple paragraphs, and any other content allowed in the textarea.</p> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec odio. Quisque volutpat mattis eros. Nullam malesuada erat ut turpis. Suspendisse urna nibh, viverra non, semper suscipit, posuere a, pede.</p> </dd> <dt> <a href="#another-accordion-item">Another Accordion Item</a> </dt> <dd> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec odio. Quisque volutpat mattis eros. Nullam malesuada erat ut turpis. Suspendisse urna nibh, viverra non, semper suscipit, posuere a, pede.Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec odio. Quisque volutpat mattis eros. Nullam malesuada erat ut turpis. Suspendisse urna nibh, viverra non, semper suscipit, posuere a, pede.</p> </dd> </dl> <p>The 5 slashes above signify an end to the accordion group above. You only need to specify the end of a group if you want to return to regular textarea content. You can continue to use the same pattern to collapse content into accordions as many times as you wish.</p>

This tiny module is intended as a helper for Ryan's Hanna Code module by providing a way to select existing Hanna Code tags within the editor. This is something I felt our clients needed in order to start properly using Hanna Code tags. See attached screenshot for details -- there's really not that much to it at the moment. Each editor requires it's own plugin and currently I've only cooked one up for CKEditor, where the plugin presents itself as a context menu item (visible on right click). I'm planning to expand the feature set of that one slightly and then probably convert the CKEditor plugin to TinyMCE, but that's just about it. Ideas are welcome, though. Some of the code is pretty much duplicated from Ryan's original module. I hope he doesn't mind -- though for the record I've also tried to make it very clear in the source what part that is and where it's from.. GitHub: https://github.com/teppokoivula/HannaCodeHelper Modules directory: http://modules.processwire.com/modules/hanna-code-helper/

Ohh wallpapers! I have one too!

Try: $lev->save();

Are you telling me that my computer is not a computer? Microsoft office is my default php editor because the people know it. The plot against wordpress

@renobird Thanks for your reply. I have really taken a liking to Ryan's module and am now using it on a few websites. When I saw what you had accomplished, I was very happy because I really like using accordians or tabs when developing a website. I really would like to be able to use both at the same time, since I believe it would allow me or even others to be more creative when developing websites. Thanks again and best regards Charles

@cstevensjr I originally developed it to using [collapse](My TItle Here) and [/end]. I don't have a need to ever use this with pagination, so ----- and ///// seemed so much easier to remember and use. However, I don't think it would be too difficult to add a config setting to allow you to chose between the 2 markup patterns. I'm glad to provide that ability if people can use it. @Martijn I think there is too much to account for to make it configurable. At least it's more development than I can devote to it. For instance <hr> would be more complicated to account for because the <hr/> is it's own element on it's own line, so marker and the text for the title of the collapsed content aren't associated in a way that you could count on. Personally I wouldn't want to override any HTML tags, I think they should always output their expected markup. Perhaps you could use Teppos awesome hanna code helper to give users a clickable option?

You're right, metadata does not belong in the database, and this approach is a bit of a "cop out" - I'm just trying to do the best I can under the circumstances. I don't think redesigning the schema really solves the problem though - the metadata needs to be separated from the data, which means it needs to get out of the database; separation is the main point, structure is actually not really an issue. What I would really like to see, is a transaction design, in which command objects are used consistently when making changes to the structural metadata - this would completely solve the problem, and make it very easy to build a migration system. Simply put, direct changes to metadata would be encapsulated and kept strictly internal - to make a change, you would instead submit command objects - for example, to change the name of a template, you would have to submit a ChangeTemplateCommand object, which the system would then serialize and store in sequential flat files, and of course serialize and store the updated template state. To migrate a system forward, you would simply unserialize any command objects starting with the last applied numbered file and submit them again. The trouble is, the existing system was not designed with a clear separation of data and metadata - the same problem as in pretty much any CMS I can think of...

Hello Can, thanks a lot for your input. I will give this a shot and let you know how it works out. Vielen Dank! Gerhard

actually you can just show different content based on the request type; so if you are doing a quick view, then you show that with Ajax; if you are linking to the page you show the page code; i'm doing that here: http://www.katonahartcenter.com/student-showcase/ and here: http://www.charleswuorinen.com/compositions/ so on your template: <?php if($config->ajax) { ?> show your markup for the quickview here <?php } else { ?> show your normal page code <?php } ?> so you don't need the quickview part of the URL

Hi Alex, Welcome to ProcessWire and the forums... Not sure what error you are getting but I am guessing the problem is the ->id part. A $pages->find will return and array of pages (i.e. there will be multiple ids); so, you only need $pages->find("age>$minAge"). You can then iterate through them. See examples here: http://processwire.com/api/variables/pages/ Secondly, nothing to do with your error, but you need to sanitize your input values first. In this case, you need to do at least this: $minAge = (int) $input->get['minAge']; The above are quick examples...you might need to sort out your double versus single quotes in the selector...I often forget which is which ...I might have missed something....others will correct if I did

@djr: first of all, welcome to the forum! Very interesting first post you've got there I may be the wrong person to comment on this, as I haven't had much time to think about these kind of changes (too busy building stuff on ProcessWire to spend time thinking what to change about it, I guess) but your idea made me wonder .. how could selectors work properly with such a structure (not knowing for sure that a specific field behaves same in different places sounds like a problem) and what kind of effect would it have to scalability and performance (I'd imagine this leading to tables with hundreds of thousands or millions of rows quite easily, which could become an issue considering overall speed, indexes etc.) Current database structure works quite well in both respects, so this is definitely something that would have to be considered carefully. Other than that, I'm actually not entirely sure that we're on the same page here about some of the things you've mentioned in your post: You mentioned that this way fields wouldn't "have to be global constructs", yet I see that as a good thing. Reusable fields rather than page-specific ones. I'm not entirely sure that I'd prefer to have field schema on the disk, even if it makes duplicating that schema in another installation in some ways easier. One of the key strengths about ProcessWire, in my use cases, is that I can very rapidly build new data structures with the admin tools it provides. How well would that be in line with having that structure as files on disk, I wonder? They're definitely not mutually exclusive things, but don't seem to fit that well together either (though perhaps it's just that I can't see it yet!) Anyway, interesting idea and definitely a good thought provoker

Think you could make your own little "cart" just a littly form with a hidden field for storing the page->id or if this form is on the same page you want to add to the cart you don't even need the hidden field. if($input->post->addtocart && !$cart) { $cart = new Page(); $cart->parent = $pages->get(5771); $cart->template = 'cart'; $cart->title = 'session_id()'; //for example $cart->save(); $cart->of(false); $cart->items = $pages->id; //not a hundred percent sure right now but should work (think I've done it like this already) } } items field would be multi page fieldtype you would then include this "$modules->get('Pages2Pdf')->render();" into the page template you want to generate the pdf's from on the cart page you add a link for the customer, think it should work when you just link to one of the pages and append ?pdf=1 to the url, which will then create the pdf create a new template under /templates/pages2pdf/ with the same name as the template you put the "$modules->get('Pages2Pdf')->render();" in in this template you iterate through the pages in the cart like you would on a blog page or similar and output everything you need for me the final output worked only with heredoc syntax, seems that proper double quotes are needed by tcpdf (you could echo as "normal" but then you would need to escape the double quotes) hoffe es ist einigermaßen verständlich und klappt (hope it's understandable and works)

I agree — ProcessModules are the way to go. They might look intimidating at first, but if you start with a very simple example, they really are very easy. Here is a super simple example that lists all pages with the template "news". (I'm sure there are others out there, but it only took a few minutes to write so...) <?php /** * Simple Process Module Example. * This is a very basic example to learn from. * I have no intention of expanding on this sample module. * * @author renobird * * ProcessWire 2.x * Copyright (C) 2011 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class SimpleProcessModule extends Process { public static function getModuleInfo() { return array( 'title' => 'Process Module (basic example)', 'summary' => 'A very simple process module as an example on how easy they are to create.', 'version' => 100, 'href' => '', 'permission' => '' ); } public function init() { // initialize the parent parent::init(); } public function ___execute() { // Find some pages $items = $this->pages->find("template=news"); /** * Create a table to display results * There are other ways to do this using MarkupAdminDataTable module, but let's keep this simple for now. */ $out = "<table width='100%'>"; $out .= "<thead>"; $out .= "<th>Title</th>"; $out .= "<th>Date Created</th>"; $out .= "<th>User</th>"; $out .= "<thead>"; $out .= "<tbody>"; // If $items pageArray is not empty if ($items->count() > 0){ foreach ($items as $item) { $out .= "<tr>"; $out .= "<td><a href=". $this->config->urls->admin . "page/edit/?id=" . $item->id .">" .$item->title . "</a></td>"; // title $out .= "<td>" . date("F j, Y", $item->created) . "</td>"; // date created $out .= "<td>" . $item->createdUser->name. "</td>"; // user that created $out .= "</tr>"; } } else { // empty pageArray message $out = "<tr><td>No pages matching your criteria were found.</td></tr>"; } $out .= "</tbody>"; $out .= "</table>"; return $out; } } Usage: Install the module Create a new page under /admin/ Set the process for the new page to SimpleProcessModule If you have never created a module, just focus on the execute() method. Most of what is there is coded exactly as you might from a page template.

$form = $forms->get("reconocimientos"); echo $form->render(); $form->get("reconocimientos")->addHookAfter("processInput", null, 'hookEmail'); A couple things to mention about the above code (quoted from above). You are adding a hook after the render(). You would need to add the hook before the render. That's because processInput is triggered from render(). Secondly is that you are hooking the wrong thing, as I don't think there is a 'processInput' method on $form (since it's not an InputfieldForm). What you'd want to do instead would be this (in your form-builder.inc file): wire()->addHookAfter('FormBuilderProcessor::processInput', null, 'hookProcessInput'); function hookProcessInput(HookEvent $e) { $processor = $e->object; if($processor->formName != 'reconocimientos') return; $inputfields = $processor->getInputfieldsForm(); // your code here. }