Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/26/2013 in all areas

  1. Just pushed some updates. Module is now v1.3.0 Form readme: Changes in 1.3.0 Changed module setting singular to false. This enables you load the module as a new instance with $nav = $modules->MarkupSimpleNavigation. This changes behavior for hooks attached to such an instance as it will only be called for this instance. This allows you to create multiple instances of the module to create different navigations with separate hooks. Added support for Page::listable. So you can exclude listing of pages in runtime by modifying this page permission. This can be done using a system hook on Page::listable and set the hook event to return false. Added new option date_format for created and modified native page properties. Added new option code_formatting, to enable or disable code formatting (indentation and newlines) of output markup. Added new option debug that will output rendertime and selector infos as commented inline html. Added support for Page::listable Usually you won't need this, but I needed it in a project so thought it wouldn't hurt. Usually you can hide pages from rendering in a list/navigation by setting the page to hidden in the admin. So this additional check in the module itself, allows you to make pages not listed on runtime. This can be used to check for logged in users that only should see the page listed when logged in. Example hook inside template just before calling render(): wire()->addHookAfter("Page::listable", null, "hookPageListable"); function hookPageListable($event){ $page = $event->object; if($page->template == "internal-page") { $event->return = false; // set listable to false if template "internal-page" } } Added new option debug If set to true this option will add an inline <!-- [MarkupSimpleNavigation Rendertime: 0.0171] --> after the markup output to show rendertime, and <!-- [Selector Level1: limit=3] --> on each item to see selector being used. This new version should still be compatible with older versions. But there could be instances where it could behave different when you have multiple navigations and using hooks. But chances are very small you run into this. If you have questions to the above just ask.
    5 points
  2. Hi Soma, first I thought "nice module, but maybe I should build a own customized template and navigation code" (html, classes, ...), because it's really simple to build with PW... After take a look at your documentation I realized... 'outer_tpl' => '<ul>||</ul>', 'inner_tpl' => '<ul>||</ul>', 'list_tpl' => '<li%s>||</li>', 'list_field_class' => '', 'item_tpl' => '<a href="/{url}">{title}</a>', 'item_current_tpl' => '<a href="/{url}">{title}</a>', no hardcoded markup! All configurable via options. No reason to build a own template or to reinvent the wheel. Markup Simple Navigation is really a great module! I like modules without hardcoded markup or with dedicated templates for easy customization. Simply want to say Thank You!
    3 points
  3. @saml, what I usually do is: 01. Instal ProcessWire. 02. Delete unwanted pages. 03. Leave fields as they are. 04. Leave templates as they are. 05. Rename Fields & Templates when needed. 06. You'll see that you'll reuse every single template & field.
    3 points
  4. It looks like it's something to do with the encoding (or not) of the accented characters in the "description" entry. I set up an RSS template with the same code and content you provided, and it worked OK for me. In order to reproduce the problem, I had to save the file with an encoding that wasn't UTF-8 (for me, the other main choice is ISO-8859-1). So - try saving your template file with UTF-8 encoding and see if that solves it.
    3 points
  5. pwired - see my comment here: http://processwire.com/talk/topic/5208-a-website-for-university/#entry50233 The same thing I say there about forum software applies to shop software - to do something as complex as other ecommerce solutions requires a team of developers or someone with a tonne of time on their hands and probably a year's development time minimum. Not to mention all the headaches you get afterwards supporting a complex codebase (you'd have to constantly update a lot of the payment and shipping modules for example as vendors change their code) and all the other hassle that goes with it. Many other ecommerce packages will have similar if not far more lines of code than ProcessWire to give you an idea, and I suspect it took ryan a while to get to version 1, let alone version 2. You can build anything you want in ProcessWire, but until someone turns up that has no need for an income and also has plenty of time on their hands I don't see a larger solution appearing any time soon. It does all depend on what you want to sell though - Apeisa's module is perfectly fine for a lot of situations and you can easily create a product catalogue in ProcessWire and drop in some Paypal code if you want to do something even simpler and don't need anything in the admin.
    2 points
  6. Just a quick heads-up: like you've already pointed out above yourself, you really shouldn't do this, as it seems to open a ton of new security issues. There are probably even better ways to do it, but why don't you at least create a new page (or Process module) and use PW API to handle the saving? It should be pretty straightforward, i.e. something like this: <?php if ($user->hasRole('admin')) { $target_page_id = (int) $input->get->page; if ($target_page_id) { $target_page = $pages->get($target_page_id); if ($target_page->id) { if ($user->hasPermission('page-edit', $target_page)) { $content = $input->post->content; $target_page->of(false); $target_page->body = $content; $target_page->save(); } else throw new WireException("Permission issue"); } else throw new WireException("Page not found"); } else throw new WireException("Missing page ID"); } else throw new WireException("Missing role"); Generally speaking, whenever you find yourself fetching (or, even worse, storing) data to/from native PW database tables, it's likely that you're doing something wrong (Exceptions above exist mostly to demonstrate couple of things you'll want to take care of if you do this at template level. Process modules have their own method of handling permissions, which makes that part less complex. Note that this was written in browser and I've no idea if that code works straight away, but I hope you'll get the point..)
    2 points
  7. I took the liberty of merging your two forum accounts - the details from your newer one should work fine. I very much doubt a full-blown forum solution in ProcessWire will appear any time soon - the general suggestion is to use another piece of software. This is because forum software is usually really complex, taking teams of developers at least a year to create and years after that to perfect. I know this is why ryan at least suggests using other software for this side of things - see here: http://processwire.com/talk/topic/572-release-discussions/?p=48129 If you've ever looked at forum admins for the likes of Invision Power Board you'll see that there are dozens of pages just for managing them as well so it's not as straightforward as it might seem at first. That said, it is possible to build modules that bridge the membership between forum software and ProcessWire. I've done it myself (and will one day get around to polishing and releasing the module): http://www.strategycore.co.uk - note that you would still manage the forum in the forum admin but you then have available the membership functionality and members and their groups exist in ProcessWire as well. As kongondo says, Moodle is an entirely separate piece of software. I have, in the past, shoehorned several different applications to work together and the results are always painful when you have to update one of them (not usually ProcessWire as the API functions stay the same) but even something like the forum bridge mentioned above could rbeak on a newer release of the forum software as other developers just will not design a good API and stick to it. That's one of the things that makes ProcessWire exceptionally different - ryan has gone for as close to human readable code as possible and it doesn't matter so much how the code works behind the scenes - it could all change behind the scenes (but it won't) and the functions available to you in the templates to pull out the data would still be the same. I think you may need to step back and take a look at what you want to achieve in terms of functionality as Moodle for example already has its own forum module. No offense intended, but you appear to be looking at different solutions, liking the idea of some of them and then deciding you want them all, rather than explaining what features you need. I would suggest that it is actually possible (with enough time and money) that you could recreate what you want from Moodle in ProcessWire and do away with one of the three software packages entirely, then hook it up to something like IP.Board if you didn't like Moodle's forums, but depending on your requirements from Moodle you could be talking about a year's work easily. That said, you can have forums, course modules and site pages all just in Moodle, so if time and budget are your constraints then you could already do it all in one package. There are also dozens of categorised plugin modules for Moodle on this page: https://moodle.org/plugins/
    2 points
  8. Case Study: SignificatoJournal.com: Migrating from MODX Evolution to ProcessWire Contents: * Useful MODX Fields * Custom Template Files * Template Chunks * Field Chunks * Snippets * The Writer Table * The Migration Script * URL Replacement * Image Migration * TinyMCE Code Breaks * Post Migration Data Checks * Link to Script Content I just finished migrating the magazine site that my wife and I run (http://significatojournal.com) from MODX Evolution to ProcessWire. How I did it may be of interest to other MODX users that wish to migrate their sites to ProcessWire. I liked MODX because it was so flexible. My experience with ProcessWire has been that PW is even more flexible than MODX, and it breaks the 5,000 page MODX Evo barrier that was the great bugaboo in Evo. I attempted to use MODX Revolution multiple times but was very unsatisfied with the slowness of the editorial interface. There were also other reasons that I left MODX for PW, that have been addressed by other writers. After using PW’s API to build a large web app in 2013 (which will be a different case study), and now, after having migrated my magazine site to PW, I’m absolutely thrilled with ProcessWire. I could go on and on... There were many things that I liked about MODX Evo, that provided functionality that I wanted to continue to use in ProcessWire. They included: Chunks, snippets, and a combination of built in MODX fields and custom template var “fields” that I created for my former website, including: Useful MODX Fields MODX Fields: longtitle (headline) pub_date introtext (summary) template (id of custom template) menuindex menutitle hidemenu (show in menu) * In PW, I use the three menu fields to create the menu of the site, using Soma’s excellent module “MarkupSimpleNavigation”, with code like this: 'selector' => 'show_in_menu=1' * I use the publish_date field to block display of pages with future publish_dates, as well as to show the actual date of publication set by the editor (not just the date of the saved record). Custom Template Var Fields: subtitle writer_id static_author static_author_attribution newsletter_volume_number headline_thumbnail article_type sitemap_exclude code_blocks1-7 Custom Template Files MODX Evo allows one to assign a custom template file to each article, which I found very useful. Unlike PW, MODX Evo uses a primary static data field set for each article, with custom fields added on as “template vars.” The advantage of the custom template files is that it allows one to use different display templates for different types of articles or section pages. I generally use a four level method of: - home page - multi-section page - section page - article page Given PW’s method of creating virtual data tables, aka template “field sets”, with display template files assigned to each template field set, I had to work out a method to have the same type of flexibility of assigning display template files to each page. For example, an article page might be a regular article page, with writer information, or an “article_plain” page, like a Contact Us page. A section page could be a multi-section page, with a list of sections, or a paginated section page that lists articles. I also had a need for custom section pages, to display articles based on “content_tags”. My solution was to create generic PW template data field sets, that all ran one php template file called “custom_template_controller.php.” The two main PW template field sets are: * article_page_structure_permanent * list_page_structure_permanent Using this method, when a new page is created, I select the PW data template first: and then, once I’m in the main set of fields, I select the custom template file for that page: The custom_template_controller.php is very simple, and simply pulls up the custom template file assigned to the page, and runs it: <?php ################################################################################################### # custom_template_controller.php ################################################################################################### include("./inc_vars.php"); include("./inc_functions.php"); #.................................................................... # block future publish dates; don't block home page (id 1) if ( ( $page->id == '1' ) || ( ! empty( $publish_date ) and $publish_date <= $now ) ) { # page can be displayed } else { wire(session)->redirect("/http404", false); } #.................................................................... include("./$custom_template_file"); ################################################################################################### The "./inc_vars.php" file gets the value of the field: $custom_template_file = $page->custom_template_file->select_value; and also initiates a variety of variables and template “chunks”. Template Chunks MODX Evo allows one to define “chunks” of text that can be replaced in the templates or in data fields, using {{tags}} that are replaced at run time. In PW, I divided the chunks into sets of templates chunks, and a smaller set of field chunks. Because of the way PW uses PHP as its “templating” language (which I REALLY like), I decided to simply place the template “chunks” in a file called "./inc_vars.php", and define them as normal PHP variables. Since that file is loaded before every page, the variables are available to use in the custom template files. Field Chunks For field chunks, I created a PHP function that loops through a set of “chunk” data pages and looks for corresponding tags in the body field, and then replaces them. I placed the “field chunks” branch of data pages under a hidden master page called “elements”, which I also used for custom selects like the custom_template_files. The field chunks use the MODX delimiters of curly brackets {{chunk_name}} and the contents of the chunks are replaced. For example, “{{email.pfb}} is replaced with an image of the email address as the title of a clickable, Javascript encoded mailto: link. In MODX, the field chunk system also allowed one to replace tags in text fields of data coming from template vars (custom fields). I found that my primary need for that was with code that TinyMCE didn’t like, such as data entry forms or special Javascript, so I created seven “code_block” fields, e.g. “code_block1” … “code_block7”. Seven is a bit much, but at the time I created the fields in MODX, I was using many Amazon affiliate tags for books and CDs, in various articles. Snippets MODX Evo also has handy-dandy snippet tags that get replaced at run time. For my purposes, I only need to replace snippets in the code block fields, prior to replacing the code block tags in the body text. For example, I have a form that needs to display a dynamically generated captcha image that gets created by a Perl script. So, in the code_block1 field of the article, which contains the form, I place a snippet tag: [!s_form_get_captcha!] which then gets replaced by the same function that parses the chunk tags. I used the syntax [!...!] from MODX Evo mainly for convenience. Unlike MODX, the ! exclamation marks don’t affect caching of the snippet. To work with the snippet tags, I created an array in the chunk parsing function that attaches the snippet tag to the name of a PHP include file: $snippet_array = array( '[!s_form_get_captcha!]' => '/home/sigj/s_form_get_captcha.php', ); In this case, the PHP file “s_form_get_captcha.php” contains a backtick call to a Perl script which returns the dynamically generated captcha image. But, the PHP file could contain any normal PHP code that has to be generated at run time. Here are the contents of the function that parses chunks and snippets: ################################################################################################### function parse_field_chunks($page_id) { $body = wire(pages)->get("$page_id")->body; $snippet_array = array( '[!s_form_get_captcha!]' => '/home/sigj/s_form_get_captcha.php', ); #.............................................................................. $field_chunk_id_array = wire(pages)->find("parent=1052, include=all"); foreach( $field_chunk_id_array as $chunk_id ) { $chunk_name = '{{' . wire(pages)->get("id=$chunk_id")->name . '}}'; $chunk_value = wire(pages)->get("id=$chunk_id")->chunk; $body = str_replace($chunk_name, $chunk_value, $body); } #.............................................................................. # replace code_block tags with field values for ( $count=1; $count<=7; $count++ ) { $code_block_field = 'code_block' . $count; $code_block_tag = '{{' . $code_block_field . '}}'; $code_block_value = wire(pages)->get("$page_id")->$code_block_field; # now parse code block value for snippet tags # [!snippet_name!] # [!s_form_get_captcha!] foreach ( $snippet_array as $snippet_tag => $snippet_include_file ) { if ( strpos($code_block_value, $snippet_tag) !== false ) { $snippet_value = include("$snippet_include_file"); $code_block_value = str_replace($snippet_tag, $snippet_value, $code_block_value); } } $body = str_replace($code_block_tag, $code_block_value, $body); } return($body); } ################################################################################################### The Writer Table I use the writer_id field as a popup, to pull in an id from a data table of long term writers. When an article page is displayed, code grabs the id and pulls in the writer info, including a photo, attribution and Javascript encoded email address. In MODX, I had to use a custom table. In PW, I simply created a template field set called ‘writer_page_structure_permanent.’ I use a ‘static_author” and “static_author_attribution” field for those times when an author is a one-off writer. My code tests for a writer dropdown ID for ‘Non-Registered’ writer, and if the static fields have something, then that data is displayed. Template Structure Here are some screen shots of my PW template structure, which essentially replicated my previous MODX structure: Templates: List Page Structure Permanent: Article Page Structure Permanent: The Migration Script One of the challenges I faced with my script to migrate the data was the assignment of the correct parent of each article. Luckily, I wanted to keep the exact structure of the section and article tree and the urls. Since I didn’t have tens of thousands of articles, I decided to create an associate array of the sections and articles under the first level of the home page (i.e. starting at level 2), and then use that sorted list to create the ProcessWire parents before each lower level of section or article. I built the script dynamically, testing as I went, so I wouldn’t say that the script is fit for any and all MODX situations. It’s heavily tailored to my installation, and is missing a few elements that I missed until after I had finished with it (thus causing me to fix some things by hand). URL Replacement I had to parse through each article, in both the body, summary and subtitle, to make sure that any internally pointing MODX urls were replaced with the full url. MODX Evo uses the syntax [~ID~] in the “<a href...” tag to dynamically create the full page url at run time. I had to create a routine to replace the ID tags with page urls, e.g. “/columns/some_article_name”. Image Migration I first took the lazy way out and thought that I could simply move the “/assets/” folder from the MODX installation over to the new account. However, when I opened a PW page in edit mode, the links to the /assets/... images were there, but the images weren’t attached to the page, and thus, in edit mode, the image didn’t now show up in the edit box. I therefore added a routine to copy the images to each page. TinyMCE Code Breaks I found that TinyMCE kept trashing my various CSS codes that came over from MODX. I tried adding various tags to the body field’s “valid_elements” field under Input / TinyMCE, but finally just changed valid_elements to: +*[*] It’s a bit radical, I suppose, but my editors are fully trusted. After that, my migrated data was fine. Post Migration Data Checks After I migrated the data for the umpteenth time, in order to get it right, I still needed to do a variety of clean up tasks. I found the Selector Test module by Niklas Lakanen very useful (Thanks, Niklas!), and used it to run checks like: body*=src\=\"{~root_url}assets (which looked for left over links to /assets/ which came from MODX) I also queried the MODX and PW tables directly, using SQLYog, a Windows MySQL client. I ran a script that compared the results of a find command (find . -type f -printf "%f\n") under the MODX assets folder to the files under the PW site/assets/files folder. I found about 70 files that were not copied, some because they were in template files, which my script didn’t parse, and some because the filenames were problematic, like files with spaces, etc. The script took into account the PW code that changes uploaded file names. To do that, I copied the PW “validate_filename” function into my script. For all my checking, I still forgot things, like parsing the subtitle or summary fields for hrefs, which I then had to go and do by hand (since there were very few records like that). I also created a few redirect aliases by hand, instead of trying to handle them via the script. All in all, this migration confirmed once again that website migrations are a Bear. Ugh. I’d rather not do them. Link to Script Content Here’s the link to the script. Note that it didn’t catch everything, and it was heavily tailored to my design. Also note that I’ve removed some of the private data, like writer’s names, etc. sj_modx_pw_migrate_script.php That’s my case study. I hope it may be useful to another “MODX Refugee”. Peter Falkenberg Brown
    1 point
  9. I'm using a lot of internal page links on my website. When they are in fields they are easy to fetch with asmSelect fields. But I also use them in textarea fields. Adding a link brings the pages menu, but then the hassle starts.... I have a few hundred names and I want to link to one of them, it means guessing where the letter H or S will be in the list of pages. For H start at page 12 or something and then click next, next.... For S definitely go to the last page and click previous, previous.... Is there an easier way that I haven't found out about perhaps?
    1 point
  10. @Julian: since PW is simply using MySQL NOW() function, I'm guessing that your database has different opinion about correct timezone than PW. Typically it would be using the server timezone, but that's not entirely certain. This Stack Overflow thread contains some tips that could prove useful here.
    1 point
  11. OK, so finished my marathon forum catch-up...14 pages of threads! Here's signs you've been away too long..... 1. You get this message when trying to like a post... 2. Soma has (finally) updated his personal web site! 3. Pete trimmed his "facial" hair (ahem, fur) 4. Arimo is the new Arial, no Arial is the new Arimo, no actually Arial is still...uh, Arial..... 5. Willy C is designing a new top secret Admin theme. ;-) 6. You are no longer sure what this means.. 7. It's Christmas eve and you are starting a lousy thread... 8..........?
    1 point
  12. Indeed. We all need to cut down our working hours or take more holiday to keep up I had 14 pages to get through too, but I chose to go at it forum by forum, picking topics that looked interesting to read (you can hover over a topic and a little down arrow will appear), then click that to see a short preview) and reading them, then marking the forum as read. Cheating I know, but I have no trouble in admitting I don't have time to read everything any more when it's backed up as much as that
    1 point
  13. you can use the 'PW blank profile' to start from zero http://modules.processwire.com/modules/processwire-blank-install/
    1 point
  14. Fieldtype File from folder I “needed” a module to select a file from a folder, using an <select> and store the filename. There's only 1 setting: The path to the folder to list. The Path is relative to the templates directory. So if your files are located in /site/templates/scripts/, type scripts/ in the `path to files` setting. here's the gist, enjoy. This module is released because it was useful for me in several projects.
    1 point
  15. Hi everyone! I would like to provide inline WYSIWYG on-the-page editing. Ideally I would like my pages to be editable like in this example: http://nightly.ckeditor.com/13-12-19-07-06/standard/samples/inlineall.html The CKEditor option for inline editing is based on the HTML5 contenteditable attribute (like in http://html5demos.com/contenteditable) But with the editor there are the usual editing options, rather than only being able to change the text. Before coming to PW I´ve been toying with this little CMS: http://gpeasy.com/ I had chosen gpeasy exactly because it provides intuitive front-end editing (to me their previous version was almost more intuitive). It is a flat-file CMS and I would say it´s geared towards small projects only. I didn´t get on so well with adapting various aspects, mainly the back-end, and I´ve come to PW for its flexibility and scalability after looking at about 20 different CMSs earlier this year. (None of them provide front-end editing that way, except for gpeasy) So my aim is to build PW-sites that are editable like in the CKEditor example mentioned above. (Just the page content, not other things for which I find the current PW back-end pretty perfect.) So far I haven´t really worked out how to save the editable content on the pages to the DB. Actually I´m not quite clear on whether this would be only a simple tweak or a major project. Has anyone looked into this already? What are your thoughts? P.S.: I´ve looked at the Fredi module. It´s nice but doesn´t really seem to provide complete WYSIWYG on-the-page editing like I´m envisioning. I´ve also seen the Page Frontend Edit module, but somehow have not been able to make it work - I don´t expect it´s what I´m looking for. EDIT: I´ve just seen that they´re working on something sort of like this over at Drupal, using the Aloha Editor. From what the project looks like there I get a feeling getting this to run is not just a "simple tweak", even if it might be easier to implement in PW... => ...looking at the API now I think maybe it is not all too difficult to accomplish, we´ll see. Also with TinyMCE something similar is possible I see here. But I suppose whichever editor you use the same issue to solve is how to transfer the edits from the front-end to the DB.
    1 point
×
×
  • Create New...