Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - CerealGuy
166
Archived fixes / updateSettingsFile in install.php
« on January 6th, 2015, 02:17 AM »
In refer to http://wedge.org/pub/support/8744/install-problem/msg296767/#new

Pull Request: https://github.com/Wedge/wedge/pull/25

EDIT: umm having some troubles here, not sure if this really fixes it. Perhaps test it again, getting some errors here in the moment, but not sure if its because of this.
167
Support / Re: Install problem....
« on January 5th, 2015, 08:19 PM »
Cant test it in the moment, but you need to open /install/install.php in an editor and look for "function updateSettingsFile($vars)". Rename it to "function updateSettingsFile2($vars)", that should be the easiest solution for the moment.

But cant test it, im not sure if both functions work exactly the same, its possible that there are more improvements needed.
168
Support / Re: Install problem....
« on January 5th, 2015, 07:22 PM »
Perhaps its enough to delete the updateSettingsFile() function in /install/install.php.
Wedge is now using that function to write enabled plugins into the Settings.php file.
169
Off-topic / Re: Happy New Year
« on January 5th, 2015, 03:00 PM »
Quote from meetdilip on January 5th, 2015, 12:06 PM
Wedge looks impressive :blush:
It doesnt only look impressive, it definetly is impressive :eheh:
170
It looks like you have some problems with your file permissions. The user under which your httpserver is running (or on which php is executed) needs to has rights to write to Settings.php. Until now this wasnt needed, but now it is. If you have a webspace, just change the filepermissions with your ftp client to 755 (or maybe 777 depends on your webspace).
171
All old plugins should still work. This just gives a lot more possibilities to plugin devs.
172
Everything's now working, awesome :cool:.
Thank you so much @Nao, i totally love wedge :D
173
Features / Re: New revs
« on December 30th, 2014, 03:22 PM »
Perhaps you should permit people to reply on this topic. I dont think that it needs "life", its only to keep track of new commits. In my opinion bugs should be discussed in an own topic.
174
Features / Re: New revs
« on December 30th, 2014, 12:47 PM »
@Freñiçh
Use the commit before or change 'Subs-MinifyPHP.php' to 'Subs-CachePHP.php'. Also you can delete the Subs-MinifyPHP.php file.
175
Looks like you missed to change the require in Subs-Template.php
Line 1129
require_once(APP_DIR . '/Subs-MinifyPHP.php');

In the moment i dont have much time, but theres something wrong in apply_plugin_mods.
Code: [Select]
// Phase 1: Waste no time if no plugins are enabled.
if (empty($my_plugins) && empty($settings['enabled_plugins']))
return;

if (empty($my_plugins))
$my_plugins = $settings['enabled_plugins'];

$this_file = $error = false;
foreach ($context['enabled_plugins'] as $plugin)

foreach loop uses $context, but i think you want to use $my_plugins. Also it generates an error, which wedge isnt able to catch. But my errror.log says "PHP message: PHP Warning:  Invalid argument supplied for foreach() in /usr/share/nginx/www/wedge/core/app/Subs-CachePHP.php on line 189
". Also my_plugins is a string, so some split is needed.
176
I vote for the first because as an administrator you have a bit more control about it (you could also rename the plugin, but Settings.php is also a nice way to modify it quickly) and in general its more clear if you look at Settings.php and see all enables plugins and not just some of them. Think about someone who edits Settings.php and wonders why there are only some of his enabled plugins. Also the file_exists thing doesnt need that much time that you have to care about it, plus its more fail resistant.

Interesting way to solve the problem, i like it :cool:
177
Plugins / [Plugin] CountLikes
« on December 27th, 2014, 06:43 PM »
This Plugin basically shows in profile summary how many likes this user gave/receieved. You can also view those posts.

https://github.com/C3realGuy/CountLikes
178
I went threw different "solutions" for this but didnt find one with which i was really happy ^^.
The one which I like the most in the moment needs a bit more to change, but it would reduce some I/O tasks. But here some ideas:
1) I would get enabled_plugins always via sql, no need for cached settings, but move it in an own table. We could also build this sql query without Class-DB so no need for a loadSource or a require (dont really like this but how else could you load Class-DB without any "depend" problems?!).
2) When going through those plugins we could already check if any of them has mods.xml and if yes which files are interesting. With this information we dont need to open mods.xml for every plugin when calling apply_plugin_mods.
3) Create a global $mods array which knows which plugin modifies which file. apply_plugin_mods would not need to know enabled_plugins anymore. $mods['pluginpath'] = array('pluginname', array(file1, file2...)). And if $mods is empty, apply_plugin_mods can return.

Just some quick ideas, perhaps its just brainshit, its already late i think :D
And i think this should be in bugs, dont know why the hell i opened this thread under plugins :hmm:.

Hope you had some good time with your family? For me its always a bit stressful, and too much food ^^
179
Currently you cant modify Files like Class-System,QueryString,Subs,Errors,Load etc. because $context['enabled_plugins'] isnt inited yet. Perhaps that should be done before loadSource ever got called?!
180
Support / Re: horizontal screen size
« on December 26th, 2014, 08:45 PM »
Setting width for .postarea article did it for me. In my case its 700px, but im using a custom skin so might be different for the other skins.