A good point. The INSTALL file contains:

chmod 777 -R application/cache

but this is missed for users installing. Simplepie will have the same issue.

Added to internal tracker, we had a similar ticket for SimplePie already.

Fix pushed this morning to v0.9.7.3-dev (master).

1.) This is an issue when using PyroCMS on PHP 5.3 which was fixed in v0.9.7.x (cant remember which). Please ensure you have the latest by downloading from the Downloads tab and clicking v0.9.7.2, or download master which will give you the current v0.9.7.3-dev (stable-ish development build).

2.) I spotted this one a while ago but I cant seem to re-create it. Possibly fixed in v0.9.7.3-dev.

3.) We have had lots of reports of Apache crashing when using WAMP or XAMPP and PHP 5.3. Are you having problems running the installer, or another page?

Installer crash is mainly caused by a MASSIVE HTTP header (too big for PHP to handle) which I think is caused by MySQLi (investigating).

All of this has been fixed. Please post back new details if installer is still suffering on Uniform server, but it should be supported fine now.

This has been added as a ticket to our internal system and will be taken care of in the next release. Thank you. :-)

Can you try v0.9.7.2? Several installer issues have been fixed since v0.9.7, this may be related to one of them.

Yes, tried both 0.9.7.1 and 0.9.7.2 with no luck.
(edit: is there a debug mode?)

It's more serious then i thought.
Console reports: Formulating crash report for process httpd[8158]

We already have an issue for this, but I have no idea wtf is going wrong here. Closing as I dont want a duplicate thread.

http://github.com/philsturgeon/pyrocms/issues#issue/94

As an immediate fix, try adding pages_m to the models line in application/config/autoload.php

It has 'pages'=>'pages_m', already.
I added as following. but it still gives an error.

$autoload['model'] = array('permissions' => 'permissions_m', 'news'=>'news_m', 'modules_m', 'pages'=>'pages_m', 'pages_m');

Ok remove that from pages_m. Are you sure you are using v0.9.7.2 and not the current master copy?

http://github.com/philsturgeon/pyrocms/downloads

Pick v0.9.7.2 from there, otherwise you are using potentially unstable copy. I will start changing the version to something like v0.9.7.3-dev after a version is tagged to stop this confusion happening again.

Did this work in the end?

I have fixed the file. Drop me an email with any other changes you had in mind so we can discuss them. :-)

the email was sent

I've added a ticket for this to our internal tracker. It will be included in the v0.9.7.2 release.

It looks like this script is trying to create the asset_folder table twice as well.

i did also have almost the same problem
mine were 2 tables: asset and asset_folder
i removed the double create table (both underneath create table user)

also i recall there were couple of tables missing their fields or settings
for example:
- inside create table settings: missing set('password') on field type - table navigation_links missing field target

if you guys know more of this mistakes, please share them with us too

thanks for this great ci cms

one more problem
on mac, using mamp, i can install this cms almost smoothly
but when i try to install pyrocms on windows, using wamp
after step 4, it just stop and got back to step 4 again
asking me to insert database name, etc
please help me out

Can we stick to one bug per issue please? Hard to track otherwise.

All of these bugs have been solved in the bleeding edge (current codebase) and some are fixed in v0.9.7.1 (mainly installer issues with step 4).

Thanks for pointing them out, enjoy Pyro!

Yes you could!

:) ok ill make it then you put in the next release:)

Thank you for the bug report but this has already been fixed and pushed to master.

Please before posting a bug report could you have a quick look at the history or directly at the file in question just to see if it has been fixed already? Saves everyone time and means you can just grab the new code instead of waiting for a fix.

Cheers,
Phil

Withough sounding like an ass, if you find a fix let me know. I have no access to either of those browsers right now and if I'm honest I cba to support them. Who uses FF2?

sometimes my projects I need support of IE6-IE8, FF>=2.0 etc ...

I haven't found the solution, but I've seen that opening in new tab/window do not inspire this issue.
after investigation I guess that issue inspired in
application/assets/js/admin.js lines 83-103.
ajaxify (or rather Get method) adds '?' and current time to prevent retrieving of the cached page

What do you mean by "menu doesn't work."?

The links dont go anywhere or the animation is messed up?

Do you get a JavaScript error?

If so, can you post the JavaScript error?

If not, can you post a screenshot that could help?

You need to give me SOMETHING to work with if you want this fixed, otherwise I can't do anything about it.

I click of top menu item such as 'Categories', 'Comments', 'Navigation' etc.
for instance, i click 'categories' link. I should see list of categories. I don't see them in FF2.. I saw the html source. The html source was modified correctly.

The reason of failure work in FF2.0 and IE7.0 inspired by incorrect changes of jQuery1.3.2 attribute 'html' after jQuery1.2.6 ( ajaxify was developed for jQuery1.2.6, tested for FF>=2, IE>=7.0).
I've noticed jquery community about this bug.
To solve this issue for PyroCMS you'll need to change this file: "application/assets/js/jquery/jquery.ajaxify.js".

You'll need to add these lines:

if(typeof data == 'object'){
    data = data.html();
}

after line number 344 (after these lines of code):

if(!jQuery(current.target).size())
    jQuery.ajaxifylog('Warning: Target "'+current.target+'" couldn\'t be found.');

}

I tested my changes in FF2, and I haven't tested in IE7 yet. but i guess, the results will be successfully too.

Implemented. Thanks.

You make a good point. We had planned to rewrite the short tags ourselves for performances sake, but this is obviously taking a while as its an ongoing "as we find them" kind of job.

I'll enable short tag rewriting for now then hopefully we can turn it off by the time we get to v1.0.

Done.

Made this into a ticket on our internal tracker, and it wil lfind its way into v0.9.8. This can be done with a manual edit to the application/config/database.php file for now.

Thanks for that, will make an appearance in v0.9.7.1.

Neither is "more accurate". em is relative to the font size, which we reset to a consistent default, meaning that neither IE or FF will be any different.

This is not an issue.

You can watch the differences in FF and IE if you used em !!! and try it px there is no difference at all !

Im not sure what the problem was here. Can you provide a screenshot?

when u click on Settings in menu / 3 times or row , try click again , it will not expand !
that's it , because the li still has active class .

While this is possible, its an ugly non-modular solution.

This is something we will address when the modules move over to the Database. Then they can be easily ordered via drag/drop and the order can be saved.

Sorry to close this one, its just something we cant do right now.

I found Solution by removing $('a[rel*=modal], a.modal').livequery(function() { in admin.js file !

Meabed: You cant just delete random bits of code to fix one error. That will stop all modal links from working!

I'll look into this error, thank you for reporting it, but please leave the solutions to us.

This should be fixed in v0.9.7, can you confirm?

It didn't Work yet ,
Meabed: You cant just delete random bits of code to fix one error. That will stop all modal links from working!
btw am Experienced web Developer am not a kid playin around :)

Deleting this will stop modal i know ! but you can simply change the modal links because it IE says missing String ! so its maybe the selector missing something ?
Also by Deleting this Line , i got no problems At ALL !and the script working fine ! ALL functions !

I guess that when Internet Explorer is the only one complaining it's IE's fault ;)

If it breaks modal windows then not everythin works fine! We'll find a proper fix but please provide some screenshots or error messages from firebug. Or a step by step approach of how to recreate this error as I cannot recreate it.

yes indeed its IE fault , i don't like IE also , but all the people still using it :)
The Error when u login to the control panel in IE 7 , the style is ok , the sidebar menu is different ill post screen now , also the Table Sorting Doesn't WORK !
Screen Shot : http://yfrog.com/5z43780055j

I cannot test this on IE7, but from the screenshot I am not worried about those issues. If it WORKS in IE7 then that is good enough for me.

Other than a few slight display issues, the only problem here it seems it table sorting. Short of removing the line for modal windows, if you find a proper fix then please post it here.

Comment those lines , i know it will remove the Loading image from the Facebox , but it still have fading effect .

    // Facebox modal window
    //$('a[rel*=modal], a.modal').livequery(function() {
//      $(this).facebox({
//          opacity : 0.4,
//          loadingImage : APPPATH_URI + "assets/img/facebox/loading.gif",
//          closeImage   : APPPATH_URI + "assets/img/facebox/closelabel.gif",
//       });
//  });
    // End Facebox modal window

it working like this :)

Solved. The IE7 JS engine does not support , at the end of a property list, but Gecko engines and WebKit do. Fixed in master.

This is fixed in v0.9.7-beta1 which was released last night. :-)

Thanks for the suggestion, I'll create a ticket for this at our private bugtracker :)

I have made a ticket for this in our niternal tracker.

This is an issue for older MySQL versions as in 5.x it does not complain about this sort of thing. Please let me know if you find any more, I dont have any 4.x installation available to me.

Well I am not running a MySQL 4.x but:
MySQL 5.1.39-community via TCP/IP

Anyhow, you triggered my with the MySQL remark.
I made a new install on another system (so I had correct tables again) of PyroCMS and it showed the same problems.
Then I checked the SQL mode of MySQL (my.ini of MySQL)
There the entry: STRICT_TRANS_TABLES
was filled out. I removed this and tried it again.
Now it works.

I hope this helps some others.
(but I still think the table should be corrected and a language selection should be available when setting up a user)

regards

Closed

Hi,

Maybe you have the same problem as I was having.
I do not use appache webserver and then you have to make an extra change:

If you add "index.php" to the $config['index_page'] item in application/config/config.php then it should work fine. (info from Phil Sturgeon)

This worked for me.

regards

Hey,

Thanks alot for your reply.

My webserver is appache but setting $config['index_page'] did make a difference. I will have a play around and post back here.

Any updates so far ?

Hey,

Sorry I have not got back to you sooner. Having trouble with it but am really short of time at the moment but am keen to get working. Will post here when I get a chance.

Many Thanks

Any update with this? Otherwise I'll close this issue as nobody else has reported problems with it.

Hi..

Sorry for not get back to you on this, work has gone crazy at the moment. Please close the ticket. Great work guys I will look again in the future. I apologise again for wasting your time!

Thank You

Is mod_rewrite enabled ?

Yes, codeigniter other installation works, maybe the pyrocms .htaccess file settings are wrong?

You could take a look at it, but I highly doubt it since if it would be wrong (almost) everybody would have problems with it.

505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

That is very odd. I would send this to your hosting support. Sorry I could not be any more help.

Could you please provide a little more information.

Is this on a local setup or live server.

Is MySQL definitly running?

Are you sure you have the right passwords?

Any information you can give us will help. Right now you are just telling me that something is broken somewhere for someone. We cannot do much with that. :-)

I also had a problem with the installation.

So I tried manual execution of the sql files.
The database went OK
but the default data failed.
Problem is with this line in default data sql:
('twitter_password','Password','Twitter password.','password','','','','0','1','twitter'), the type mentioned 'password' does not exist in the table settings

Solution:
in the database.sql at CREATE TABLE settings update the line:
type set('text','textarea','select','select-multiple','radio','checkbox') collate utf8_unicode_ci NOT NULL,

To

type set('text','textarea','select','select-multiple','radio','checkbox', 'password') collate utf8_unicode_ci NOT NULL,

This solved the database setup problems for me

It's weird to see that the default data still isn't inserted properly, it should've been fixed a while ago.

Hi,

Thanx for your Mail.

I downloaded pyrycms yesterday (03OCT09, philsturgeon-pyrocms-287aff0.zip)
And the problem is in the 1-tables.sql file.
By adding the 'password' entry I was able to execute all 3 .sql file's without problems.

If I now start pyrocms, it shows me the default page which is good.
But I encountered a new problem, when I try to login with:
user: demo@example.com
password: password

The browser goes to:
http://localhost/pyrocms/users/login

Which does not seem to exist, showing me a 404 page.
So I am not able to login to test the CMS :-(

I also cannot find a controller called users??
so I am stuck a bit.
I guess this should be Admin instead of users.
I have not found a solution for this yet.

regards

Did you upload your .htaccess file as well ?

Well I do not use appache as webserver but Abyss from aprelium,
So I do not have any need for the .htaccess
At least I think. I will take a look at the aprelium forum for abyss if I can find anything about .htaccess but I thought it was specific for appache.

There's your problem. PyroCMS relies on a working .htaccess file in order to work properly. It has never been tested on Abyss (or any other non Apache server as I know).

Not entirely true. PyroCMS simply requires mod_rewrite for the URL rewriting. If you add "index.php" to the $config['index_page'] item in application/config/config.php then it should work fine.

Yorick: perhaps this could be added to the installer? Have a "Server Software" option with a dropdown showing only "Apache (with mod_rewrite)" and "Other". If mod rewrite then have a blank index_page, if anything else keep index.php in there. That should make it work with most server software around.

Thanx Phil (and Yorick),

The last info from Phil was the solution,
everything seems to be running ok on my Abyss webserver.

I'll add this feature to the installer as soon as possible :]

Hi, i'm having a problem with after i install the database, I get a blank page that says "No input file specified". Any ideas why? I've uploaded the htaccess and I have mod_rewrite enabled.

magicmarkker: Is this still causing problems? Have you tried the newest version?

ok so I found the problem. If cgi.fix_pathinfo default is set to 1, you can fix it either of two ways.
1. Create your own php.ini file and set it to 0
2. Go to .htaccess file and add question mark after index.php and before slash.

Do you have a suggestion for PyroCMS implementation? I think this is a environment problem, and im worried if I make the change mentioned in option 2 it would have widespread effects for other users.

Can you test this change in a few common environments so we can include it?

This was a suggestion on how to fix the No Input File Specified error on Dreamhost hosting. Because on their hosting cgi.fix_pathinfo default is set to 1 and in order for the htaccess file provided with PyroCMS to work, cgi.fix_pathinfo needs to either be set to 0 or in the htaccess file you need to add a question mark after index.php and before the slash so like this, index.php?/$1

I'll add cgi.fix_pathinfo to index.php and hopefully it wont break for everyone. >.<

You need to run the installer. I see you have found the installer in another issue so I will close this one down.

No. The layouts folder is there to allow different layout files to be used. This feature will be expanded in the future to allow modules and pages to select layout files.

header.php, footer.php, etc are all there so the same basic components can be used for each layout, just used in different orders or combinations, with different layout code in the main layout file.

Trust me, its a required feature. :-)

You don't need a plugin for gravatars :)

Of course you do. You should NEVER refference a third-party website in your codebase unless it is wrapped in a function.

http://codeigniter.com/wiki/Gravatars/

Something like that, but renamed to avatar() would be fine. That way we can switch to any proivder down the line.

No you don't. Just chuck it in a helper. Plugins should only be used when you have additional resources. Getting a gravatar only requires the building of a URL, and an email being passed to it.

The wiki article I linked to was actually a helper, but if you check the manual for plugins:

Plugins work almost identically to Helpers. The main difference is that a plugin usually provides a single function, whereas a Helper is usually a collection of functions. Helpers are also considered a part of the core system; plugins are intended to be created and shared by our community.

It is a simple feature, just wrap it somehow, dont care which.

Is this a full fresh install? when did this start happening? Whats the URL?

Ray is having this issue as well. It's most likely caused by a buggy .SQL file, I'll copy whatever is in the settings table and post it here tomorrow.

Settings table is empty. The rest of the default data gets in, just not that.

Fixed in the latest commit

Currently taking a hone hour break because I had enough of coding for more than 16 hours in total (over the past 2 days). I'll scrap the current template (again) and make one based on the installer :)

I thought you needed to finish widget work first? I suppose if its only backend left then that is enough to get going on templates again right?

We can leave the widget backend to someone else. You have already bitten off more than you have time for by the sound of it. :-)

The frontend needed to be finished, which is pretty much done for now.

If you don't mind me commenting, I don't think any of the current templates (installer, default and admin) are particularly great.

It all needs to be consistent, cool and stylish. We can get away with something simplistic, because it makes it a lot easier to do for us and makes it a lot nicer for the end-user. I'll have a go at writing up a simple stylesheet and some nice valid XHTML for the installer, just as a test to see what you guys think.

In the end the idea was to make the same template for everything (or atleast make it look the same). The current default template does look like shit and is being replaced with a template based on the installer.

This one can be solved the old fashioned way, a theme-off! :-D

If you are both working on one anyway, we can see which is better and make that the default, the other can just be a cool extra theme to be included in the release. Would be good to have a few in the core codebase as varied examples of what we can do.

Or we could do the following :

@author Yorick Peterse - PyroCMS development team @copyright Yorick Peterse - PyroCMS development team

Personally I think this is better.

@author Yorick Peterse - PyroCMS

is fine. We should be adding full doc-blocks to all our work really. I'll put this on the "Coding standards" wiki page.

Great. It's something that makes it look more mature :]

Done. Thank you for this bug report. :-)

People are stupid, the file is in there so read it. Anyways, I'll add that list.

also, fix the error “The dummy data could not be inserted, please verify your settings.”

That error should only pop up whenever the tables don't exist for some reason, but I'll verify it.

Issue fixed in this commit : http://github.com/philsturgeon/pyrocms/commit/799f0ba6c51444fe66e84a90a57a597691e85d22

Much better. I had to make a change to allow soft error handling for GD if it is missing but now the server information is very handy.

For the installer to be complete, we need to make it into a step-by-step system.

Step 1, show you the server information.
Step 2, tell you to permission your files
Step 3, take information from the user,
Step 4, tell them to re-permission the config files back, and give them a link.

The dashboard should be available via a link from all steps, along with a "Skip", "Next" and "Back" on appropriate pages.

I'm actually thinking of recreating the entire installer from scratch using CodeIgniter, it's too messy at the moment.

It's fine as it is if you just get it running step -by-step. even a barebones new application would be overkill for this.

Just get it running in steps and we're fine. :-)

No, I've decided to completely recreate the installer. It's way too messy right now. On top of that I want to add an option that lets users update their database without messing around in phpMyAdmin.

We really should not add any scaffolding or anything similar. Please keep the installer to its absolute basics, and we can create a "PyroCMS Pen-knife" which will contain random utilities that exist outside of the main installation at a later date, if it is required.

I would like a working full installer as soon as possible as I am getting multiple complaints each day from users having trouble with it. Some are actual errors, some are lack of understanding as the installation is not clear enough.

Making this work in steps is a good quick solution for v0.9.7 and you can re-code it in time for v1.0.

Sound fair?

Already started recoding it earlier today, spent the last 6 hours working on it. Currently in the process of finishing the last step. :]

I know you have been working on this all day but I had to do quite a bit of work before the public could be let near it.

Firstly, why did you include a 2nd installation of CodeIgniter?! And why did you have some crazy modular system in there? If it needed modules, use the same one as the rest of the site?

Also you forgot to remove the tabs for Upgrade and Maintenance so those have been replaced with step 1, step 2 and step 3.

The main page still had the upgrade and maintenance headers and text on it too, lol!

Finally, anyone without GD would not be able to install PyroCMS. I dont have GD!! I added a message to say "you match most of the requirements, continue if you dont mind shit being messed up" or something along those lines.

The main thing is we got there! This is now a VERY cool installer, thanks very much for the work on this dude.

Any you know what this means? We can have a multi-lingual installer now! :D

Dude seriously, cry me a river. The "crazy modular system" is the HMVC, and is almost identical to Matchbox. The tabs and all the other stuff have been changed in a new commit, so check that first before replying.

Finally, anyone without GD would not be able to install PyroCMS. I dont have GD!! I added a message to say "you match most of the requirements, continue if you dont mind shit being messed up" or something along those lines.

Finally, anyone without GD would not be able to install PyroCMS. I dont have GD!! I added a message to say "you match most of the requirements, continue if you dont mind shit being messed up" or something along those lines

It only retrieves the version. If it isn't installed it will tell you. I don't see the problem of this. I've listed some reasons for moving the installer to CI below :

• Much easier to manage
• Multi lingual
• Cleaner code. The original installer was horrible and made me sick every time I took a look at it.

Moving to CI was brilliant, but you havent explained why we had to have a second copy of CodeIgniter in the codebase. We can use the same one...

The main issue with GD was that it would physically stop people from progressing through the installer. I do not have GD and it was creating a session variable that would not allow me to progress. This has been modified.

HMVC seems pretty fecking nuts after looking at the code. It has CI_BASE extentions in the Controller library and all sorts of crazy shit. Matchbox would have been a better choice to keep things working in the same way, but ofc we dont need any modular system now.

I am just adding a few more changes and you can see what I am talking about. A "Complete!" page was required too.

The GD library is something that should be required since the galleries and the staff module depend on it (or is it using something else ?) If you don't have it you should install it, instead of modifying the installer.

GD library is not required in the same was a PHP or MySQL because it will work at a basic level without it. If I turn off captchas and dont actually use products, staff or gallery then I will be fine without it.

Remember we are trying to support as many people and as many environments as possible, at varying ranges of technical ability. Everything has to work for everyone, unless they are using IE6 :-p

Ah ok. The installer will show the following message whenever the server doesn't passes the validation process for a full 100% :

Your server meets most of the requirements for PyroCMS to run properly. This means that PyroCMS should be able to run properly but there is a change that you will experience problems. In most cases this this is being caused by not having the GD library installed.

I already had a message in for that, but that is fine when you have fixed the change/chance typ0. Lets write new issues for new problems on this one.

Didn't notice that typo, I'll fix it later today.

Pfff....Weren't the languages based on the URL or something like that ? If so you could simply redirect to the English version.

Issue being, the code says if a page & language dont match, the page doesnt exist for you.

That is the fundamental logic and pages are listed with language next to them. They only happen to share a slug, but they are separate enteties.

Should we perhaps make them simply "a Page" with multiple content boxes for different languages? Then just say "[checkbox] Spanish is the same as English" to hide the input box for spanish, so it shares the English content, etc?

This could get confusing.

Multiple content boxes for different languages isn't going to work when you have many different languages.

Done.

Which theme are you using?

all 3 themes missing last link in footer

And what last link ?

Done.

Has been fixed in v0.9.6.2 was an issue with the multi-langing of the "new item" type buttons.

Done.

Looks pretty neat :)

This has been fixed in the main codebase and applied to pyrocms.com and pyrocms.com/demo.

Thanks for the heads up!

Which line in which file should this change be made?

If you could post the exact line as it should be that would be brilliant.

Done, will be pushed later on.

Should this be applied at a "Themes" level?

Balls to that idea.

Done!

You mean displaying of active and inactive comments for each module which uses the comment-module? I've started so think about that while scripting the backend-part. The problem was that the easiest way to solve this solution to use url-params. But I wasn't abled to parse url's like this: admin/comments/module_name/edit e. g. to differentiate between the modules... If you could give me a solution of this, I can extend the comments-admin for that issue ;) I just need to be allowed parse url's with the special syntax: admin/comments_module/module_which_use_comments/action

Anyway I just need the possibility to get the module_name for which the comments should be displayed. I'll have a look at this one again. Some basics still exists ^^

BenneX

I think we need to have a serious think about how to create links to modules from the UI anyway.

If we have a "item table" which had, module, uri, id/slug and then we created an id for that, we could use that link_id everywhere.

Basically the link_id wouldnt exist until somebody tried to use it. then it would be added to the database.

This could be VERY handy for creating links to photos, news articles, suppliers, etc because all we'd need to know is the name of the module, the URI it is using and the ID number of the object and it would work.

That would also mean that we can have multiple "things" to link to for a single module.

With me on this? Guys, opinions would be great.

Step back.

We're using a polymorphic association for comments, so everything that is commentable can be commented on, from a central "Comment" model, right?

Why can't we assign a "resource_name" to the module (so the Articles module would have an Article resource, or the Categories module have a Category). Then we just display that along with the ID?

Thats kinda what im getting at, just struggling on the details. We can give something a "resource_name" and assign that resource a URI structure and some DB joining details, but not sure exactly how. Got code blindness over this one so need some fresh eyes on it.

The reason it seems like I am overcomplicating things is for the simple reason of this is quite complicated and started a discussion on a bigger problem.

Problem 1) We have no way to know what the URL is of a commented item. The CMS used to store the URI string in the database as unique but this is no good when commenting on news as the URI slug can change.

Problem 2): It assumes that only one kind of comentable "thing" exists for each module. This wont be true in some more advanced cases.

Problem 3) (the bigger thing): We need some sort of structure for the entire system. This is what I am talking about when I say "things". If everything has shared meta-structure then we can build tree's, set permissions, create navigation, breadcrumbs, etc all very easily. Right now with all modules acting entirely on their own there is no way to create a user friendly system for any of these aspects, AND keep it modular.

We can discuss point 3 separatly, but it would drastically change how we handle this issue in general.

I tweeted an idea to phil several days ago, but it seems he missed it, therefore I'm showing it here :P

If we want to link everything together (or atleast give the possibility of doing this), the only thing you would need to know is the table and the ID of the row. Simply creating a parent field with the following structure : %TABLENAME%_%ID%. For instance, a comment could have the following in it's parent field : pages_2. This would refer to the page with ID number 2.

As I said, not all modules will only have one "thing" so this approach is no good. Also, how would you join using that? There is no advantage to that approach over having a hash/unique key with various fields stored for each row.

I still cant even think how to begin this one.

Seperate them with a comma. Joining is simple since you can create the syntax for the query based on the format.

<?php
$parent = $this->some_model->get_parent(); // Get the parent(s) of the current item. In this case it will return page_1

// Get the stuff for the syntax
$array    = split('_',$parent);
$table    = $array[0];
$id    = $array[1];
 
// Do something with the database
$this->db->query("SELECT * FROM $table WHERE id=$id");
?>

Seperate them with a comma. Joining is simple since you can create the syntax for the query based on the format.

<?php
$parent = $this->some_model->get_parent(); // Get the parent(s) of the current item. In this case it will return page_1

// Get the stuff for the syntax
$array    = split('_',$parent);
$table    = $array[0];
$id    = $array[1];
 
// Do something with the database
$this->db->query("SELECT * FROM $table WHERE id=$id");
?>

While I was workin on this module I've just thought about that issue and as far as I remeber I had a solution but only the problem with the uri routing and the parameters. I need to install the github stuff and could have a look at it again :)

Home brew ! The taste of home made cookies is always better than buying it in the local bakery store :)

Ok screw it we're going to go with mine. It currently allows view forums, view topics, new topic and is almost working with new replies. Then its just "Edit topic", "Quote" and the moderator tools and its ready to go.

On overloading it with features:

Surely Pyro's gonna need a private messaging system anyway? I'm sure a lot of the additional forum functionality can be abstracted into separate modules and used across the system. That way the forum module itself is kept relatively clean.

Private messaging and friends etc are already seperate modules I have used in other projects. When I mentioned this I was worried that if we start down a community path then I will end up cnverting the lot (as seperate modules) and will start moving away from the current core-purpose of PyroCMS: "Creating simple sites for personal and corporate use".

I have got a little bored of converting the forums module, but will find the motivation to finish it sometime I'm sure. :-)

When loading the dashboard you would fetch these results and store them in a variable (and output it). I think it's best to only do this for the default modules. If you would do this for every module the dashboard would probably become very slow.

For instance, you could use the following :

Model function (from my guestbook) : http://pastebin.org/10849
View file (also from the guestbook) : http://pastebin.org/10850

Pretty much fixed in this commit, though the dashboard message needs to be changed (and translated) : http://github.com/philsturgeon/pyrocms/commit/bfd50f7a98542bf55ed3dd51f269ead864fe8b17

Current features

• Comment stats (all,approved and pending)
• General stats (pages,users and news articles)

To do :

• The RSS stuff
• The server data

RSS support has been added in this commit : http://github.com/philsturgeon/pyrocms/commit/e329670aa0614d3c816a960d711308a33f436774

Sorry Ignited this was meant to be for you.

I have so far only checked the code looking at the commits and so far it needs lots of improvement in the quality of the coding. This needs to be using lang files and there are a few other comments on your commits.

PLEASE do not randomly assign yourself issues and commit half finished work to the master without running it by myself.

I wouldn't do it if people would do their homework. I'm not going to work on a project where most of the project members do jack shit.

They do what they can when they can. I am looking into ways to improve communication but its not the point. If you want to work on a new issue talk to me about it so we can plan how its going to be done. I REALLY dont want work that I have no idea about being thrown into the master.

If random work was thrown into branches... thats a different matter! :)

Had a self closing tag which is now and empty closing tag. Still cant spot an issue here though, looks fine. Which browser?

Firefox 3.0.13

It's possible im just being an idiot here but it looks fine to me. Could you pastie a corrected version of this file so I can include it into the codebase?

Which template are you using ?

The admin template. http://example.com/admin/login

Checked the bug and it seems to be working fine, closing this one.

Thanks for the heads up. Done.

This is the AJAXify plugin that loads only part of the page and has history enabled by using the hash tag as a unique URL. This stops a new page load but maintains history and bookmarks.

Fixed the last AJAXify related issue I could think of, language switching links now use the AJAXify hash tag so you get sent back to whichever page you are viewing, AJAXified or not.

What kind of error ? Or is that the actual error itself ?

This seems quite likely to be a permissions issue. Did you run the commands in the INSTALL.txt file?

We should probably put a reminder in the installer interface to run these commands. I will put something together tonight.

Almost 99% sure this is an issue related to file permissions, I can create a photo album without any trouble.

I double checked it and this isn't a bug.I closed it for now, but feel free to message me in case you want to have this issue re-opened.

Check this: http://files.getdropbox.com/u/152065/pyrocms_add_gallery_error.png

Have you copied the main chinese language files for CodeIgniter into the systems/ folder? I forgot to mention this on the wiki page.

Oh,I forgot it.It seems work following your direction.Thanks.

Glad to hear it. If we can sort out issue #42 hopefully we can get chinese built into the core!

It's "Nederlands" in Holland :)

Hows this language coming along? I have changed the name and added the flag, all we need now is the extra files to be translated, and PyroCMS will support three languages! :D

• What is the something and something_else class names all about?
• What does module_function method do?
• Where is this called?

Why dont we just extend layout library to check for view files within the theme folder that match the filepath?

if(file_exists( theme/current/views/modules/news/views/index.php ))
{
    whoop, use the new one
}

else
{
    use the old one
}

I thought we decided we would just strip out the float-left float-right rubbish and leave modules to be styled with module specific CSS which could be overridden by theme CSS with !important;

It's just a bunch of example names.

I thought we decided we would just strip out the float-left float-right rubbish and leave modules to be styled with module specific CSS which could be overridden by theme CSS with !important;

We didn't actually. On top of that that idea is just plain stupid since you would still be limited to the HTML structure, and there's no way of changing it other than modifying core system files. Simply said : A big no-no.

For instance. Say a user wants to have the date of a news article showing up at the bottom, without having to modify the module view files or adding really stupid CSS rules. That's simply not possible with the current system, but it will be with the new one.

Considering we now have this I'm closing this issue :)

So far the only thing that needs to be fixed is the stupid bug that prevents a widget from being executed twice, and god knows why it isn't working.

The widgets library has been added. The next step is to integrate it into the system.

Quick question, why can't I extend the default controller or MY_Controller ? This is required by the library, but whenever I do so I get the following error : http://i29.tinypic.com/2z3nqwy.png

Oh and by the way, where do you want me to load the library ? Right now I'm loading it at the top of the PyroCMS template (which is really, really stupid).

Autoload? It will be used on all pages so seems fair enough.

Not sure about the loading issue. Include the widgets class in MY_Controller?

Hm, didn't thought about that :P

Not sure about the loading issue. Include the widgets class in MY_Controller?

I can't make it extend the Controller class or the MY_Controller class for some reason. Embedding it into the MY_Controller class would be rather dumb.

We already do this for Public_controller and Admin_Controller:

include(APPPATH . 'libraries/Public_Controller'.EXT);
include(APPPATH . 'libraries/Admin_Controller'.EXT);

So you want me to extend the Public Controller instead of MY_Controller ?

Fixed the problem using the get_instance() stuff. Not really fond of it, but it works.

get_instance is a good way of doing it. More logical and less hacky that my suggested method. :-)

Isn't there another way, besides the one you suggested or my solution ? I'm not really fond of having to use $this->CI->load->model and stuff like that. $this->load->... is much cleaner :)

I'd say this is the best way to go. This is how all of my libraries do it. Makes much more sense that extending controller.

Hm..I'll just leave it as it is :)

So the News Widget is finished, but the other ones aren't very clear to me.

RSS Widget

Internal or external RSS feeds ?

Twitter Stuff

How the hell do I use the Twitter model ? It doesn't make any sense :P

Links Menu

Use result_array() rather than result(), that way you'll get rid of the Std Classes. Other than that, is it possible to fetch the link groups using the name, rather than the ID ?

Currently the following widgets have been created :

Feeds (RSS and Atom)

Enables the user to display external RSS or Atom feeds. The feeds are parsed using SimplePie

Navigation menu

Shows the navigation elements for a certain navigation group (e.g. Sidebar)

Recent News

Shows a list of recent news articles.

Why use simplepie when we can just use built in SimpleXML?

Anyhow before making too many new widgets we need to worry about sorting out the db structure so we can have multiple widgets of the same type.

Because it's MUCH easier to use SimplePie instead of writing my own parser.

Anyhow before making too many new widgets we need to worry about sorting out the db structure so we can have multiple widgets of the same type.

I double checked the database and adding the the same widget multiple times works perfect, the only thing that needs some minor modifications is the library in order to make this work properly.

Version 1.2. 1.2 MB zip file

That is why it's better. Thats like fishing with hand grenades dude!

So you are basing your arguements on the file size of a zip package. Did you bother looking at the contents ? The actual library is just 380 KB (of which about 50% consists out of comments).

Seriosuly, don't base arguements on file sizes...

Still, RSS parse with simple xml is 20 lines of code. whats the point?

Because then you'll only be able to parse RSS, whereas SimplePie can also parse ATOM. I don't really see the problem, it works perfectly.

I assume .spc files are SimplePie Cache? You need to configure the library to store ALL cache in the main cache folder, NOT application/widgets/feeds/cache/*.spc

We don't need ANOTHER cache folder, just the one please.

This issue can be closed since all the widgets are created. The only thing left to do is to make a backend module and we're done :)

This issue has been fixed in the latest commit : http://github.com/philsturgeon/pyrocms/commit/db19539933431889dc9f88d8c5321fb7cfb77cde

I've pushed a branch named "issue_36" with the fixed file, which just need to be merged into master.

There was a little syntax error, which also can be fixed manually.
Just open the following file:

pyrocms/application/modules/navigation/controllers/admin.php

and go to line number 156 or search for the following code snippet:

$this->session->set_flashdata('success', $this->lang-line('nav_link_delete_success'));

and replace it with the following code:

$this->session->set_flashdata('success', $this->lang->line('nav_link_delete_success'));

BenneX