Leaderboard
Popular Content
Showing content with the highest reputation on 09/01/2014 in all areas
-
PageTableExtended Download here: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Extends the Processwire PageTable field for rendering table row layouts. This is great for editors, because they actually see at a glance what the table rows consist of. What it does Turns the Processwire Fieldtype "Page Table" from this: into something like this (sorting capabilities of course still functional): See it in action: Requirements FieldtypePageTable installed (part of the core since Processwire 2.4.10.) Templates used for PageTable need a file associated (otherwise nothing gets rendered) This render method is meant for sites where the PageTable templates only render part of the layout, not complete websites. But you also can define what will be rendered (see below). Options Render Layout instead of table rows Check this for seeing the rows rendered. You can easily turn off the complete functionality by unchecking this. Path to Stylesheet Since the parts are unstyled by default, it is a good idea to define styles for them. All rendered templates are encapsulated in a div with the class "renderedLayout" so you can style them with: div.renderedLayout h2{ color: green; } The path is to be set relative to your templates' folder. Reset Admin CSS Since the parts are rendered inside the Admin, common styles of the Admin Interface apply also to your layout parts. This is not a bad thing, because especially text styles are well integrated in your admin's theme. But if you like to override the admin styles in your table rows completely (more or less), just check this box. Don't forget to define a custom CSS then! Advanced Since this module is meant for parts of your layout you already have defined for your frontend templates, it is a good idea to use a preprocessor like Stylus, Sass or Less for building the custom CSS file. Just outsource your layout part definitions in an extra file, compile that in a separete CSS file and use this as custom CSS for this module. Since your CSS is should be built in a modular way, this works pretty well ;-) Will write a tutorial with a use case once finished testing. Notes: Github: https://github.com/MadeMyDay/PageTableExtended If you want to get rid of the unnecessary step for entering a title before editing the page, just set the "autoformat" value as suggested in the PageTable settings. If you don't want to use a title field at all, see this post from Soma Will put it in the module repository once finished testing. Please test it and give feedback. I haven't used GitHub for a long time, please check if everything is in place and if this will work with the modules manager and the new core module installer once added to the repository. Have fun Module is in the repository now: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Please use GitHub for instructions, I made some additions there.16 points
-
Hi everyone, I'm pleased to announce a new website built on Processwire just went live : http://optimum-events.eu. It's my first multilingual site with Processwire and all in all the experience has been really pleasant. The website use Bootstrap 3.1.1, AIOM module and Maintenance module. Any comments is welcome as there's still room from improvements ;-) Regards, Nicolas5 points
-
@ryan. Not a lot of demand? What planet do you live Well, everytime this comes up it get's many likes. My post just got 7 likes. I and many others are waiting for versioning/drafts since a long time. Thing is that it was on the roadmap all the time, so many of users are not asking for it again and again cause it's already.. well "ordered". I agree that it might not be always needed, and I see that this is not a quick implementation (I wouldn't know how in PW this should be designed). Maybe PW just isn't designed and capable for such a feature. And also it can lead to confusion if not implemented right. And all that comes with it, all correct. But I think it's a feature many are waiting for.4 points
-
Update: Version 1.3.0 - 31 August 2014 Summary of Changes Version 1.3.0 BlogPublishDate - Part of the Blog module suite, new small autoload module to save and preserve a Blog Post's publication date. The value (current time and date) is saved on Post's publish. It can be manually modified. Unless manually modified, the original published date is preserved between subsequent unpublish/publish events. Thanks @Adrian for idea, @SiNNuT and @Soma for code. For new installs, the new module will be automatically installed by PW when you install ProcessBlog. For existing installs, you will have to manually install BlogPublishDate. You will also have to set the field 'blog_date' not to automatically default to current date. Change this in Setup->Fields->blog_date. On the Input tab, scroll to the bottom and find 'Default to today's date?'. Untick the checkbox. Posts Dashboard (see screenshot) Date column: Now shows 'Pending' for unpublished posts (never before published ones), 'Expired' (published then unpublished posts) and published Date for currently published posts Date column: Date shown is formatted according to the format user set in 'blog_date'. Blog's default is 'j F Y g:i a', e.g. 8 April 2012 Date column: Sorting by date column now works correctly. Thanks @webweaver and @Teppo for solution Posts Dashboard, Categories Dashboard, Tags Dashboard Number of posts/categories/tags per page now shown - e.g. 'Posts 1 to 10 of 120' Customisable number of posts/categories/tags to show per page (via a drop-down select). Default is 10. Selected value is preserved (state saved via a cookie - browser specific, of course) per context (e.g. can have different values for posts, categories and tags dashboard) and per ProcessWire user. Thanks to @Nik for code idea. Some code clean-up Pending: - Featured image widget - Auto-publish/unpublish by set date Note: Issue in Dev: If you are running latest Dev, you will get an error about TinyMCE not being the default editor (if it is not installed), etc. when editing Posts. Follow the instructions given by PW. Once PW 2.5 is released, I will change 'blog_body' to use CKEditor.4 points
-
There is no drawback, there are only advantages. For example if an instructor changes, you only change the reference, you don't have to give the course a new place in the tree (and lose perhaps the URL).3 points
-
Yep, exactly what Sinnut says. And the best part: You also can import the courses with the CSV importer. Just define a page field in the course template which relates to the instructor(s). You can easily customize the CSV importer module for that case. For example a reference to instructors with ids 1012,1024,1034 should be placed in a column in the CSV export which then is tied to the page field. Of course the ids don't match "the old" ones, so you have to apply some additional logic in the importer. For example it could be possible to import the old id with the instructors in an extra field and while importing the courses you look for the matching instructor and build the relation via the page field. Search the forums a bit, especially the CSV import thread, there are a lot of good solutions hidden3 points
-
Are there scenarios thinkable where a course could have multiple instructors? In that case you would probably want to reference the instructors via a page field belonging to the course template. Or even, when a course can only have 1 instructor this might be best/flexible way. So you would have: instructors >member name1 >member name2 courses >course1 >course2 and then the course pages would have a field of type 'FieldtypePage', where you can choose one or more instructor pages, depending on your needs.3 points
-
Hi there just a first little piece of code for a simple maintainmode. Other CMS needs a setting or something else complicated.....and with PW you've simple tools to do that easy. Using 2.4 but with template setup from the actual dev with /templates/ _func.php /functions and navigation (with MarkupsimpleNavigation.... _init.php /init _main.php /template basic-page.php home.php ... so i wanna simple build up a page or later set it in to maintainmode without loosing access for bots.... so at now i'm setting up my first pw project i've the following code running perfect for building up the page: _init.php //setting the maintainpage $maintain = <<<EOT <html><head> <title>what you wanna show</title> <meta content="text/html; charset=utf-8" http-equiv="content-type"> <style> body { some basic style } </style></head> <body> <table align="center" border="0" cellpadding="0" cellspacing="0" width="400"> <tbody><tr> <td style="padding-top: 50px;" align="center" valign="top"><img src="my-fancy-logo"></td> </tr> <tr><td style="padding-top: 50px; text-align: center"> <p>Some text on the maintain thingi</p> </td> </tr> </tbody></table> </body></html> EOT; //headline or title $headline = $page->get("headline|title"); //maincontentblock $bodycopy = $page->body; // if the current page has a populated 'sidebar' field, then print it, // otherwise print the sidebar from the homepage $homepage = $pages->get("/"); if($page->sidebar) $sidebar = $page->sidebar; else $sidebar = $homepage->sidebar; // Include shared functions include_once("./_func.php"); and in my templates that shows the different pages (aren't to much in this project) basic-page.php // default settings and fuctions include("./_init.php"); if (isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/bot|crawl|slurp|spider/i', $_SERVER['HTTP_USER_AGENT'])) { // main template for building the page include("./_main.php"); }; if ($user->isGuest()) { echo $maintain; } else { // main template for building the page include("./_main.php"); }; This is just quik and dirty so if i've the time i would make a simple function within the _func.php and get the _main.php include a little bit smarter, especial with much more template files this shouldn't be redundant/repeated... Further improvments could be a checkbox on a backend page /settings/ maybe.....to check on/off maintain mode.....so it would be a simple switch in the Backend even a client could do.Next step could be a maintain template to get the text and content editable in the backend for everyone....should be not that hard and would made it complete!Hope this is interesting for someone... have fun mr-fan - use PW is having fun every second for me since i've not the huge times for coding stuff -2 points
-
new german updates for actual PW dev 2.4.16 (01 September 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--process--processmodule--processmodule-module.json pw-lang-de-dev-update.zip2 points
-
2 points
-
A simple edit link can be done with ease. Regarding in place editing: I think especially for non professionals it's important to make them aware of the fact, that websites don't come in one shape. There are mobile layouts, responsive layouts, maybe a rss feed, which is shown in a rss viewer. Ryan already talked about that earlier in this thread. Nobody wants to have content with 15 " "'s just that the next word flows to the next line. If you just don't like your client to have to leave the current page to edit, take a look at this: http://modules.processwire.com/modules/fredi/.2 points
-
These might come in handy: $this->modules->isInstalled() $this->modules->getInstall() I used these in Migrator for detecting if third party modules are installed and if they are available to install.2 points
-
2 points
-
Introducing ProcessWire ProFields: Table – it lets you literally define your own Fieldtype! This is one of the most exciting ProFields and it's something very different than any other Fieldtypes. I think it is best described by this screencast (be sure your sound is on): Special thanks to Joss for his great voiceover on this screencast. Please view the video at 720p and full screen if possible. Read more about the Table Field Table is part of the ProcessWire ProFields package now available for purchase in the ProcessWire store.1 point
-
Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.1 point
-
Manfred, just wanted to say a huge THANK YOU for your effort! Very appreciated!1 point
-
I'm confused as to why you would want bots to be able to see your content if it's under maintenance but not guests? If you use my module, I would leave it so it blocks bots too otherwise Google could easily see a PHP error or something if you are changing things behind the scenes.1 point
-
Similarly don't be drunk yourself at Las Ramblas at night or you could well get mugged. When I was last there the police just seem to sit at either end and whatever happens in the middle... happens. One guy in our group got mugged, someone tried to mug one of my brothers friends when he went a few years later - not nice. Other than that, beautiful city and lots to do, but I was on a stag do so all I remember is Sangria and Mojito's1 point
-
1 point
-
1 point
-
Schedule Posts Publish and Unpublish dates using SchedulePages module Hello Bloggers and devs! I would like to hear your thoughts on this matter. As you know, there have been requests to implement such a feature in Blog. I have decided to use the module SchedulePages to accomplish this. In fact, I have already implemented this in my dev version and it works brilliantly. Thanks to Jasper for a great module. OK, I need to make a decision whether: Scenario #1: This should be an optional add-on to Blog, i.e. those who want to use the auto-publish feature should go ahead and install SchedulePages and optionally maybe, if found on your server but not installed, Blog would go ahead and install it for you. Blog would then use the feature VS. Scenario #2: Require that auto-publish is always used. In this scenario, the user would first need to install SchedulePages before Blog is installed. If they don't, installation would halt. The issues with #2 is that I feel I would be forcing users to use a feature they may not be interested in or a feature they could implement using other means, e.g. normal normal cron vs lazy cron. I am therefore inclined to go with #1; make the feature optional. Those who want to use it to go ahead and install SchedulePages and Blog would detect that and work with it in blog-post template and quick post dashboard. The way I see it, there's 4 camps of users:. SchedulePages already installed but user does not want to use it with Blog SchedulePages already installed but user wants to use it with Blog SchedulePages not installed but user wants to use it with Blog SchedulePages not installed and user does not want to use it with blog Going with Scenario #1 would cater best for above 4 user camps, I think. Maybe make this configurable in the module post-install screen. Tick a box if you want to use SchedulePages. In that case, the checkbox would be locked for ticking unless SchedulePages was already installed [not just available] on the system (I'll see whether this is doable). Note that SchedulePages itself installs and works with two date/time fields - 'publish_from' and 'publish_until'. Blog would need to add these to the 'blog-post' template after ticking of the above checkbox. This should be doable via an include in init() that would run only once/if checkbox was ticked and SchedulePages already installed. Hope I am not complicating this. Maybe there are simpler ways to effect this? I would like to hear and consider your thoughts, thanks .1 point
-
looks nice. around 800px and smaller there's a horizontal scrollbar.1 point
-
I guess I am mixing purposes a bit here - your goal was to style the output exactly as it will appear on the frontend, but I guess I am looking more for replicating the ease of editing that repeaters have. Maybe I'll make a different extension for PageTable that works more that way. Maybe not worry about the ajax saving and just use the page save to save each of PageTable components. I'll mull over it for a bit.1 point
-
I am a bit ambivalent regarding such a feature. Of course it would be nice, but also would add a lot of overhead to this specific module. If there would be an existing solution for that (for the frontend), it would be easy to integrate it as well in this module (including necessary js and css files should be enough), because the layouts are rendered as in the frontend.1 point
-
The Slashes ( / ) are a php specific thing to implement regex patterns, while the two patterns below are different ones. The first one does only match if the input is a single word, while the latter would also match "Passwrd Passwrd" see: http://regexr.com/39e12 vs. http://regexr.com/39e18 Edit: To answer a little bit more clearly, the second one is the one you should put in the field of the processwire backend, to reflect the first pattern.1 point
-
Fixed my issue and just updating this in case anyone has same problems. Authors profiles are just users. If you have a user, you can set their blurb in the Users area. I'd renamed my /blog/ page to /blog-test/ and this is why some of my links weren't working and why the right column wasn't displaying "Recent Comments" and "View by" etc Blog settings are back since I renamed my /blog-test/ to blog/ upgraded PHP to 5.5 and updated the blog module to the latest version.1 point
-
// _init.php $GLOBALS['gallery_used'] = false; // _func.php function renderGallery(){ if(!$GLOBALS['gallery_used']) { $GLOBALS['gallery_used'] = true; return "gallery"; } else { return "already used"; } } With the exception of an error in the order your solution does work horst, thank you both.1 point
-
A quick update. Not adding image variations to the $valid array will get them removed. Although this includes variations that are still in use, these will be created again dynamically on the next page view. This is acceptable for me as I am using ProCache. As an example of the result, here is again the folder from above: 1) AFTER running the script with $valid[] = $f-basename commented out, but BEFORE page view: 19 images: 9 original size images 9 auto created "0x100" images 1 image I am not sure why it is there) 2) AFTER running the script and AFTER a page view: 37 images: 19 images from above: 9 thumbnails 9 PIM images with watermark Cheers, Stefan1 point
-
Sparrow, assuming you upgraded the .htaccess file with the PW version, I would start by renaming the .htaccess file to htaccess.txt and then try to reload the homepage. Is the internal server error gone? If so, then restore the .htaccess and start commenting stuff out to determine which htaccess rule is causing the issue. If that's not the issue, then next look at your PHP and MySQL versions: what versions are they? You'll want to get more info on the error message. Start by editing /site/config.php and enabling $config->debug=true; on the line where it's currently turned off. Reload, do you see any more detail about the error? Check /site/assets/logs/errors.txt, anything there? Look for PHP's main error log to see what it has to say. On some servers this can be hard to find, so you may have to examine the phpinfo(); result to determine the location.1 point
-
// _init.php $GLOBALS['gallery_used'] = false; // _func.php function renderGallery(){ if(!$GLOBALS['gallery_used']) { $GLOBALS['gallery_used'] = true; return "gallery"; } else { return "already used"; } }1 point
-
that may help: https://processwire.com/talk/topic/4717-global-not-working-in-templates/1 point
-
I do agree with Soma that over time there have been quite a few users that expressed their (big) interest in PW (page) versioning capabilities. On the other hand it's also quite hard to estimate how many PW clients would actually go on to use it. But a killer feature nonetheless, if done right. Anyway, it's on the roadmap for 2.6+ and if it stays there, i personally think it might be a good thing if the versioning, enhanced workflow and js session monitoring became a priority after 2.5. Why? Because i think these 3 items kinda go together. In my mind a versioning system really has the most use in some kind of editorial cycle where multiple people can work on a document (page) and maybe put versions up for review and approval, or other workflows. Ideally this would be be accompanied by a way to compare differences between the published version and/or draft versions. Maybe some inspiration can be taken from the VersionControl module by teppo. But maybe i'm taking this too far. I would be curious how Ryan sees the scope of versioning capabilities and related subjects.1 point
-
as far as I understand this, orphaned images are images without an original image, but I may be wrong. There are different variations in your assets/files folder: .0x100 // this one is (auto) created for the backend, all others are custom ones => your variations .390x100 .390x125 .390x166 .390x83 .585x125 there are a minimum of 5 variations of each original image. These are no orphaned images because their parent image are still there. 9 x 5 = 45 valid custom variations Do you not use / need them anymore?1 point
-
Thanks guys @Adrian, But getInstall() will only install modules available to install on your server no? I mean, it will not go to the ProcessWire modules directory to download (like ModulesManager) and install the 'missing' module, would it? I have tried and I get the message 'SchedulePages' installed but it isn't. I guess I could just write a script to go and download the module if it is not on the server, then install it. I am trying to avoid bundling the third party module with Blog if I can, thanks. Not to worry guys. Changed my mind..., too much effort......I'll just abort if people don't follow instructions1 point
-
@deprecated, use pageName instead. This is since 2.4. /** * Format required by ProcessWire user names * * @deprecated, use pageName instead. * @param string $value * @return string * */ public function username($value) { return $this->pageName($value); /* $value = trim($value); if(strlen($value) > 128) $value = substr($value, 0, 128); if(ctype_alnum(str_replace(array('-', '_', '.', '@'), '', $value))) return $value; return preg_replace('/[^-_.@a-zA-Z0-9]/', '_', trim($value)); */ }1 point
-
1 point
-
Obviously a much better approach from Soma! so I definitely don't deserve a "Solved" on this one Of course my original code snippet didn't exclude other fields, but I was thinking something along the lines of checking the name of the field before proceeding - just didn't get that far when posting in a rush yesterday1 point
-
1 point
-
In the roadmap I can see all the cool features are sponsored by someone. I just guess we could crowd-sponsor our own desires )) If it was possible to estimate, how much will it take to complete those "draft and live versions of any page" functionality, we could try to collect the money and get the common good. Just recently I took part in such an endevour related to Joomla. I can't say I got too much money to spend, but I'll surely find 5 to 10 bucks at least . It would be cool to see stated "this feature is sponsored by community". To not break Ryan's open source spirit down we could decide to sponsor definite amount of new functions per semester or so. We could also make some kind of voting on that, so we really take part in deciding, in which direction should this software develop. What do you think?1 point
-
Greetings, I don't doubt that the three choices are the result of a legitimate nomination process. I'm saying that if that process leads to only three choices for "Best Free CMS" it's not a very useful contest. In general, one of the problems I see in the CMS world is that systems like ProcessWire and Joomla/Drupal/WordPress are constantly put into the same category, when they are essentially different types of systems. And since CMS Critic has a mission of exploring the complexities of the CMS world, I think they should embrace their role as an analyst of CMS choices, and focus on articles exploring the dimensions of the CMS world. Contests like this just add confusion and misunderstanding. EDIT: I don't see how grouping CMSs based on whether they are "free" is generally useful. Why not group them according to logo color theme? Thanks, Matthew1 point
-
I explained that question poorly, I was thinking, while Lister is clearly an uber powerful Admin tool, as a by-product piece of functionality, could a Lister 'view' (a preconstructed 'find') be made visible on a public page (read-only, fixed results, no controls available to the public)? It would be a sort of query and results builder for custom finds. I hope that question makes sense and I've not misunderstood something obvious(!).1 point
-
Try adding this to the top of your /site/templates/admin.php, after the opening <?php tag: $pages->addHook('saveReady', null, 'makePageHidden'); function makePageHidden(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'category-site') return; // replace 'category-site' with your template name if(!$page->is(Page::statusHidden)) $page->addStatus(Page::statusHidden); }1 point