Leaderboard
Popular Content
Showing content with the highest reputation on 11/11/2012 in all areas
-
EDIT: This project has been put on ice - I don't work with ProcessWire in my day job anymore, so this project is looking for a new maintainer. Knowing that, you can decide whether it's worthwhile reading through 7 pages of posts EDIT: The source code has been dumped on GitHub - feel free to fork and have at it. There's one thing about ProcessWire that pains me, and I've brought this up before - it's the same problem I have with e.g. Drupal... Because the meta-data (Configuration, Fields and Templates) is stored inside the database, once you have a live site and a development site, moving changes from the development site to the live site is, well, not really possible. Repeating all the changes by hand on the live site is simply not an option I'm willing to consider. Telling the client to back off the site and give me a day or two to make the changes, and then moving the whole database after making and testing the changes on a development site, is really a pretty poor solution, too. I had heard some talk about a module in development, which would make it possible to import/export Fields and Templates? It sounds like that would mostly solve the problem. Ideally though, I'd really like a solution that records changes to Fields and Templates, and allows me to continuously integrate changes from one server to another. So I started hacking out a module, but I'm not sure if it's going to work at all, if it's even a good idea, or if it's worth the effort. I'm looking for feedback on the idea as such, more than the code I wrote, which isn't real pretty right now. Anyway, have a look: https://gist.github.com/b7269bb7bd814ecf54fb If you install this, create a "data" folder under the module's folder - migration files will be written there. Basic overview of the idea and code: The module hooks into Fields::load() and takes a "snapshot" of the current Field properties and settings on start-up. It also hooks into ProcessField::fieldSave() and when a field is saved, it compares it's properties and settings to the snapshot it took at startup - if changes were made, it writes the previous name and updated properties into a file. The same thing is not implemented for Templates yet, but would be. The migration-files are named like "YYYY-mm-dd-HH-mm-ss.json", so that they can be sorted and applied in order. Each file contains a JSON representation of a method-call - currently only updateField() which would repeat a previous set of changes and apply them to another installation of a site. (not implemented) So basically, the module would record changes to Fields and Templates, and would be able to repeat them. How those files get from one system to another is less of a concern - would be cool if servers could exchange migrations semi-automatically, using some kind of private key system, but initially, simply copying the files by hand would suffice. I'm more concerned about the whole idea of capturing changes and repeating them this way. Any thoughts? Is this approach wrong for some reason? Would this even work?3 points
-
Description A ProcessWire module to add some classes to your body tag. That will give you a better control of your CSS. Basic Usage Add this code into the class of your body tag: <?php echo $modules->get("BodyClass")->bodyclass() ?> So your body tag should look like this: <body class="<?php echo $modules->get("BodyClass")->bodyclass() ?>"> Custom usage <?php echo $modules->get("BodyClass")->bodyclass(array('page_id' => false, 'template_name_prefix' => 'templatename-')) ?> Default options array( 'page_id' => true, // bool (default true) return the page id 'page_id_prefix' => 'page-id-', // string (default 'page-id-') prefix for page_id 'parent_page_id' => true, // bool (default true) return the page id of of parents 'parent_page_id_prefix' => 'parent-page-id-', // string (default 'parent-page-id-') prefix for parent_page_id 'template_name' => true, // bool (default true) return the template name 'template_name_prefix' => 'template-', // string (default 'template-') prefix for template_name 'browser_info' => true // bool (default true) return some browser informations (os, browser, browserversion) ); Project Page on GitHub www.yesjoar.com2 points
-
I'd like to request that TinyMCE be configured to paste as plain text by default. This tends to save a lot of headaches with special characters coming in from Word and reduces support calls about the WYSIWYG ;-) It doesn't seem like something I can override in the admin theme, but if I'm wrong please let me know the secret... I found this example on stack exchange on how to do it: tinyMCE.init({ ... plugins : "paste", paste_text_sticky : true, setup : function(ed) { ed.onInit.add(function(ed) { ed.pasteAsPlainText = true; }); } .... }) Thanks!2 points
-
I've written a module that fulfils a small but hopefully useful need to provide clients with links to "live" but work-in-progress pages so they can be viewed by those that don't have a CMS login. The basic process is to add a "create draft" link to the page listing (after edit, new, move, delete etc). When clicked, this link creates a clone of the page and adds an MD5 hash of the current time to the URL so that a draft clone with an effectively "un-guessable" URL (name) is created that can be given out to clients to view the page. This clone has a "publish" link added to it in the page listing so this can then be copied over the original published page, and the draft deleted, with one click. The cloned pages also has "(DRAFT)" added to the title. Does this sound useful to anyone? The only problem is that, because the "draft" page is published it will show up in menu listings and anything else that is utilizing the site structure or API to grab live pages. If the "published" nature of the cloned pages makes this idea unworkable then I will go back to the drawing board! But if it has potential to be useful then I will at the very least publish the source on github or copy it in here so it can be tampered with by others. It occurs to me that it wouldn't be hard to filter out these pages with "(DRAFT)" at the end of the title so they don't show up in menu listings etc, but this would require extra effort on the part of the developer in every case where the fetching of pages is occurring.1 point
-
http://www.fmmhindusociety.com/ This one is the first website I have created with ProcessWire for non-profit organization. As I have mentioned in my one of the post that this website is hosted under windows platform which has IIS7 as web server. Thanks for checking out.1 point
-
One more step you have to do. Go to Setup->Templates. Click on 'home' template. Click on 'Access'. Give the 'Edit Pages' access to the newly created role. You can also give other access if you wish as per the new role.1 point
-
Roles are actived per template basis, so take a look at your home template and access tab. PS: Welcome to the forums!1 point
-
In the Field setting screen of a TinyMCE field you can configure much if not everything. Tab "Input" you see the TinyMCE Advanced Configuration Options. Add "paste" to the plugins string. Add paste_text_sticky: true paste_text_sticky_default: true to the Additional TinyMCE Setting field. If you want to add it globally to al TinyMCE fields you could add following to the default.php in your admin theme. Before closing </head> <script> // overwrite TinyMCE skin setting globally // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js // and loaded before if('undefined' != typeof InputfieldTinyMCEConfigDefaults) { InputfieldTinyMCEConfigDefaults.plugins += ",paste"; InputfieldTinyMCEConfigDefaults.paste_text_sticky = true; InputfieldTinyMCEConfigDefaults.paste_text_sticky_default = true; } </script>1 point
-
@mindplay.dk: if I'm following your post correctly, you're saying that by default trailing slash should be added to pages which can (currently) have children and omitted from pages which (currently) can't? I do see where that's coming from, but I still have to disagree here, mostly based on the previously mentioned fact that those things (family settings etc.) can be changed quite easily while URLs changing is generally speaking a bad thing. What you're saying about files and folders is absolutely right; in this context files/folders act exactly as they would in, say, pretty much any UNIX style operating system. Thus /foo/bar/ would refer to folder /bar/ in another folder /foo/ and /foo/bar to a document called bar in folder /foo/. Up to this point we're probably seeing things exactly the same way. That's also where things get slightly more complicated: I prefer to think that each ProcessWire page really is in a (virtual) folder, so when you're accessing /foo/bar/ you're actually getting served default file in particular folder; in this case /foo/bar/index.* (suffix doesn't matter here.) There's nothing wrong with this, it's always consistent, very common and has been used for many, many years already all around the web. Even if that particular page had only one file and thus didn't really need to exist in a folder, this is still completely valid. If pages that can't currently have children had to be accessed as files instead of folders, strictly speaking that should also mean that same address with trailing space added should not work -- otherwise they would be folders and not files, and like you said that's a different beast altogether. Just give it a try in whatever OS you're currently running. Most likely if you create a folder /foo/ and try to access it as foo (without trailing slash) you're still redirected to correct folder, but if you're trying to edit / view a file called foo and add that trailing space you'll only end up with an error ("foo/: Not a directory" or something similar.) To sum this up current behavior is imho very much consistent with how the OS beneath your site actually behaves and that's another reason it should not be changed (unless you're actually suggesting that user accessing /foo/bar/ should only get 404 in case that admin has decided that bar can't have children, thus making it a file instead of a folder.) See where I'm going with this?1 point
-
Just use a text field and make the type = password. $field->attr('type','password');1 point
-
CKeditor has a version for jquery that doesn't seem hard to implement. I did a very quick adaptation to the pw tinyMCE module, and got it working. Lot's of work ahead is still missing of course... the new skin look pretty nice http://ckeditor.com/...ckeditor_4_skin
1 point -
If I understand the question correctly, you indicated "new ProcessWire sites" in which case you should check out the Site Profile Exporter to create your own starting profile to use instead of the included Basic Profile.1 point
-
No, not yet. This feature has been discussed before and it is coming at some point. Probably as a JSON export/import. More reading: http://processwire.com/talk/topic/1284-best-practice-for-staging-to-live-database-synchronization/#entry127521 point
-
I've just found this while searching for something else... Maybe it would come handy to someone... http://tinymce.swis.nl/1 point
-
Not sure. I think it's either a children's game or has something to do with MS Office, or both.1 point
-
Ryan, Thanks this gave me a great place to start. I thought I'd share the version I created in case anyone finds it useful. • Single template for the login/logout. • Automatically redirects the user back to whatever page they originally requested after they login. ./includes/login.php <?php // Handle logouts if($input->get->logout == 1) { $session->logout(); $session->redirect($page->path); } // If they aren't logged in, then show the login form if(!$user->isLoggedin()){ // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($page->path); } else { $session->login_error = 'Login Failed. Please try again, or use the forgot password link below.'; } } ?> <!DOCTYPE HTML> <html lang="en"> <head> <title>Custom PW Login</title> </head> <body> <form action='./' method='post'> <div class="login"> <? if($input->post->user && $input->post->pass) { echo "<p class='error'>" . $session->login_error . "</p>"; }?> <p><input type='text' id="user" name='user' placeholder='Username'/></p> <p><input type='password' id="pass" name='pass' placeholder="Password" /></p> <p><input type='submit' class="btn" name='submit' value='Login' /></p> </div> </form> </body> </html> <? die(); // don't go any further if not logged in } // end !logged in ?> In any template you wish to protect: <? require("./includes/login.php");?> To trigger a logout: <a href="?logout=1">Logout</a> Note: I'm using the HTML5 placeholder attribute. Browser support is not 100%. You may want to use labels instead, or use some jQuery (like I did) to add the placeholder text for browser that don't support it. SideNote: How do you get code indents to stick when posting? I'm having to go back and add spaces to each line. I use tabs when coding.1 point
-
Absolutely! Here is a simple, but functional example for both login and logout templates. You would want to replace the markup with your own markup or includes. Likewise you'd want to change the redirects to redirect to whatever page you want them to go to after completing a login. /site/templates/login.php: <?php if($user->isLoggedin()) { // user is already logged in, so they don't need to be here $session->redirect("/somewhere/"); } // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect("/somewhere/"); } } ?> <html> <head> <title>Login</title> </head> <body> <form action='./' method='post'> <?php if($input->post->user) echo "<h2 class='error'>Login failed</h2>"; ?> <p><label>User <input type='text' name='user' /></label></p> <p><label>Password <input type='password' name='pass' /></label></p> <p><input type='submit' name='submit' value='Login' /></p> </form> </body> </html> /site/templates/logout.php: <?php $session->logout(); ?> <html> <head> <title>Logout</title> </head> <body> <h1>You have logged out</h1> </body> </html>1 point
