Leaderboard
Popular Content
Showing content with the highest reputation on 12/07/2016 in all areas
-
Welcome to the PW world @dg234! Your site reads like the perfect task for ProcessWire. While you don't need to move your data from its external tables, chances are high that you will want to do that and create a page for every hike that holds its data, track(s) and images. PW's template files are (unless you install a template engine module like smarty) just PHP files outputting your HTML, so you have every freedom regular PHP scripts give you. PW also provides you with a PDO wrapper to its database in the $database variable, or you can use the underlying WireDatabasePDO class to access an external database. Or use PHP's native database layers. Or use a third-party ORM layer. Whatever you fancy. You don't have to upload your images one by one. You can either drag and drop a number of files at once in the backend (though POST limits may hit you there depending on the server settings) or FTP them to the server and create a short bootstrap script that adds them to their pages. Since you control the HTML, you can include whatever scripts and styles you want, either generically (in such cases I like to put them into an extra include for the header, like _header.php, to keep them organized) or on a per-template basis. If you have a generic page layout but want to add different includes and styles depending on the template, you can use the (popular) strategy of automatically appending one "master" PHP template that produces the HTML and fill the variables used there (like e.g. $content and $headers variables) in every individual template's file as explained here. PW lets you override that setting on a per-template basis, so, like with most things in PW, you have every freedom. Just keep in mind that PW's pages first and foremost are equivalents for tables to store your data. The fields you assign in the backend template are their columns. Page fields, Repeaters and the implicit parent-child relationship are links between these "tables". Not every page needs to have a PHP template, in that case it can't be viewed directly but still used to hold and render data in other pages, but once you have your data in pages, it's easy to display it as well as search for it using PW's extremely powerful selector API. To wrap it up, you'll be able to do most if not all things you need with PW's default functionality and a handful of already available modules. I don't see a need to develop your own module yet, but there is a getting started documentation for module development in the online docs and, if you find that you do in fact need to, just ask here and you'll find a wonderfully helpful community.7 points
-
Hi @Nils Wiere Try this: $pages->find("template=B, sort=parent.title, sort=sort"); or this $pages->find("template=B, sort=parent.sort, sort=sort"); Not sure that this will work, but give a try. As alternative: $parents = $pages->fint("template=A, sort=sort"); $items = new PageArray; foreach($parents as $parent) { $items->import($parent->children("sort=sort")); }6 points
-
German web design magazine PAGE published in their latest issue (01.2017) an article about WordPress alternatives. One of the four introduced alternatives is ProcessWire, which is praised for its5 points
-
If you search using ~=, you're performing a fulltext search (aka natural language search) that only looks for words. If you need to be able to search for non-word characters too, you'll have to use %= (LIKE). For fulltext, you'll likely need to clear out any non-word, non-digit, non-whitespace and non-connecting characters, e.g. with '/[^\p{N}\p{L}\p{Pc}\p{Zs}]/u'.4 points
-
Do you mean to put HTML code into a field in the admin backend? Don't do it. It is probably 'bad design'. Anything in your fields / pages should be just content. Anything markup should probably be some php file under your templates folder. A common approach is a "partials" folder where one could store snippets of markup which can be placed here and there. Have a look at these methods: http://processwire.com/api/ref/files/render/ http://processwire.com/api/ref/page/render-field/ http://processwire.com/api/ref/page/render-value/ http://processwire.com/api/ref/files/include/ They all have the purpose to render some .php file in one way or the other - or html markup. Quick example: // templates/template-file.php <?php namespace ProcessWire; $output = $files->render('snippets/sidebar.php', ['hello' => 'hello world!']); include('./layouts/layout.php') // delayed output ?> // /templates/snippets/sidebar.php <div id="sidebar"> <?= $hello ?> </div> // /templates/layouts/layout.php <html> <body> <?= $output ?> </body> </html> Sometimes it is good to not worry too much about the theoretical "right way" - I also often do. But often it just prevents me from actually learning right away Maybe post an example of the sidebar HTML you want to include - We / I could give you a better advice if we see the actual code because it is more clear what you are up to. cheers!4 points
-
For import of the hikes with images, you could use the ImportPagesCSV Module. I've used it for many simple occasions. A breeze. You will have to create a template with fields you need for your hikes. On the import screen, you can assign columns to fields and as long as the images are provided as http links the module can access, download and import them just like that. If your site structure is not too complex you might as well migrate all data this way.3 points
-
My few cents: I recently began to make a clearer distinction between the templates folder and the site folder. So anything in templates shall just be real "templates" and related stuff for the frontend. Though the template files function as controllers. But well, thats processwire ... In site/ I now have vendor/ with composer packages—because they are no templates, of course—and include them in site/init.php. There is also a /site/functions.php ... my own 'classes' become processwire modules. In templates: php related: /fields /components (like fields but with some extra functionality ... work in progress ... anything can be here. parts, snippets, head, partials, js css and php is bundled and provided together) /emails (html email templates to render maybe) /padloper (if I use padloper) /layouts (main "framing" templates for delayed output method) /forms (some custom forms?) other /scripts /styles /... Edit: If you are new, you might want to check out this blog entry about site/init.php or site/ready.php ... https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/ Huh, I am recommending the same blog entries all the time - but they really helped me structuring my processwire sites. (It's nice to rely on processwires own ways - like a best practice built in .... or so .... whatever ....)3 points
-
If going that route, I'd recommend you put your code in a file and call it via wireRenderFile() in the module. Have a look at the support thread for some of things guys have been able to pull off using the module.3 points
-
Not to put you off making your module, but I believe RuntimeMarkup can do this.3 points
-
ProcessWire (again) is featured in the c't: One of Germany's biggest and most renowned IT magazines. The article is about alternatives to WordPress. WordPress-Alternativen: CMS-Auswahl leicht gemacht2 points
-
hi from the API side you can set the values like this: $page->setOutputFormatting(false); $page->images->trackChange('title'); $img = $page->images->first(); // or whatever image you want $img->title = 'Title in default language'; $img->title($languages->get('fi'), 'Title in Finish'); $img->title($languages->get('de'), 'Title in German'); $page->save(); $page->setOutputFormatting(true);2 points
-
Hi all, the renowned German magazine for computer tech, c't, in its most recent issue #25/2016 is presenting several "WorldPress alternatives", and ProcessWire is among them. (My translation.)2 points
-
2 points
-
If you have the filecompiler turned on, you usually shouldn't have to do anything to upgrade from 2.x to 3.x. If you don't want to use it, all you should have to do is add: namespace ProcessWire; at the top of your template files. Generally there should be no need to prepend all wire() calls like that.2 points
-
Have you tried to login a specific user from within the script? Maybe a specialy created user 'cli', who has superuser rights granted? I'm not sure, but if you run that script form the browser, and you was logged in before with your admin account, than the script also runs in that account.2 points
-
I knew there's an easy solution (as always in ProcessWire) – thanks Zeka! I wasn't aware that we have a sort option "parent.sort". So for me, this was the solution: $products = $pages->find("template=B, sort=parent.sort, sort=sort");2 points
-
Page access in the backend is not handled by template access rules, but by the module's config (permission): https://processwire.com/api/ref/modules/get-module-info/2 points
-
v2.4 is up: added additional filters and macros (optional, see README) added 'languages', 'fields', 'templates', 'logs' to the default API variables (suggested by Pixrael) remove cache directory on uninstall2 points
-
That's not correct. $page and $pages are the only api variables preregistered as local variables. Other processwire api variables are available via the access method in classes: $this->wire('api-name'). And you can always create as many own variables as you like in there. Nobody needs you to use the local variables $pages/$page for the code. They're just there for convenience.2 points
-
The version I just committed makes those (and lots of other config settings option) translatable. OT - this version also includes lots of new options for adding/updating/overwriting images when importing a CSV file.2 points
-
If your module extends Wire or any Wire derived class, you should be able to this in your init() method. public function init() { $this->wire('html', $this); } Are you sure the module is loaded when the template is rendered? See the autoload option in your modules config: public static function getModuleInfo() { return array( 'title' => 'Example module', 'version' => '1.0.0', 'singular' => true, 'autoload' => true, ); } You could also load it manually: $html = $modules->get('ModuleName');2 points
-
Thanks for the great module, but I get the following error in php7 environment. It runs smoothly in php5. require_once(): Failed opening required '/home/admin/public_html/site/modules/AutoSmush./ImageOptimizer.php' (include_path='.:/usr/share/php') The error is gone after I change line 5 in AutoSmush.module from require_once /*NoCompile*/__DIR__ . './ImageOptimizer.php'; to require_once /*NoCompile*/__DIR__ . '/ImageOptimizer.php'; (remove dot before /ImageOptimizer.php) However, in Local tool optimizers info, the module cannot find any exe.(EDIT: I found that you have posted solution above. Let me try first, thanks) EDIT: Solved by simply apt-get install optipng jpegoptim gifsicle2 points
-
FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup Modules Directory: http://modules.processwire.com/modules/fieldtype-runtime-markup/ GitHub: https://github.com/kongondo/FieldtypeRuntimeMarkup As of 11 May 2019 ProcessWire versions earlier than 3.x are not supported This module allows for custom markup to be dynamically (PHP) generated and output within a page's edit screen (in Admin). The value for the fieldtype is generated at runtime. No data is saved in the database. The accompanying InputfieldRuntimeMarkup is only used to render/display the markup in the page edit screen. The field's value is accessible from the ProcessWire API in the frontend like any other field, i.e. it has access to $page and $pages. The module was commissioned/sponsored by @Valan. Although there's certainly other ways to achieve what this module does, it offers a dynamic and flexible alternative to generating your own markup in a page's edit screen whilst also allowing access to that markup in the frontend. Thanks Valan! Warning/Consideration Although access to ProcessWire's Fields' admin pages is only available to Superusers, this Fieldtype will evaluate and run the custom PHP Code entered and saved in the field's settings (Details tab). Utmost care should therefore be taken in making sure your code does not perform any CRUD operations!! (unless of course that's intentional) The value for this fieldtype is generated at runtime and thus no data is stored in the database. This means that you cannot directly query a RuntimeMarkup field from $pages->find(). Usage and API Backend Enter your custom PHP snippet in the Details tab of your field (it is RECOMMENDED though that you use wireRenderFile() instead. See example below). Your code can be as simple or as complicated as you want as long as in the end you return a value that is not an array or an object or anything other than a string/integer. FieldtypeRuntimeMarkup has access to $page (the current page being edited/viewed) and $pages. A very simple example. return 'Hello'; Simple example. return $page->title; Simple example with markup. return '<h2>' . $page->title . '</h2>'; Another simple example with markup. $out = '<h1>hello '; $out .= $page->title; $out .= '</h1>'; return $out; A more advanced example. $p = $pages->get('/about-us/')->child('sort=random'); return '<p>' . $p->title . '</p>'; An even more complex example. $str =''; if($page->name == 'about-us') { $p = $page->children->last(); $str = "<h2><a href='{$p->url}'>{$p->title}</a></h2>"; } else { $str = "<h2><a href='{$page->url}'>{$page->title}</a></h2>"; } return $str; Rather than type your code directly in the Details tab of the field, it is highly recommended that you placed all your code in an external file and call that file using the core wireRenderFile() method. Taking this approach means you will be able to edit your code in your favourite text editor. It also means you will be able to type more text without having to scroll. Editing the file is also easier than editing the field. To use this approach, simply do: return wireRenderFile('name-of-file');// file will be in /site/templates/ If using ProcessWire 3.x, you will need to use namespace as follows: return ProcessWire\wireRenderFile('name-of-file'); How to access the value of RuntimeMarkup in the frontend (our field is called 'runtime_markup') Access the field on the current page (just like any other field) echo $page->runtime_markup; Access the field on another page echo $pages->get('/about-us/')->runtime_markup; Screenshots Backend Frontend1 point
-
This isn't tested, but i use this general sort of thing all the time to change page URLs. It is within the hook function that you need to deal with your logic of when to add the .html and when not to, you will need conditional statements... /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'something') { $event->replace = true; $event->return = $page->name . '.html'; } }); Snagged from here originally:1 point
-
Yes, that version works like a charm! All entries are translatable now. Fantastic1 point
-
Ah yes - try the latest version - those should also now be translatable. Sorry, in a rush, but hopefully that will work. Perhaps I can improve things in the future - I honestly haven't played around with module translations at all1 point
-
Great Adrian, thanks for the great and responsive support, it's much appreciated Tested it out... maybe it's just me... The setting dialogs of the module edit screen are translated now (see screenshot below) - great! But I think the translation is not reflected yet on the normal content pages where the module does it's magic - there it still shows up like in my screeshot above.1 point
-
1 point
-
Nice!!! I'm glad it works nicely for you! If you insist on the beer I will send you my paypal address ;P1 point
-
Yes, this is how my site config.php looks like: /** * Installer: File Permission Configuration * */ $config->chmodDir = '0770'; // permission for directories created by ProcessWire $config->chmodFile = '0660'; // permission for files created by ProcessWire $config->fileCompilerOptions = array( 'chmodFile' => $config->chmodFile, 'chmodDir' => $config->chmodDir, ); That's an installer issue, it should add those two settings in /install.php after line 716.1 point
-
My friend, this works perfectly and right out of the box. It solves my issue even better than pre-selecting options on a per-field basis. I would like to buy you a beer!1 point
-
1 point
-
@benbyf - Looks like it works well here as well. The issue occurred once after a full refresh, but couldn't replicate it again. As for the absolue/fixed, it remained in place as I scrolled - that was with the CSS applied to the video tag/element.1 point
-
The stripe module @kongondo mentioned above works really well.1 point
-
Try it out! There is no definite solution ... Just remeber to keep markup always in .php files - I often put side-wide options into the home template. But if they are not relevant for the editor it is probably better to put them into the .php files. For example you could add options to the $config variable in init.php <?php $config->my_site_options = array(); $config->my_site_options['nice-color'] = '#123456';1 point
-
hey kixe, its working really well (1.0.3)... didn't really troubleshoot the issue much.... but what i did was delete the repeater field which had the button in it.. and created a new one with the button... worked like a charm... for me... thanks mate1 point
-
There's these two payment modules in the modules directory, for PayPal and Stripe. I'd go with the commercial e-commerce module Padloper though.1 point
-
1 point
-
ProcessWire is a nice out-of-the-box solution in storing custom content, so you're set in storing those listings or payment information. The actual payment processing does need to be handled either by a 3rd party modules or your custom code and very much depends on what you need there.1 point
-
Obrigado, Sérgio But this doesn't help. I am with PW 3.0.42. Since the problem resides actually on the language translation panel, it is not that important. Some day, I will find. Boa noite.1 point
-
Actually, I just remembered that I made a module which just aims for that, but relying on the new pages to inherit those "base settings" from parents. https://github.com/blynx/AdoptDefaultsFromParents What it is about: In the module settings, you can define templates that hand over the values of fields (which you also have to define) to newly created pages below them. Also, you can decide whether the new pages inherit the values only from the immediate parent or from the closest parent with that field. I used it for a shop - so that products inherit some values from their product-category (parent page). The product-category defines some basic common settings for the products then ... Yet, I haven't tested it with all sorts of fields - it might work well with that checkboxes field (options?) - it works with pagefields, simple texts, etc ... but not for images / files ... it simply copies the field value via setAndSave() You can have a look at the code there on the github page for inspiration - or even use the module if it suits you Or, here is the basic code to put into an /site/init.php file (see: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/) <?php wire('pages')->addHookAfter('Pages::added', null, function() { $page = $event->arguments(0); if($page->template->name == 'my-template-name') { // save outputformatting state // and set to false $of = $page->of(); $page->of(false); $desired_value = ## my desire ## // set the desired field value $page->set('that-field-name', $desired_value); // save page // and re-set of to initial state $page->save(); $page->of($of); } }); cheers!1 point
-
No, there isn't. And there is no reasons to prefer .html endings to slash even from SEO point.1 point
-
some quick options: check for url segment 'news.html' off the root and then render the /news/; for 'my-fist-post.html' you could grab the url segment in the /news/ template, explode it at the period and then use the first part to find and display the post. you'd need to hardcode the links or do a hook on the page path to rewrite the URLs of the pages1 point
-
@Rajiv I was very busy with other stuff today. Now I had a little time to check the module within Repeater (you didn't mention the usage inside a repeater). I couldn't reproduce your error exactly, but I fixed some other (maybe related) stuff. I pushed an update 1.0.4. Please try out and tell me if the error still exist. Which PW Version do you have in use?1 point
-
Do you need a temporary hosting place? I have room to spare in case you need it.1 point
-
I don't have any experience to be honest with Processwire, just found about it from a friend. I want to make a directory sort of website where users add content and others view and apply for it. What I had in mind was Expression Engine because had this huge flexibility but then I saw PW and was basically the same principles, but atleast I could play with it without buying the core functions. Anyway, coming back to Ecwid, Macrura is right you have to add the products from the Ecwid interface. So basically you add them and after you can copy two types of code to display them in your website. 1 - is the whole list of products, like a grid style let's say and when you click on one opens up the dedicated page for that product 2. a sort of widget or buy button that is just for one product. Like the Shopify button if you want a comparison. Downside is that you have to edit the appearance of the cart and products from the Ecwid admin page, through custom css. Quite flexible I would say but nevertheless. Good aspect is that you can place this cart interface in 20 websites if you want and have the same admin page. So you can sell on facebook, on your website, on your blog, or pretty much anywhere. You can create a page from PW I suppose for each product and just add the Ecwid button for AddTo Cart. And when the buyer clicks the shop, pops on top of your page. You can also redirect it to a different page if you want to make it look like is integrated well dith the rest of the website. Here is my website if you want an idea. I use it with wordpress, but I created some sort of custom pages for products. You can see it best at the Flio Up details page. I believe can be done easily with PW. Loads a bit slow as I have to restructure but anyway, maybe after holidays. In terms of features they are quite rich as any other big ecommerce. But more importantly is easy to manage your sales. if you start having more than 100 orders/month this becomes annoying and time consuming with woocommerce for example. You can't copy paste properly addresses for labels, can't manipulate or modify orders fast and accurate, 10 plugins to keep track with, is a mess in my opinion. If you focus on handling an ecommerce as a business take a dedicated ecommerce platform like Shopify, Ecwid or even BigCartel, Magento. Saves a ton of time, money and headaches. You can have it for free with up to 10 products. That is really how I used it for 1-2 years just because I didn't need anything, the full features are there. Just recently switched to a paid plan of 15 euro/month to have access to some better SEO and apps.1 point
-
Announcing that I've tested and can confirm that RuntimeMarkup is compatible with ProcessWire 2.8.x and ProcessWire 3.x1 point
-
Image & File Dependencies Allows Image and File fields to be used in inputfield dependency selectors. Note: prefix field names with an underscore in your dependency selectors. Usage Install the ImageFileDependencies module. You can now create an inputfield dependency based on the number of images or files added to a Image or File field. When you create an inputfield dependency for a Image or File field, prefix your field name with an underscore. Example for a field named 'images': _images>3 Note that you do not include a '.count' subfield in the selector. https://github.com/Toutouwai/ImageFileDependencies Demo1 point
-
if Padloper doesn't meet your needs, I would go the Shopify Button route.1 point
-
First of all, your question is asking to compare apples to bananas. ProcessWire is first and foremost a CMS, but with a great (smallish) framework beneath it, whereas Laravel and the others you named are big feature-rich frameworks. But to answer it anyways: (In it's role as framework) I've never regretted choosing ProcessWire for what it does, but if so rather for what it doesn't. E.g. tests are first class citizens in other frameworks out there and ProcessWire doesn't have that. Also ProcessWire's core is not the kind of framework which does come with all batteries included. If you need more advanced features e.g. like queueing stuff for later processing or handling notifications it's often more manual work, than it might be in your alternatives. On the other hand you'll get great data-modeling tools and the accompanied backend nearly for free. If you rather want to compare ProcessWire to other CMSs the bullet-points would certainly be quite different, as the use-cases are probably quite different.1 point